My Design Process
The techniques and methodologies I employ to get the job done.
Breaking it down
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. But it’s important to have a framework nonetheless.
That said, this is generally the design process I’ve formulated for my team. It’s come about over years working on products with multi-disciplinary teams. Read more about some of the ways I’ve organized and simplified our process as well as how I’ve made it visible and transparent to other teams.
Questions to ask:
- What is the Project High-level Description?
- Who is part of the team?
- Who are the stakeholders?
- What are the Business Goals?
- Metrics for Success?
- When is the project ETD?
- What are the dependencies?
- And when are their ETDs?
Actions to take:
- Outline Project Assumptions
- Define User Personas based on predicted user behaviors
- Determine Intended Outcomes/Deliverables
- Append any applicable outstanding UX Debt to project scope
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.
Let’s recap: the heart of design is 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 is so important that you start with a goal in mind, I cannot emphasize it enough.
I could go on, but I think you see my point. At the very least, be sure you don’t ever leave a kick-off meeting without being able to clearly articulate a problem statement.
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 supplement your perspective of the initiative. 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
- Update Assumptions
- 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
- Business requirements document (PM)
- Acceptance criteria (PM & Design)
- UX strategy document (Design)
This is the fun part: documentation time!
…not your favorite? That’s okay. I’ve made this step less painful by creating a template for UX designers to bring to kick-off meetings. It has helped us bring clarity and direction to new projects by aggregating all of 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. It not only provides designers with a way to document their perspective, it’s a great resource to reconvene with a PM at a later time to ensure you’re aligned.
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! Accessibility means everyone’s ideas are equal.
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:
- Ideation/sketching/design pitch
- 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
- Business leaders
- Define Project timeline (versioning)
There isn’t much to say in regards to what this part of the process entails. If you’re coming from a visual design background, this will be where you’ll really hit your stride. Generally, 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.
- Finalized Comps
- Technical Specifications Document
A similar practice I’ve introduced is weekly 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.
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.
Maintenance & Evaluation
A designer’s job isn’t complete as soon as devs have our deliverables. Often times 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 in a bit).
One step I do to ensure quality and parity between the designs delivered and the final product is what I call 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.
Actions to take:
- Offer Dev Support
- QA Revisions
- Design Audit
- Peer Reviews
- Exit Interviews
- Capture UX Debt
- Discuss next steps
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 following 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.
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!