uxdesign.cc – User Experience Design — Medium | Jules Cheung

A practical workflow to manage design projects

“What’s your team’s design process?” This is one of the most frequently asked interview questions and one that I’m excited to share with interviewees. It’s easy for me to answer this question now but this wasn’t always the case. Previously I had a hard time conveying design culture because process was nonexistent. In fact, this lack of shared process presented several challenges within our team.

Problem 1: Unclear team culture/vision

Lack of process was a symptom of deeper problems around team culture. Even though we belonged to a team, it didn’t feel like we united in vision. Without clear purpose and structure, design get-togethers dwindled and the team felt further fragmented.

Problem 2: Designers worked in silos

Product experience suffered because siloed designers used patterns inconsistently and didn’t solicit feedback from others. At times I’d even discover new design patterns during development! A lack of sharing ideas and communication among teammates contributed to this problem.

Problem 3: Bad copy discovered in production

Bad copy showed up in live products because the team overlooked copywriting. Even when we had access to copywriters, people denied taking responsibility for this problem and finger pointing ensued.

This presented an opportunity for me to develop a design process, one that could be easily referenced and promoted across the team. It was also a catalyst for conversations around building team culture and collaboration.

I was inspired by high-level processes like d.school’s Design Thinking, IDEO’s Design Kit, and How to apply design thinking from scratch. I find these methods great for reference but still too high-level for real product development. I’ll share my interpretation of the design process and how to apply it in practice.

The design board

The design board is a virtual board that helps designers visualize workflow, and it’s inspired by the Kanban methodology used by agile development teams. Work items are represented as cards that move through different stages of design.

A basic kanban board consists of three steps: to do, in progress, and done. You can create a simple board using free tools like Trello or Taiga. First create a card for each project within the To Do column. Move the card to In Progress when you start working on it, and move it to Done when it’s completed.

The design board is a bit more complex and consists of 10 columns representing steps within the design process. I used Atlassian JIRA (paid subscription program) to create the board.

Note: I’m less adamant about following Kanban best practices for project management, so feel free to consolidate steps within this workflow.

The numbers on top of the board represent tickets (JIRA term for cards) within each column, and clicking a ticket reveals more information about the project. I encourage designers to document as much of their research and thought process within tickets.

Why? We often refer to old tickets for new projects or hand-off projects to other designers. In either case, good documentation is useful to recall or understand why design decisions were made.

Designers start a new project by creating a ticket within a separate design backlog board. This serves as a repository of tickets to be worked on in the future. My backlog usually contains ideas for various projects and UX/UI issues to be revisited. Here’s an example of a design ticket in JIRA.

Next I’ll dive into the details of the design board.

To Do

When tickets are ready to be worked on, they’re moved from the backlog to the design board’s To Do column. Work hasn’t started but managers can glance over this column to anticipate projects coming down the pipeline.

Define Scope

The first step of the design process, Define Scope, is to conduct preliminary research to understand the purpose of design. I created a template with several key questions to answer.

• Problem — What’s the problem you’re trying to solve? Frame the problem in a way that’s easy to understand.
• Goals— Who are the users and what are their goals? Every element in your design should be justified by a user need or goal.
• Relevant Research — If there’s existing research related to this problem, how can it be incorporated into design?
• Constraints — Are there existing or anticipated constraints?
• KPIs — How do you measure success? Knowing KPIs (key performance metrics) empower designers to think more strategically about the business impact of design.
• Flowcharts — Is it useful to map out flows comparing current vs. proposed designs?

Answering these questions will help designers engage with stakeholders and perform their due diligence to make more informed design decisions.

Wireframes in Progress

Designers should now have a solid understanding of the problem they’re trying to solve. The next step, Wireframes in Progress, is where they explore various solutions via wireframing.

I typically create wireframes that are super low-fidelity using comic sans. It prevents me from getting attached to a particular direction and focuses my attention to UX flow instead of visual design. The benefit of making wireframes purposely jarring is that it instantly communicates “this isn’t final and is subject to change!”

Design Check

It’s always valuable to solicit feedback to avoid spending time going in the wrong direction. Wireframes are shared with other designers during the Design Check step.

This prevents designers from working in silos and is informally done through slack or in-person. If major changes are needed after this step, tickets are moved back to wireframes in progress and the cycle restarts.

Copy

The Copy step involves reviewing and updating all copy within wireframes. I’m fortunate to have access to talented copywriters who enforce copywriting best practices. They review designs, submit copy changes, and hand tickets back to designers to update wireframes accordingly.

User Testing

My philosophy is to test designs whenever possible because there’s always something to learn from users. The User Testing step entails testing prototypes externally with users or internally with coworkers. This step can repeat several times depending on test outcomes or project complexity.

Though external user testing is more expensive, it’s absolutely necessary when designing new or large scale features. Internal user testing involves grabbing coworkers who aren’t familiar with the product for quick testing.

Dev/PM Review

Designs that pass user testing move onto the Dev/PM Review step for a walk through of the prototype’s interactions. Everyone who works on the project attends this meeting including front-end devs, back-end devs, PMs, and UXR.

The purpose of this meeting is to discuss technical feasibility and typically results in two options: 1) pair down the design scope, or 2) proceed onward with the design.

Mockups

The Mockups step is where wireframes are transformed into high-fidelity mockups following the visual style guide. Companies with larger budgets can benefit from user testing after this step to gather feedback from more realistic-looking prototypes.

Spec

The Spec step is perhaps the most dreaded aspect of design where interaction patterns and mockups are outlined for developers. Spec time can be significantly reduced if the team leverages pattern libraries and grid systems. I find the 8-pt grid system and Atomic Design great for reference.

Done

Tickets that move across the design board are finally completed in the Done step. Hooray!

Our team periodically reviews this design process to identify opportunities for improvement. This process was created with the product designer’s workflow in mind and needs to be revamped for other design specialities.

Leadership sets the example when it comes to influencing team attitudes and adopting new processes. I definitely faced backlash when this design process first rolled out but over time, the team’s outlook changed as designers felt more empowered to fully own projects on their board. ✌️

If you liked what you read please give a ❤️ below! It gives me 💪🏻 to share more stories with you 🙋🏻

Jules wrote this story to share knowledge and help nurture the design community. All articles published on uxdesign.cc follow that same philosophy.

Building design process within teams was originally published in uxdesign.cc on Medium, where people are continuing the conversation by highlighting and responding to this story.