How a Product System can help you focus on what matters

A Design System is a shared reference that maps functional and visual patterns of a digital product. Its main purpose is to deliver a consistent user experience to customers.

The practice of creating such documentation emerged when major technology companies had to strengthen the design of their products to compete.

It was, in a way, a solution to pains of organic development.

While different companies adopt this methodology with varying results, using a Design System has proven to have tangible benefits.

Alongside consistency, re-use of interface elements improves the efficiency of ideation and development. A lot of the overhead—and thus cost—from reinventing the wheel, is spared every time you build something new.

Not just UI

On the other hand, the interface is just one aspect of the user experience a team that’s trying to get a product right has to nail.

Working with our clients at Moze, we found team’s lack of a shared understanding of their product is often the poisonous tree from which friction and distraction originate.

“We’re all working on one system. Why do we form teams around the artifacts people produce instead of the problem they should be working together to solve?”

— Erika Hall

Here below is our approach to helping companies think of their product holistically, drawing inspiration from different techniques and contributionswe found valuable.

What is a Product System?

A Product System—as you may have guessed by now—extends the intuition behind Design Systems to the product as a whole.

It is a shared reference that organizes the key elements of your product in a structure easy to understand. It includes all the information you will find in a Design System but presented in a broader context.

Why should I use it?

The purpose of a Product System is to help the team form a shared mental model of their product and elaborate a common language to ideate and build.

Think of it as a lightweight scaffolding you can use to iterate, rather than static documentation.

Startups can use their Product System as a canvas to keep perspective on who they are and what they’re doing. Grown products can use it as a template to re-organize existing knowledge.

How is it made?

Since products and teams are very different, it’s not our intention to find a one-structure-fits-all. The point is to start thinking product-wise, providing everyone with the big picture.

Below is our attempt to select and arrange the right amount of product knowledge we believe can be useful referencing and maintaining, without turning into an obstacle.

You can use this structure as it is, or just use it as a starting point to work out your own.

The template we present has four main sections to it:

• Idea explains why the product exists and provides a model that describes how it’s made.
• Needs is the place to pin down what your customers want. Your Research goes here.
• Language gathers all about your Brand and stores patterns you use to build and communicate.
• Solutions is about what you are building, how you build it and what has to be done next. Here go your process, product map, and roadmap.

Let’s try to break down each section and see what’s inside.

Idea

The first section provides high-level information about the product, aimed at onboarding people from scratch.

It consists of three sub-sections:

Story

Vision and mission statements shouting how your company is changing the world are overrated. On the other hand, people are naturally engaged by narratives.

Try to tell your story here, tell about who the founders are and why they decided in the first place to start building this product.

Use a short text or a long video, whatever suits you best. The goal is to rally the team on your purpose and clarify where you’re heading as a company.

Model

A schematic description of your product at a system level. It should be useful to explain the basics to a stranger.

You can use any scheme, drawing or blueprint you think it’s more appropriate. Or just use text.

“To work together, we need to use language that makes sense to everyone involved.”

— Abby Covert

Regardless how you choose to represent it, there are two fundamental concepts to outline in your model:

1. What are the main objects in your product.
2. How they are related to each other.

As an example, if your product is an email client app, your objects might be “Inbox,” “List,” “Sender,” etc.

Writing down an explicit definition for each object is a huge step to reduce linguistic insecurity in your team and speed up collaboration.

Once you have defined your objects, choose the diagram structure that best visualizes the relationship between them.

Principles

Given the purpose outlined in your story, principles should help the team understand how to behave to achieve that purpose.

Hence, to define effective principles you should take a clear stand about what defines good behavior.

The goal is to enable team members to make the best decision possible whenever they need to make a call on their own.

Defining your principles will also help you with your product’s positioningsince your choices also define where you stand in the competition.

Here’s a great example from Medium:

Here are a few of the early design principles we crafted at Medium:

Direction over Choice. This principle was often referred to while we were designing the Medium editor. We purposely traded layout, type, and color choices for guidance and direction. Direction was more appropriate for the product because we wanted people to focus on writing, and not get distracted by choice.

Appropriate over Consistent. This might seem controversial, but when applied across devices, its purpose is clear. We were willing to break consistency if it was more appropriate for the OS, device, or context.

Evolving over Finalized. This is exemplified in the ability to share Medium drafts, write responses, and leave notes. The content on Medium should be antifragile, improving with use and evolving overtime. We did not want to design printed books for the internet.

Needs

Customer needs should be the team’s north star to decide what to do, how to do it and when. Getting what you learned lost in a report will turn it into waste, making it visible at all times will help you keep focus.

From best guesses to thorough Research, use what you learned to define what are the needs of your customers you want to address.

A convenient way to arrange this section is to start by defining hi-level needs, and then breakdown lower level points hierarchically.

For each need, you can include reference to related qualitative and quantitative Research.

Mind this should not be the place to describe how you intend to fulfill those needs, just a clear reference to customer problems.

Language

This section gathers information about your functional, visual and written language. Everything you find in a Design System.

You can arrange content into two sub-sections:

Brand

Visual and written elements of your Brand (Brand Identity) should be the primary focus of this section. Describe how they are made and how to use it in your product and touchpoints.

However, you might as well include information about channels and strategy if you think it can be helpful to collaboration in your set up.

Modules

Functional and visual elements of the user interface. Your UI library. If you are building non-visual interfaces, the building blocks of your interactions can be placed here as well.

Solutions

Finally, it’s time to ship. List your solutions in this section; describe how they are made, how you build them and what’s next to be done.

Include every solution or artifact related to your main product, such as landing pages or strategic internal tools.

In short, if it has to be built, it should be part of your solutions.

I’m sure you have lots of stuff going on, you don’t have to cram in every detail. Again, the goal is to provide everyone with the big picture.

Process

Whether Waterfall, Agile or Dual track, describe the process you use to ideate and build solutions for your customer’s needs.

Product map

Managing your product with todo lists can be daunting, it makes hard to know if there’s something you are forgetting.

Instead, creating a high-level map of each solution will help the team understand what’s being built and manage the effort.

Roadmap

Get everyone onboard with priorities sharing a high-level view of your Roadmap. A diagram with a reference to your tool of choice can be just enough.

How can I start using a Product System?

The goal of a Product System as presented here is to bring clarity to the team and ease the workload. This can only be true if benefits outweigh the effort.

As a rule of thumb to build your own, the degree of development of your Product System—the amount of work you put in—should correspond 1:1 with the degree of development of your product.

Start small

For instance, the founding team of an early stage idea company could start with as little as printing out a diagram of it and stick it to the wall.

Doing anything more than that should always be well worth the resources.

Keep it clean

This should be the place where you condense—as opposed to expand—product knowledge to make it accessible and actionable.

Keep it uncluttered.

A team member should spend the least amount of time possible browsing it while finding useful to get back to it often.

Keep it up to date

Revisiting your Product System regularly is the whole point of having one. Use it to facilitate the discussion about the health status of your product, come up with new ideas and keep track of what you learn along the way.

Thanks for reading. We will share more of our learnings and updates on this topic. We’d also love to hear opinions, feedback or questions.