Alright, let’s get into it!

1. Assess the maturity of the practice

Every team sits somewhere on a continuum of maturity in terms of their and engineering practices. Some teams can be running smoother than a Swiss train schedule despite only having existed for a number of months, while others may have been together for years and are hamstrung in a number of key areas.

Understanding where the team you’re working with is at will help you identify where you can add the most value, and also foreshadow where you may encounter challenges.

Maturity model adapted from Inzovu and UX Matters.

There are two main areas you can to look at to get clues about the maturity of their practice: a) Craft, and b) Operations.

“…the Design you build will be shaped by them…”

a) Craft has to do with pure design capability of the team members and the activities they are empowered to do. This includes a lot, from the research and data gathering methods currently in use, to the presence of divergent and convergent design thinking, to the skill sets required to create a beautiful interface that solves a real problem with a high degree of usability — and more!

For example, if you’re working with designers accustomed to defining all the interaction states for a component then you’ll likely avoid time spent educating them about those different states and making that a habitual part of their process. If not, then something that fundamental could take weeks.

When it comes to research, many companies don’t have meaningful ways they listen to their users and aren’t comfortable with the close-up nature of human-centered design methodologies. The path getting them there can be long and littered with political barricades. After all, the behavior that gets employees rewarded in many traditional business settings can be at odds with the open-ended, more-questions-than-immediate-answers qualities of design.

You can get a rough feel for Craft by interacting with some of their products. I recommend supplementing that with a series of 1:1s with key people on the team. You’ll get to hear their more candid thoughts which will help you triangulate where the true strengths and opportunities for improvement exist in their practice. It’s important to remember that this shouldn’t be a secretive endeavor, and isn’t intended to find “weak links” or be exclusionary. Do it in a way that is transparent, and respectful to the people and setting you’re in.

b) Operations — Or as it pertains to Design, ‘DesignOps’, as many are calling it. It is the surrounding structure that supports the Craft, and can be greatly influential in propelling or limiting the team’s ability. Forces such as recruiting/hiring practices, how designers/devs are positioned within the org chart or on projects, having a culture of feedback and critique, governance & workflows, tooling, and the KPIs driving decision making are just some of the high level areas that comprise DesignOps. Those 1:1s will also shed light on the inner workings from the operational side.

Building a design system with your client doesn’t mean every factor within the craft and operational areas is going to evolve in your time on the job. However, all that is to say with certainty that the Design System you build will be shaped by them. Probing a bit and making observations about various aspects of their practice early on will help you navigate your road ahead.

2. Conduct an inventory of existing UI Components

This is a common step listed you’ll read about elsewhere, but it belongs here too. Invest time upfront to perform a UI inventory of the relevant pre-existing components, applications, and interaction patterns, so that everyone is on the same page about what’s in use.

I recommend starting this activity by actually printing out designs on paper and taping them up in a meeting room wall where everyone can freely look between them, which should spark a lot of good conversation.

Inconsistencies, scalability issues, and usability problems should become more evident from the start, helping your team prioritize your backlog. Just as importantly, doing so can help reduce friction and prevent the team from hanging onto an inferior element just because it has the precedent of being already in use, or due to emotional attachments. It also helps avoid the scenario of building something from scratch only to find out a version of it existed already that is good enough! Just as importantly, it will begin to establish a shared language across the team as to what elements should be called.

3. Establish some guiding design principles

In addition to setting the goals of the design system itself, take time at the start to write out some high-level principles. They should voice the intrinsic product qualities you wish to exude through the design system. Having a set of principles to look back on will come in very handy during the numerous moments you’ll be judging the merit of two design alternatives, and all things seem equal at first pass.

An example: My team was building a design system where the end users of the applications were aviation mechanics. Their current tools and day-to-day communication involved a ton of technical industry jargon and abbreviations. Based on the finding that it takes a new employee a year to achieve basic competency with tools we were replacing, one of our objectives was to shorten job training time. Therefore, we drafted the principle:

“Use everyday language whenever possible”.

Following this principle resulted in a series of guidelines that demonstrated how to write instructions, form questions, and other content throughout the products in a fashion that worked to help new employees learn key concepts or phrases more easily, while avoiding being overly wordy.

A starting-point agile model for building a Design System. Many here are related to items listed in Iteration 1.

4. Zero in on a Visual Identity

It’s easy to rush into producing components on day one. In fact, I can almost guarantee there will be some pressure to do so. The trap here is that if you don’t step back and ask, “how should the different pieces of our system look and behave in a way that reflect our principles, user goals, brand, and overall mission?”, then you may end up with a collection of components and patterns that aren’t truly unified. The result can feel disjointed or underwhelming. If you have multiple visual designers churning out components, it’s even more likely for this to happen.

To avoid that pitfall:

  • Have the team collaborate on some mood boards, curating screen shots of various products, designs, or general styles they admire and want to emulate in some way.
  • It’s also very worthwhile to survey other design systems to borrow some direction. Gather these materials together in the same room and through discussion pull out what it is exactly about the designs that you like or dislike. Here’s a good reference site for getting acquainted with the other design systems out there:
  • From that, have a talented visual designer (or two) spend a couple days mocking up a representative sampling of components, backgrounds, and containers that set the overall visual identity you’re aiming for. Rounded corners? Bright or muted colors? Completely flat or usage of drop shadows to communicate depth? Questions of that nature should come to the forefront and be answered. Doing this early on won’t lock you down as you can always change, but it will set you off in one direction instead of five!

5. Demonstrate an Return on Investment early

