Building a Design System Without a Team

Update: I changed the title of this post from "Design Systems for Small Teams" to "Building a Design System Without a Team."  This is a more accurate description of the content of this post and addresses the key issues: building a design system when it is impossible to dedicate full-time resources. 

When a new design system is announced, I'm right in there with everyone else, digging into the public documentation website, examining the versatility of their responsive assets, clicking through to examples, and, of course, visualizing my own team's ability to do the same. But the shine wears off quickly and it gradually seems impossible.

Looking at design systems from AirBnB, Google, IBM... Eventually, there's a wake-up call: You're not in the FAANG. The design systems you're looking at online are built by dedicated teams, specialists hired to do that work. They develop specific skills and processes, whether they are full time members of the team or agencies with highly capable teams of their own. 

If you are on a small product team, it is unlikely that you are in a situation fitting the above description. You're more likely to be generalists and stretched thin. 

If you maintain the expectation that you will be able to deliver what those big teams deliver, at the same cadence, and in the same manner, you're going to have a long string of bad days. 

How am I going to pull this off with 20% of one designer's time and sporadic development commitment? We can't be this detailed or specific or thorough. We can't dedicate a team to the design system. We don't have engineers dedicated to the design system. We can't even fully dedicate a designer to the design system. We don't have a 'design ops' person, let alone a team. 

Your Responsibility

I'm speaking here to design leaders. That may include senior IC's. That may include management-only types. But If you're someone who takes on the design system project and helps define the process and infrastructure for creating and maintaining that system, then I'm talking to you.  

For the sake of this discussion, a design system lives in four places:

Design Assets: The library of assets that designers use in their work in accordance with the design. Sketch symbols, Figma components, etc. These tools are specifically for the design team. 

Codebase: The front-end code base, that lives actively in production that executes the design ecosystem, reflects the design tools. This is specifically for the engineering team. Naturally, in organizations where designers also code, there can be relationships drawn for collaboration & contribution, again depending on the team's dynamics.

System site: A realization of the design ecosystem in the format of a publicly accessible site. This tends to include visual examples and code snippets for each component. This also reveals the taxonomy and hierarchy of components, along with the intentions and limitations around their use. There are ways to split the responsibility for this between the design and engineering teams, depending on the team's dynamics. 

The design ecosystem: devoid of medium, this is the set of rules and guidelines made visible that define the brand, product, and resulting experience. The design team owns this, in tight collaboration with stakeholders like content strategy, marketing, leadership, etc, if your company has each of those. 

A functioning, living, breathing design system will be realized through the creation and maintenance of these four things. 

So, what first?

While you may not be able to commit a full-sized team to the effort, the system will need an owner, an individual contributor on the team who can be the steward of the system for the long run. This does not mean they need to be the final arbiter of what goes in the system, although that can help a lot. On my team, it was our intrepid designer Mai who took the reins. 

Out of the four concentration areas, you need to start somewhere. I advocated for starting with design tools, namely a pattern library for the design team to use while creating new designs.  

It may sound selfish, but if you have any hope of propagating any design standards through the organization, you have to start with the design team and assure that work in flight is designed to spec with consistent execution.

Build out a shared library of patterns for the team. Make sure everyone is using the same grid, type, form fields, buttons. As projects com into the team, apply the new assets. Look at every project as an opportunity to bring more of the digital experience into alignment.

Keep your side of the street clean. 

Gain allies

Seeing the design team get in order and deliver consistent, high-quality work has a positive downstream effect as work is delivered. 

Development team members, realizing that the work from the design team is consistent, will soon realize that they save time component-izing their work, too. The challenge is getting both teams to accept the immediate reality that components in the code base will just trickle in, project by project, Jira ticket by Jira ticket. At this point, there's a bit of a leap of faith; building components in the hopes that components will make a system.  

It's not unreasonable for members of any team to second-guess the need for a design system. It is reasonable, predictable, and manageable. 

Project by project, the components stack up, and the proof is in the engineering team's estimates; as components take hold, front end estimates shrink due to efficiencies built in re-use.

My team saw the best results focusing on projects that included form fields: the components are a little complex so the savings associated with reuse is significant.

Gradual Reach

Two more tools can be powerful in extending this lightweight approach to building out the design system. 

A kanban board with tickets created for each component to be made. First column on the left is a great inventory of all components that have not yet been built as part of any project. Final column on the right is components released to production. A few columns in between for design stages, accepted for for development, etc. We've used this simple set up as a complement to what's in the codebase.

