Screens are easy to discuss because they are visible.
A dashboard can be sketched. A form can be rearranged. A navigation tree can be debated. Stakeholders can point at a prototype and react immediately.
The underlying product model is harder to see.
Who can perform an action? Which state transitions are valid? What does a record mean? Which information is authoritative? Which permissions depend on context? What happens when a process spans organizations?
When teams begin with screens too early, those questions do not disappear. They become hidden inside interface decisions.
A stronger sequence begins with capabilities.
A Screen Is a Projection of a System
A screen is not the capability itself.
A "Register Student" page might represent a capability involving:
- guardian identity;
- student identity;
- relationship authorization;
- school membership;
- eligibility rules;
- consent;
- duplicate detection;
- invitation state;
- audit history.
The screen is one representation of that capability for one actor in one context.
Another actor may access the same capability through an admin portal, API, mobile flow or automated process.
If the team equates the screen with the capability, the domain becomes fragmented across interfaces.
Capability Modeling Asks What the Product Must Be Able to Do
A capability is a meaningful ability of the product or organization.
It is usually more stable than a feature description and less implementation-specific than a screen.
For example:
Capability: Manage supplier quotation
That may include:
- create quotation event;
- define items and quantities;
- invite eligible suppliers;
- accept proposals until a deadline;
- handle revisions;
- normalize commercial terms;
- compare proposals;
- award all or part of the request;
- preserve decision history.
The screens can change. The capability remains.
This gives product, design and engineering a shared object to reason about before they optimize the interface.
Actors Matter Before Navigation
Navigation often reflects actor assumptions.
If the product has guardians, students, teachers, school administrators and platform operators, a single information architecture may not make sense.
The team first needs to know:
- What can each actor see?
- What can each actor change?
- Which relationships grant authority?
- Which actions require another actor?
- Does a person hold multiple roles?
- Can the same user act in different organizational contexts?
A screen-first approach may create a global User.Role model because the UI only shows one role at a time.
Later, the product discovers that a guardian can also be a teacher, or that a teacher belongs to multiple schools.
The problem appears technical, but the root cause was a product model that never separated identity, membership and permission scope.
State Transitions Are More Durable Than UI Steps
Interfaces often suggest a linear workflow:
Draft → Submit → Approve
Real domains are rarely that simple.
Can a submitted item be withdrawn? Can it expire? Can an approver request changes? Can multiple approvals happen in parallel? Can a rejected item be resubmitted? Can an external event change the state?
State modeling makes these questions explicit.
Once the state machine is understood, UX has stronger material.
The interface can communicate what happened, what can happen next and why an action is unavailable.
Without that model, disabled buttons and conditional components become the accidental specification of business rules.
Permissions Belong in the Product Model
Authorization is frequently postponed until engineering because it is described as security.
But permission is also product behavior.
A guardian may be allowed to register a child. The child may be allowed to suggest an opportunity but not submit the registration. A teacher may see classroom performance but not private family records. A school administrator may manage institutional settings but not another school's data.
Those rules shape the experience.
Design cannot create an accurate workflow without them.
Security cannot implement them safely if the product has not defined them.
The capability model should therefore include who can perform an action and under which scope.
Domain Language Reduces Interface Ambiguity
Words in a UI are often the first visible symptom of an unclear domain.
Teams use "account," "profile," "member," "student," "user" and "participant" interchangeably. Then backend models inherit the same ambiguity.
A stronger process defines the concepts before using them casually.
For example:
- User: authenticated identity.
- Student: person represented in the academic domain.
- Guardian relationship: authority relationship between a user and student.
- School membership: time-bounded relationship to an institution.
- Participation: student's involvement in a specific competition edition.
Once these distinctions exist, screen content becomes easier to design because the product is no longer asking one interface object to represent several different concepts.
Capability Does Not Mean Feature
Capabilities and features overlap, but they are not interchangeable.
A feature is often a deliverable expression of value.
A capability is an underlying ability that may support many features.
For example:
Capability: Maintain decision history
Possible features:
- change log
- approval timeline
- audit export
- decision comparison
- restore previous configuration
Thinking in capabilities helps teams identify reusable system responsibilities instead of reproducing the same rule in multiple screens.
This becomes particularly valuable in API-first products, multi-channel products and platforms where UI is only one consumer of the underlying behavior.
UX Should Not Be Deferred
"Capabilities before screens" can be misread as "engineering before design."
That would be a mistake.
UX is essential to discovering whether the capability model corresponds to how people actually think and work.
A domain model can be internally coherent and still produce an unusable product.
The better relationship is iterative:
Domain understanding
↔
Capability model
↔
User journey
↔
Prototype
↔
Evidence
Each view tests the others.
A prototype may reveal that the domain distinction is confusing. A workflow may expose a missing state. User research may show that two capabilities need to be combined for a real-world task.
Design becomes stronger when it is operating on explicit product semantics rather than inventing them implicitly.
When UI-First Thinking Works
UI-first exploration can be extremely effective when the problem is mostly experiential and underlying domain risk is low.
Examples include:
- testing navigation;
- exploring visual hierarchy;
- validating content;
- comparing interaction patterns;
- prototyping a consumer flow with simple state;
- exploring a new interface for a well-understood capability.
The problem appears when teams mistake a useful prototype for a complete product definition.
A prototype can hide security, data history, exception handling, organizational roles and operational constraints because that is often exactly what makes it fast.
Its incompleteness is a feature during discovery.
It becomes dangerous only when the organization treats the prototype as the specification.
Capabilities Improve API and Architecture Decisions
When teams define capabilities clearly, API boundaries become easier to reason about.
Instead of creating endpoints that mirror screens, they can create contracts around meaningful behavior.
Weak:
POST /save-step-3
Stronger:
POST /quotation-events/{id}/proposals
POST /registrations/{id}/submit
POST /memberships/{id}/revoke
The stronger interfaces expose domain behavior rather than UI sequence.
That separation allows interfaces to evolve without forcing backend behavior to follow every presentation change.
It also helps architecture avoid decomposing systems by page.
Capabilities Help Prevent Premature Implementation
A capability model is one of the artifacts that can reduce the cost of early uncertainty.
It does not need to be exhaustive.
It needs to make important actors, responsibilities, rules and state visible enough that the team can recognize major gaps before implementation hardens assumptions.
That connects directly to Implementation Is an Expensive Way to Discover the Product.
When teams skip capability formation, developers often discover the missing model while writing code.
Give UX Better Material
The argument for capabilities before screens is not an argument against interface design.
It is an argument for giving interface design something coherent to express.
Strong product work moves across multiple representations:
Problem
↓
Actors
↓
Domain
↓
Capabilities
↓
Rules and state
↓
Journeys
↓
Interfaces
↓
Implementation
The arrows are not one-way. Evidence should move back through the system and change earlier assumptions.
The practical question is not "Should we start with UX or domain?"
It is "What are we currently treating as known that has not actually been understood?"
Screens are powerful discovery tools.
They become more powerful when the team knows what system they are trying to reveal.
References
- Marty Cagan. The Four Big Risks. Silicon Valley Product Group, 2017. https://www.svpg.com/four-big-risks/
- Silicon Valley Product Group. Product, Design and AI. 2025. https://www.svpg.com/product-design-and-ai/
- Silicon Valley Product Group. Discovery vs. Design. 2021. https://www.svpg.com/discovery-vs-design/