“…if you ship a component that removes that thorn in their side within the first couple weeks they’ll start skipping through the hallways singing about your  work.”

Or you might say, “ship early and often”.

While the value in building a Design System might be a no-brainer to you and I, you should keep in mind that it can still be a foggy concept to some stakeholders or product owners. Someone allocated part of their budget to the project, and others are likely experiencing some pain point in their world that the Design System promises to solve. Some can even be resistant to it entirely as they fear it will impact their product or timeline negatively.

The counterpoint to all the level-setting “do this first” steps I’ve made above is that those individuals want to see hard evidence of progress in their actual products, and sooner than you think.

For that reason, it’s best to identify a few components that are causing headaches among users or stakeholders and tackle them quickly. If there are no immediate headaches, pick some low hanging fruit. Make a habit of regular smaller releases rather than big reveals, and work to get the components officially integrated into the products as soon as you can. If you don’t, the pressure on your already high-profile project can intensify as folks may begin to question the value of the initiative. Conversely, if you ship a component that removes that thorn in their side within the first couple weeks they’ll start skipping through the hallways singing about your great work.

6. Find a realistic governance model

The team must identify the necessary processes, people, and responsibilities required to maintain and iterate on the Design System after the first big push. Otherwise, it just becomes another artifact that no one owns, or worse, uses.

The key from a people-standpoint is having open and honest conversation about who will own the future maintenance and development of the design system, what their current job entails, and how their priorities will be managed. Short of creating an entirely separate “Design System Team”, the reality is that some people are going to have more put on their plate. If a particular person seems to be constantly behind on their work, then they aren’t a good candidate to review and approve code in a timely manner.

Map out an intended workflow with the team from the moment a need for change is identified through to when that change goes live, and after.

Ask questions like:

  • “Do the people pegged to be the Design System keepers have autonomy to make a change or must they get approval from three higher-ups?”
  • “How does tooling impact the workflow?” For example, if your Design System is not powered by a Content Management System, then it may be that non-technical teammates can’t directly edit it, and even the smallest update requires developer intervention. (Yikes! Use a CMS whenever possible).
  • “What are agreeable turnaround times for a new component, guideline, code review/push, etc.?”
  • “How do we evaluate a voiced need and determine if it is something that should be addressed by the design system?”

Being brutally realistic about these types of questions will help shape a governance model that can actually be held up. In the meanwhile, the team can identify long term needs around people and processes that they can put in their road map.

7. Everyone has a role

If you’re brought on to support an in-house design team because they’re too occupied to push the pixels and write the code for their own Design System, then there is a risk that some members of the team will be detached at moments throughout the journey. This is unfortunate not only because they’re the ones who will be using and must understand it, but also because you can miss out on valuable feedback.

To combat this, consider getting people to commit to micro-roles. Micro-roles can include performing a bit of code QA, being brand-cop, or reviewing the accessibility of a component, among others. This tactic will achieve two things:

  1. Help distribute the work and keep you moving forward.
  2. Keep their eyes on the output so any objections are raised in a timely manner, rather than weeks after you’ve moved onto the next thing.

8. Budget more time for copywriting and documentation

If you want to have a design system that describes in words to the reader the principles, guidelines, “do’s and dont’s”, and other reasonings behind the system, then you can depend on spending more time writing and editing than you anticipated.

It’s best to designate someone who’s good at writing as the official copywriter, and make it a considerable part of their role. Having someone tasked with copywriting should help in maintaining a consistent and coherent voice from one area of the design system to the next.

A sample of instructional copy around Accessibility from a recent design system project. Writing takes more time than you anticipate, and spurs more questions for the team to answer.

9. Consider building on top of a UI Component Library

It seems like every time you hear someone talking about their awesome design system, it appears as though they built every component from scratch. While that may be the case for larger organizations like Google, Shopify, or Salesforce, I’m not sure how frequently that is the case for others. Doing so can be a very time and money intensive endeavor that not every org is prepared to undertake.

If you have a more abbreviated timeline to get things moving, then consider using an existing UI Component Library. There are lots of robust and technically sound options out there that can be edited to meet design requirements or philosophies. This can be especially good for a team building their first design system as the library developers have probably accounted for more technical considerations than you have time to address.

Of course, there are potential downsides to this approach, such as the scope of the library, support, and licensing fees. Still, many teams may find this most economical and fruitful route. Here are a couple that come to mind.

(I am not being compensated for including these links)

If you want to hitch your wagon to the Material Design language, then there’s:

. If you’re using Sketch nested symbols, figure out the naming in advance!

Alright, I admit this one is more nitty gritty than I said I would get, but it bit me so I figured why not?

If your team happens to be using Sketch for screen design and you’re keeping a symbols library that acts as a static representation of the coded components (most do), then to keep organized you’ll likely be using slashes in the names of your symbols to enforce organization within the library menu. Doing this is especially helpful to separate top level master symbols from nested symbols, if you chose to do so (highly recommended for ease of use!).

At the time of this writing, there isn’t a really efficient way to rename components or layers quickly without using a plugin like Sketch Symbols Manager or Rename It. You have to do it one by one manually, and if you keep putting it could be painful later on.

So, trying to align on the symbol naming conventions and hierarchy ahead of time will avoid that and also help in establishing a shared language across the team. Hey, maybe this one has a bigger purpose after all.

Renaming symbols and nested symbols is not very fun!

Thanks for reading, and to my teammate, Eva Forrest, for helping me put this list together! I hope it was helpful in some way. Please leave a comment and let me know about your experiences, or what you would add.

Source link


Please enter your comment!
Please enter your name here