A tool like Zeroheight helps a lot for building out a first iteration for your system site. Those geniuses have set up a way to point their site at your Figma, Sketch, or XD pattern library file and--BAM!--it spits out a site of the design system. Not bad! It makes another great tool, in conjunction with the kanban board, for engaging an engineering team on the intended output of the design system.

Once there is some momentum in place, then it sets the stage to begin conversations over the design ecosystem. How can this system be extended to other design materials, content strategy, and brand assets? In some ways, it feels remedial to revisit the system from these other angles, but it is part of the process of extending the reach of the system.

Leveling up the product experience this way takes time, but it gets there. It's cheap, it's scrappy, and it's doable when there's no team to commit to the work. 

So, don't be intimidated by what IBM, Google, Adobe and other big companies are doing. The most important thing to do is to make progress in standardizing the experience of your product, period. On a small team, it doesn't have to happen overnight. 

The 6-1-1 Sketching Session

What's all this then?

A 6-1-1 is a structured sketching exercise. You may recognize it as a miniature version of a design studio workshop (example) or you may also see that it is very similar to some of the methods popularized through Lean UX and Design Sprints. I developed the 6-1-1 as a lightweight workshop while at LivingSocial in response to two main forces:

• the emergence of Jeff Gothelf and Josh Seiden's work in Lean UX, which I found very influential and was implementing at the office as a practice
• the energetic environment of the company; exciting and creative but sometimes lacking in direction and focus.

When to do a 6-1-1

When you have a problem that you are trying to solve and...

• You are having trouble coming up with solutions
• You are having trouble agreeing on solutions
• You are having trouble focusing on a solution
• You need input on solutions from a diverse group of stakeholders
• You need to get shit done fast
• You need to get a lot of input from a a lot of people and bring focus to that direction as quickly as possible

In any of these cases, or in any combination of these cases, a sketching session can act as a powerful tool for bringing alignment and buy-in within your team and ultimately with the greater cross-functional set of stakeholders involved.

Prep for the session

Write a clear and concise problem statement. The session itself will rely heavily on understanding of a problem. Do the work; research and clarify a problem that you are trying to solve. If you don't have this, the session will crash and burn.There are numerous effective formats and structures for problem statements (user stories, jobs to be done, etc), so use the one that you and your team find effective. Make sure it includes:

• who is affected by the problem
• where and when they encounter the problem
• what the problem is

...but leave it at that, and be very careful not to bias the conversation towards a solution!It's worth pointing out the importance of emphasizing who is affected by the problem. Communicating the affected person, in the form of a persona, is a powerful method for gaining the empathy required for your 6-1-1 participants to put themselves in another person's shoes.Gather the materials. Don't let anyone off the hook because they don't have a pen or a piece of paper. Get everything that will be needed ready in advance.

• Room with whiteboard
• Timer (phone is OK, but something bigger/louder is usually better)
• Pens, pencils, markers, etc.
• 6-up sheets for first round (paper with 6 boxes on it)
• 1-up sheets for the 2nd round (paper with 1 box on it)
• Big post-it pads for the final round

Find a cross-functional group of people. If you only invite design and product people, then you're going to have a bad time. Actually, the session might go really well, but you'll have a bad time when you end up releasing a product that only works for designers and product people. Mix it up. Definitely get people involved who talk to your customers on a regular basis; phone reps, field reps, etc. Get your development team to leave the cubicle behind for a couple hours--BONUS: getting your development team involved now will set a collaborative foundation that will pay off later. Get content people, finance, legal, executives--anyone who has a perspective on the customer experience.Prep the invitation. The invitation is actually pretty important. Since this meeting is a lot more interesting than some boring old status update, there is a chance that people will actually read the invite. So,  it should include:

• An explanation of the sketching session
• The problem statement
• Assurances that they don't have to be great at drawing (more on this in a bit)
• Complete and detailed agenda
• An optimistic tone that shows everyone on the invite that they'r opinion is valuable

Set up an after-party. One the sketching session is done, you will need to meet with leadership to validate if this approach works and outline for them how you want to move forward. I recommend having this very soon after the sketching session.

Example  Meeting Invitation

Here's an example of what to include in the meeting invite:

You are cordially invited to attend a sketching session for our ####TOPIC###. We’re going to run through a 6-1-1 sketching session, ending with our direction for a new prototype.Problem Statement: ####insert problem statement here####A note on sketching: Please remember that this is not a drawing exercise. The objective here is to communicate ideas that could solve the problem. If you can draw a triangle, a square and a circle, then you can draw some representation of every interface that has ever been designed. Finally, Don't be afraid to be unrealistic with your ideas. Our most unrealistic ideas often become our most innovative solutions.

