July 11, 2019

Creating a Design System part 1 – Creating a ‘T’ Shaped Artifact

By JeJun Lee

‹ Back to News & Insights

During design sprints, my team produces the artifacts necessary for engineering and product development. Each artifact has its own purpose, and we spend a lot of time iterating to make sure the correct information is captured and we are set up for success when a project reaches the engineering phase.

Here at Intersect, we are driven by a systematic design approach, and a component guide plays a crucial role in this. Here’s our definition of a component guide:

A Collection of reusable components used to communicate amongst designers, engineers, and stakeholders to ensure we design and build only once.

As a result, a cohesive component guide should improve consistency and save time creating new screens. Aside from the benefits we all know, I want to showcase a few things I learned while I was working on a recent project and how we leveraged component guides to improve our overall process.  

Concept design and finding its gaps

At the end of our typical discovery phase, we deliver a prototype with a vision of ‘what it could be’. Once the product moves on to the build phase, we take the prototype and turn it into a production-ready design. The prototypes are used to validate a business, strategic, or customer experience challenge. They are typically a ‘happy path’ flow, taking a user from a set of desired flows. Once we move to an engineering phase, designers, solutions architects, business analysts, and engineers work together to tackle design sprints one by one. 


(A snapshot from the concept design of a banking app.
Top: Your recent transactions for a chequing account.
Bottom: Details of a single transaction)

After going through requirements and BA stories, we realized there are lots of questions left unanswered when looking at a set of screen designs. 

(Not all requirements are captured in the initial design)

At the start of a design sprint, my immediate reaction as a designer is to estimate how many screens I need to design for this sprint. It would be easy if someone just gave me a list of screens I need to design or wireframes. But that’s not the case nor how we work.

After getting myself familiarized with the requirements, I have a rough list of the variations I need for the screen design.

With simple math, if I have to design every single state of this screen, it has 9600 variations. 

Working smart 

As a designer, I really really don’t want to create 9600 screens… Hence, I will leverage the component guide to EXPLAIN the rules behind it, so they can derive the screen design they are looking for on their own.

To do this, I stepped back and thought about how the screen got created. 

As you can see, the screen is built using these five components, and each component has different variations. So in the component guide, I want to explain the screen’s construct using these components.

One thing to keep in mind is:

  • It’s NOT the screens that have states.
  • It’s the components that have states.
This is 9600 screens worth of information

Now we covered what the screens will look like in different scenarios and the components used, BUT there are still some missing pieces.

What about the conditions and rules that trigger these state changes?

In a typical scenario, these rules are first captured as business requirements. At Intersect, we translate these into user flows so it can clearly communicate how users will face these requirements during their experience with the app.

But it doesn’t always have to be

Going back to the above example, if user flows were the only artifacts to capture all the rules and conditions, we might be facing one massive flow that will take hours to understand. 


Handoff process of a typical design process

A linear process like this will result in one bloated artifact and redundant information as it trickles down to later design process.

In this sprint, we moved away from the linear process. Since the component guide and design was already created, the guide acts as a framework to address the many iterations and states of a single screen. This led to some interesting new developments:

  1. Requirement documents started to adapt to the structure of the component guide.
  2. Since requirements are more aligned to our artifacts, user flows didn’t have to capture every single requirement. Flows became more lean and simple.
  3. There was now less number of screens to design as the component guides illustrate what different states would look like.

At the end of the day, we are just trying to achieve one thing: Creating a lean and scalable collection of information to build a feature


Example: Snapshot from a requirement doc leveraging component guide

The entire design process during this sprint became more organic and collaborative. Each of our artifacts were leveraging each other.


Together, we complete each other

As a result, we observed how one artifact became more ‘T’ shaped. A mere component guide was leveraged by not just the design team but also the business and engineering teams.

Things to keep in mind 

After this sprint, I learned that the way we create artifacts doesn’t always have to be exactly the same. With more context, there is always more room for you to improve.

  1. Be proactive about understanding/chasing the information required for you to execute.
  2. Always be collaborative. This was possible because our team was always communicating.
  3. Think about the users. In this case people who are viewing your artifact. What information do they require to do their job? How can I make it as clear as possible for them?   

Conclusion

Using the process outlined above, the guide becomes a source of truth for the entire product. Not just for designers and engineers, but product managers can use it to define the product and change management, SA’s can address scope, and BA’s can leverage for business requirements. 

Work smart, not hard. 

"Subscribe", you say?