As the leader of a product design team, I’m not just responsible for mentoring other designers on how to tackle big projects. I’m also responsible for ensuring other teams are aware of that process and evangelizing the importance of adhering to that process. Of course, not every project has to follow every step of that process. In many cases, projects will need to be approached in a way to address its unique challenges. But it’s important to have a framework as a reference nonetheless, especially when your job is to advise others on what the process should be.
That said, this is generally the design process I formulated for my team. It has evolved over the years while working on products and with multi-disciplinary teams. Read more about some of the ways I’ve organized and simplified the process my design team used as well as how I’ve made it visible and transparent to them and to other internal teams.
Every project begins with defining the goals and objectives. Sometimes it can be difficult to really pinpoint what the concerns we need to address are. I’ve worked on projects that have cycled through seemingly endless iterations because the Product Management team had been told to deliver a product instead of a solution.
My personal definition of design is the process of solving a problem. Without a firm grasp of what business goal to meet or user behavior to elicit, most projects will become an exercise in futility. It’s important that you start with a goal in mind. At the very least, be sure you don’t ever leave a kick-off meeting without being able to clearly articulate a problem statement.
Questions to ask:
What is the high-level description?
Who is part of the team?
What are the business goals?
And metrics for success?
When is the project ETD?
What dependencies are there?
And what are their ETDs?
Actions to take:
Outline Project Assumptions
Define User Personas based on predicted user behaviors
Determine the intended outcomes and/or deliverables
Append any applicable outstanding UX Debt to project scope
Once you have an understanding of what it is you’re trying to do, you’re still not ready to start designing. It’s important to do research to enhance and (in some cases) challenge your perspective of the project. Without this context, your team will likely end up redoing the project again and again, all the while wondering why you’ve fallen short each time.
Research can come from many sources. Typically, it’s helpful to have an understanding of what your competitors are currently doing (benchmarking). At the very least familiarize yourself with current trends and research reports.
Hopefully it goes without saying that you ought to have insight on your users’ needs and expectations. At times, this can be extrapolated from behavioral metrics (attrition, engagement, etc.). Whenever possible, it’s always preferred that some sort of preliminary research is conducted. Surveys can be a useful tool when you just need some numbers to get going in the right direction.
The last part of this stage is talking to other teams. Yes, I said it. Some of the products my team works on are built around extremely finicky services. Ask me about our Game Setup Tool if you want a great example. Better yet, don’t. Many of the projects I’ve worked on ended up coming to a standstill because we weren’t asking the right questions to all the right people. So cover your bases and ensure technical requirements gathering is a regular part of your process.
Information Gathering (interviews, past usability test notes, behavioral data, reviews, emails, etc.)
Outline Key Use Cases
From External Sources:
Benchmarking or Competitive Analysis
Review similar products and solutions
Investigate industry best practices
Determine technical dependencies (Services, FES, SDK, etc.)
Understand limitations from all relevant resources
This is the fun part: documentation time! …not your favorite? That’s okay. For most people, they’d rather forget that documentation is a very helpful step in ensuring that the project succeeds. I’ve made this step less painful by creating a template for UX designers to bring to kick-off meetings. It helps bring clarity and direction to new projects by aggregating all the findings from the previous two steps. I’ve even created a worksheet version so I can hand-write my notes straight onto the document and type up a formal copy for distribution later.
I created the UX Strategy 1-Pager after too many conversations where stakeholders and I weren’t on the same page, figuratively speaking. This template provides designers on my team with a way to document their perspective. It’s also a great resource to reconvene with a PM at a later time to ensure you’re aligned on the nuances of the project before continuing.
Business requirements document (if not already done by PM)
Acceptance criteria (PM & Design)
UX strategy document (Design)
This step is called informal design for a reason. No one should be jumping straight into a favorite tool for creating high-fidelity comps at this point. This is the stage where ideas should be flowing. The more, the better. If you hinder your ideation by being beholden to time-consuming tools, expect to frustrate yourself and your stakeholders.
My favorite way to begin this process is to whiteboard. The great part about this activity is most people feel comfortable grabbing a marker and doodling along with you. Product managers, engineers, other designers…even directors and VPs! The accessibility of the medium allows everyone to feel like their contributions are considered equally.
There are many different ways to produce a hypothesis. The trick is to use testing to learn and refine. This cycle should be repeated for as long as it’s needed. Once usability issues seem to be under control and the concept meets all requirements, only then are you ready to move on.
One thing I will add, it’s important that engineering be involved during this stage. Too many product managers will cloister away themselves and their designer until the concept is “done”…whatever that means. I advise the pms I work with to do what I’ve come to call tech checks early and often. Usually the cycle will be: test with users, review findings with the pm, iterate, present to devs. After all, what’s the point of designing a solution if it’s not technically possible?
This is a great time to update documentation. Review what the goals were, and ensure that the deliverables align with the intention. If any stakeholders feel that the scope is creeping, it’s important to recalibrate before moving on. The next stage is time-consuming and costly if your work won’t be used after all.
Informal Design Process:
Mind-mapping or user flows
Create hypothesis (wireframes)
Test hypothesis (paper prototyping)
Iterate from findings
Review with engineering
Repeat as necessary
Finalize Project Scope:
Review Project Proposal with stakeholders:
Define Project timeline (versioning)
I feel like this is where all the hidden problems start crawling out from under the floorboards. “Where was this requirement three weeks ago?!” is a common utterance. One thing I have found immeasurably helpful at this point is to collaborate with other designers. Sometimes a fresh perspective is all you really need.
From day one of leading our team, I’ve established a routine of a daily stand-up. Keeping abreast of what teammates are doing is made so much easier with this practice. It also gives everyone the opportunity to ask for peer review when they desperately need it.
The objective of this phase is to walk away with not only finalized full-color comps, but also a technical specifications document. This might include functionality flows, redlines, or any other artifact that will ensure your designs are implemented as intended.
Technical Specifications Document
Maintenance & Evaluation
A designer’s job isn’t done once devs have the deliverables. Often what seemed like an easy fix ends up being far more complex than originally estimated. There have been a number of times when I have been asked to create impromptu design solutions. Often times there isn’t time to test these, and usability issues can creep in at this stage (more on this below).
One step I do to ensure quality and parity between the designs delivered and the final product is a design audit. When QA has cleared most of the bugs from the JIRA epic, I will review the build on the test environment and review my findings with them. If needed, I’ll write up the issues as new bugs in JIRA and track progress in the comments of the tickets.
Many times, I’ve already begun this process for a new project by this point. However, as I alluded to earlier, there are many opportunities for unforeseen issues to pop up as the project comes to a close. Jack Moffett defines outstanding usability issues as “UX debt” in his book, Eliminate UX Debt. By adapting his prescribed methodology, I have been aggregating the UX Debt in our toughest projects.
With this list, I have been able to persuade the Product Management leaders the importance of moving beyond the MVP (minimum viable product). Now addressing UX debt is gaining traction from within as the smart way to maintain our growing products.
Actions to take:
Offer support to developers throughout
Make revisions as QA finds issues
Perform a design audit
Conduct peer reviews & exit interviews
Capture UX Debt
Discuss next steps with project owners
Leadership in User Experience Design needs to move beyond the momentary needs of a product or company. While it can be relatively easy to create deliverables for one-off solutions, a complex product requires eloquent planning. In addition to the tools and techniques I describe above, I maintain additional documents and processes to manage my team and our product development outside the scope of a single project.
One of the tools I employ to help with organization and distribution is Confluence. I lead a team workshop to define who our team was. This is used to inform other teams as to what our skills are and how to engage us. Some of the things we came up with include an overview of the team, our vision and mission statement, our values and design principles, previous year wins and misses, and current year goals.
The Confluence page is also our hub for templates, documentation, and educational resources. Essentially, anything that our team uses finds its way onto there eventually…including this design process!
Another practice I’ve introduced was twice-monthly meetings for just product designers. Product Talks, as I call them, were introduced to provide a dedicated time for us to co-mentor one another, watch webinars, and do other professional development activities. It helps designers refine their presentation skills, share learnings, and deep dive on topics they’re passionate about.