Agenda

Seeion time: 90 minutesDiscuss the problem: 10-15 minutes We'll start by making sure we all have a complete and shared understanding of our problem.Sketching, 6-up: 8 minutesOn a 6-up sheet, sketch 6 ideas that address the problem.Discuss & critique: 5 minutes per personAt this point, everyone in the session shares their ideas. It’s important not to judge any of the ideas at this time in terms of feasibility of even sensibility.All ideas are available to trade and steal.Sketching, 1-up: 5 minutesAfter consolidating (stealing) ideas from each other, each participant creates one sketch that reflects the best approach to address the problem.Discuss & critique: 5 minutes per personAt this point, everyone in the session shares their 1-up ideas.All ideas are fair game: trade and stealSketching, Collaborative 1-up: 15 minutesOne person assumes the role of the draftsman.The team collaborates on a final sketch that represents a single, consolidated approach.Output & next stepsSketches, ready for business validation, for use in creating stories & prototypingparking lot of other ideas

Before the session

• Get in 10-15 minutes early.
• Distribute the materials around the room
• Write your problem statement on the whiteboard.
• Write the rules on the board (more on that in a minute).
• Set out any refreshments you might have brought.
• Get ready to greet everyone with a smile.

Begin the session with rules

Welcome everyone to the session and thank them for their time.Start off with the rules of the session. I like to use the rules to set the tone: fun, a little irreverent, but focused.Rule #1: No job titles. Emphasize that everyone has something to add from their area of expertise. I like to take this opportunity to call out any senior leadership in the room if I have some rapport with them, "Hey, for the next 90 minutes, you're not the CFO, you're not anyone's boss, but you are someone who knows a lot about corporate finance and markets and for that, we need your help."Rule #2: No drawing, only sketching. Sometimes I like to show a picture of some really amazing pencil work like MC Escher, Leonardo Da Vinci, or maybe mix it up with one of those charcoal drawings of Tupac that you get at the boardwalk. Then emphasized that we're not here to draw, we're here to sketch. I like to do something that I heard from Jeff Gotthelf in a LeanUX workshop; I draw a square, a circle, and a triangle on the whiteboard and tell them, "if you can draw something like this, you can draw every computer screen or mobile app that has every existed. Stick figures are OK, even welcome. We're not here to be artists, we're not here to make it beautiful, we're here to solve a problem and communicate with each other."Rule #3: It's OK. If you sketched something and it didn't quite come out the way you wanted--it's OK. If you didn't think of as many ideas as you wanted--it's OK. If someone else at your table is running away with it or is falling short--it's OK. If you feel overwhelmed or confused, ask for help--it's OK. No one is getting graded on their performance, this isn't going to go on your review, just listen, sketch, and relax.

Get to know the problem

Ask someone in the room to read the problem statement off the board and ask them what it means. Then ask, "who else knows about this problem?" Listen and course correct if necessary. Then ask for another perspective from anyone else in the room. Refine the problem statement if necessary. Be ready, just in case, to defend the problem statement without being defensive. Outline for everyone that solving this problem statement is their objective for the day.

Facilitation

