Why Use Models in System and Product Design?
model /mŏd′l/
noun
A small object, usually built to scale, that represents in detail another, often larger object.
A preliminary work or construction that serves as a plan from which a final product is to be made.
What you should use instead of screens to design digital products.
TL:DR
Using product and systems models—instead of detailed screens—in early stages of product definition and design identifies and validates requirements, gives the product team (Product Management, Development, and Design) insights needed to make major architectural and business decisions with confidence, speeds the delivery of front end screens and flows, and unblocks development [1].
The following two use cases are real-world examples of the use of models in product definition and design. All content, conflicts, insights, and conclusions are true, though I have updated some of the visualizations for consistency. I tell the stories linearly, but in practice each project had plenty of revisions, rejections, and updates.
Names have been removed to protect the innocent.
There’s an elephant in the room
Nearly every product definition process I’ve been involved with in my career (20+ years) has eventually devolved into a high-tech version of the old parable about sightless people describing an elephant. Each person describes the elephant differently—as a wall, a column, or a spear—depending upon what part of the elephant they touch. As part of the product definition process the product team delivers business, technical, and design requirements in an effort to describe the elephant (i.e. the product) they want to build.
But it’s hard to turn a list of requirements into a product vision. And the odds that every member of the product team has the same product vision (however vague) are low.
“When can you get us some screens?”
That’s why product teams want to see detailed, designed screens ASAP. Design deliverables soon become de facto requirements docs and everyone yearns for the moment Design gets it “right” and unblocks Development.
It’s unintuitive, but relying on detailed screen designs—even “rough” wireframes—too early in the product definition process actually slows things down. After every product review Design fixes mistakes, adds new requirements, creates, updates, and discards dozens of ever-more complicated screens and functional flows in an attempt to get things “right”. This takes increasing amounts of time—with or without the help of AI. [2]
Working with screens severely limits the breadth of product issues a product team considers at any point in time. This increases the chance that the team will overlook one or more critical requirements (see either use case) until it’s too late to address them.
Models are better, cheaper, and faster
A model can present a top-down view of a single feature, an entire product, or, most powerfully, a complete system. A model can show connections, relationships and product architectures that would be impossible to show or describe in a set of screens or flows.
A model is easier to build, modify, and maintain than any set of screens and flows. A model may be any combination of flow charts, data flows, architectural diagrams, user journeys, text tables or any other visualization tools.
The current version of any model should provide the context needed to allow the product team to make their next decision—whether it be technical-, business-, or design-related—with confidence.
A model has no set resolution or level of detail. A model gains more detail each time it is updated after a product decision. A model will soon have sufficient detail about things like the overall product architecture and fundamental features (e.g. account creation flows) to allow Development to begin foundational work long before the delivery of screens. In fact, a model can eventually have sufficient detail to pre-define every element on every screen.
And that’s and that’s a good time to start designing screens.
What’s the difference between a product model and a system model?
It’s mostly about scope and purpose. A product model, for the most part, places multiple features of a single product (see the Amazon Kindle eReader OOBE use case) into a context which helps the product team make increasingly detailed decisions.
A system model (see the ACME B2B Reseller Platform use case) places a product model into context with factors over which the product team has limited-to-no control but which must be accommodated in the final product definition. These may include internal legacy systems which the product must integrate with but which cannot be modified, third-party services with established APIs (e.g. Square for credit card transaction), and—most important of all—established business practices which are simply too entrenched and which will never change no matter what benefits the product may bring. For example, the best designed client management system will fail if it doesn’t meet applicable governance and privacy standards.
Long-term product vision? Short-term scope reduction? A system model can help with both.
A huge benefit of working with system models is their broad scope. A system model will often identify opportunities well-beyond current schedules, resources, and goals. These opportunities are typically so large they do not contribute to short-term scope creep. A future roadmap or vision, however broadly defined, can help product teams avoid making short-term decisions which could limit future innovation.
Conversely, a system model can help product teams reduce product scope when inevitable problems and delays arise and still deliver a consistent, holistic, and compelling product experience.
How to build a model.
“Begin at the beginning and go on till you come to the end; then stop.”
—Lewis Carroll, Alice’s Adventures in Wonderland (1865)
You create models to arrive at consensus about product definition, requirements, customers, competition—whatever the product team deems a factor in making the next round of decisions.
You build models incrementally, beginning with the simplest, most obvious concepts.
You review the model with the product team. If the model—as far as it goes—is correct the team uses it as a framework for further product decisions.
You update the model, adding complexity and detail. And stop. And review it. And do it all over again. A model may, in fact, be used across multiple product initiatives, growing in sophistication and detail with each revision.
On the left, the first version of the ACME B2B System Model. On the right, the “final” version.
1 If that doesn’t make you want to read further, I don’t know what will.
2 Using models in conjunction with AI can yield tremendous productivity breakthroughs. But I’ve yet to see a prompt which can get any AI client to first document the full set of requirements which bound any given product release. Until that can happen, a human designer will always be needed to provide the context for the AI-generated work.
Model Use in System and Product Design