As you guide the team through the scheduled exercises, keep time and keep a positive spin on the activity.Sketching, Round 1, 6-up instructions: We're going to start with the worksheet you have in front of you with six boxes on it. Before we start, write your name and the date on the sheet. OK, so, we're going to come up with as many solutions as possible to solve the problem we just talked about. Crazy ideas are welcome! You can work through the same idea more than once because you might kit it from a different angle the 2nd time around. You can imagine unlimited technology and resources and everything works all the time--no limits, nothing is too crazy, nothing is too boring, nothing is impossible. Any questions? 8 minutes. Go.Timer: 8 minutesSharing, round 1: OK, so now that we're brimming with ideas, we're going to share them with each other. But, and this is very important. The only thing we are going to do is share them. We are not going to critique them or offer feedback, but only to share. As you go around the table, each person gets about 5 minutes. While other people are talking, take notes on things you think are a good solution to the problem, you will use these in the next round.Give them about 5 minutes per person. If you hear feedback or critique beyond any reactive "I like that" or "that's interesting" then remind the team to stick to sharing and we can build on the critique in the next round. Sketching, Round 2, 1-up: OK, sounds like we had some great ideas within the group. I saw some great sharing, and heard some great ideas. Next up we're going to use the sheet with one big box on it. Put your name and today's date on it if you haven't already. So, we're going to approach this round a little differently. We talked about our problem (read the problem). We sketched up all kinds of solutions. You took notes on the solutions that you heard and you have your solutions that you came up with. Next, on the sheet with one big box, I want you to sketch the 1 approach that you think would be the best solution to the problem. You can integrate the solutions from other people in the group. All ideas are fair game, so you can steal other people's ideas, remix them, turn them upside down and backwards, and re-imagine it as one solution that you're going to sketch on this sheet. And you're going to do it in under 5 minutes. Any questions? OK, 5 minutes, go!Timer: 5 minutesShare and critique; OK, time's up. Next we're going to share our ideas, but we're going to do things a little differently. We're going to go around the group sharing our solution. I want you to listen for themes that emerge as people share their solutions. What do these solutions have in common? What bubbles up as a good idea within the group? Take some notes of the key themes you hear and write them on your sheet. Go ahead and share, about 3-5 minutes per person.Time box of 3-5 minutes per person. The team shares their work with each other and themes start to emerge. Facilitate the conversation towards capturing themes.Sketching, collaborative: OK, it's time to pull it all together. What were the themes that emerged in your discussion?Someone from the group read the themes, write them on the whiteboard.OK, fantastic. Next, let's elect a draftsman from the group--you take the marker. Now, we'll work collectively on the giant post-it-pad to try to weave these themes together. As we go, we can talk through the themes.

• What stands out as a rock solid must have solution for the person that is described in the problem? For who they are--when and where they are?
• Which ones really make sense for us?
• Which ones stand out as something special, either a competitive advantage or something we do especially well?

Prioritize the themes to make it clearer what's a must-have and start sketching against those themes. Work through the list of themes until the output sketch meets the criteria.Review and critique the final sketch. Thank everyone for their time, creativity and effort!

What now?

Catalog the output. Once there is a final sketch, take pictures of all the sketch worksheets and catalog them all in your resource of choice: team wiki or whatever.Send out a thank-you note. Send everyone involved some sincere thanks and a link to the sketches. Remind them that they're making a valuable contribution as part of the design process.Develop a hypothesis. The design that was revealed in the session is, in and of itself, a hypothesis for solving the problem that you started with. Verbalize this hypothesis.Afterparty and validation. Remember that "after party?" Here's how that's going to work. Set up a presentation for leadership who may or may not have attended:

1. Walk through the problem
2. Outline the structure of the exercise
3. Take a minute to compliment all your participants for their intrepid contributions (this is what makes it an afterparty--the good vibes)
4. Outline the new direction and a hypothesis

Seek their validation and reality check. Is this a direction that you should pursue as an experiment? Is this something that our company does or could potentially do?The output of that meeting may require some refinement to your direction, but you should be in a good position to take the output sketch and push towards a prototype as quickly as possible.If you're cool and you have a mature style guide with prototyping templates ready to go, then hey, good for you. If not, your next step is to pull together something that works for you. The team at Google Ventures emphasizes that a prototype is meant to be a facade for an experience, and this is a good approach. This sketch should set a foundation for that facade; a direction and hypothesis for you team to investigate.I hope this explanation was helpful. I'd be happy to talk about it--don't hesitate to get in touch!

A Sample Design Collaboration Cadence

In order to maintain a decent level of collaboration within a design team, while maintaining a productive pace, and keeping transparent about upcoming roadblocks and needs for solutions, and finding opportunities to support each others in our design practice.... I ended up with a cadence of quick and straightforward cadence of check-ins and working sessions.This assumes that the members of the design team are not embedded solely with individual development teams, but are shared as a committed resource. Individual designers will be dedicated to team-specific meetings like stand-ups, groomings, etc, as necessary, depending on your organizational structure.

• Weekly, 30 min: Team meeting
  • The design team as a whole meets to check in on any news or updates that stem from higher organizational issues and raise any concerns for their own work.
• Bi-Weekly, 30 min: 1:1s for personal development
  • Could be weekly if needed, of course
  • Opportunity for mentorship and management, pursuing opportunities for growth. As a manager, I'm asking these questions:
    • What is going well? 
    • What could be going better?
    • What do you want me to do more?
    • What do you want me to do less?
• Bi-weekly: Team critique sesh
  • Designers take the initiative to set the stage for collaboration on their work through critique or other exercises
• Monthly: 1/2 day: Team boost sharing skills or presentations
  • Opportunity for designers to share more deeply and broadly with the team, showcasing skills, providing training to others, presentations etc.

A Design Practice

Over the course of my career, a framework has started to come into view for a establishing or augmenting a design practice. The framework has three key ingredients:

• Craft: What do you do?
• Infrastructure: What do you use to do it?
• Personal Growth: What are you getting out of it?

Attention to these three areas provides a foundation that is both flexible enough to work in organizations of different sizes and workflows, but clear enough to stay relevant under different methodologies.

Craft

"What do you do exactly?"This is the collection of executional tools we have at our disposal. This includes typical UX activities like card sorts, personas, prototypes, and critique, among others.

• Specific executional methods: typically the work that goes into design deliverables; personas, prototypes, card sorts, sketches, etc. There are dozens of options, appropriate at different stages in of a given design project.
• Participatory workshops: tactical, focused exercises such as kickoff meetings, research interviews, sketching sessions, etc.
• Processes: Executional activities and their resulting output is bundled into a process such as a Design Sprints or Lean UX sprint schedules, which provide a linear path for interactive discovery, design, and validation.
• A commitment to quality: throughout the above practices--and in many ways because of the above practices--there is a sustained commitment to quality. A thorough and focused practice keeps a designer performing at their best.

Infrastructure

"What do you use to do it?"This is typically what we would refer to as design tools; the software, team structure. But this concept goes further to include conceptual infrastructure like design principles that provide thematic support to all the aforementioned methods.

• Organizational infrastructure: team organization through clearly-defined team structure and roles--there's a lot more to this, of course.
• Technical infrastructure: software such as design and prototyping tools, file sharing, communication platforms, all of which facilitate the delivery of good work; also, reusable technical assets associated with style guides, templates, patterns.
• Facilitation infrastructure: provided through the use of meeting agendas and other materials that are re-used in workshops or other sessions--key for healthy engagement with stakeholders
• Thematic infrastructure: tenets such as principles, values, and methodology; tools that guide the team through tough decisions and elevate the team's thinking around solving challenges. Principles are the outcomes we seek in the work we create. Values are describe how we want to work. Methodology is the school of thought that ties together the methods at use on a project.

Personal growth

Everyone on the team is advised to approach every project as an opportunity for personal growth. I have found, historically, that not very many people look at their work this way, as an opportunity for growth. But those who do benefit both personally and professionally."What are you getting out of it?"

• Preferably, this starts with an introspective self-assessment to understand an individual's strengths and weaknesses and understand the need for addressing these opportunities
• Each project should be evaluated as a growth opportunity
• What opportunity do you have to improve your "on-screen" skills, the nuts and bolts of the design process?
• What opportunity can you find to improve your "off-screen" skills, your ability to work with stakeholders through facilitation, active listening, salesmanship, critique?
• Not every project has to be a growth opportunity, but we keep revisiting this as a means of maintaining that trajectory

Putting it in motion

High-quality design methodology, both in process and execution will always be critical to any high-functioning team. An efficient infrastructure liberates the team members from the burden of re-building and wrangling repeatable assets, cuts down on variability and error within the product experience, and removes the cognitive burden associated with smaller design decisions from the team while the work is in flight. But none of this is worth doing if it is not a vehicle for one's personal growth. We spend more of our waking day working than anything else and it should ultimately be a nourishing and rewarding experience.So I'll leave you with a hypothetical example of how a team would carry this through when starting a project.Let's say you start a project with a kickoff meeting (method). In this practice, the team would have a pre-set agenda for a kickoff meeting (infrastructure). The agenda had been tuned over time to assure that three criteria were met:

• Define the problem space and objectives
• Select design methods
• Make a commitment to complete the work

In the kickoff, the team works together to get a sense of what they need to do for the project. They refine and agree on a problem statement (method) and an objective that they aim to meet (method).Next, the team assesses what methods they want to use to reach that objective. Is field research the best way to get the qualitative data we need? Is there existing data from our analytics platform? Is Should we do a sketching session with the team to develop a direction for a prototype? Should we use the Design Sprint methodology for this problem?Finally, there is some assessment of the path forward, an estimation of how long it will take and, based on the needs of the project and the strengths and weaknesses of the people on the team (personal growth), a determination of who should do the work. So, if it's a mobile app project and a associate designer is looking to expand their repertoire with mobile, they could take the project on with a commitment from a senior designer to advise and mentor along the way, helping them ensure that the aligns with the team's values and the work is in line with the team's design principles (infrastructure).Naturally, once the team adopted this perspective, all their dreams were fulfilled!