Customize and clarify the ‘standard design process’ to fit your work environment
I didn’t realize that my design process had changed that much until I sat down and sketched it out.
I recently had the chance to assess how I’d like my UX group to work with writers, developers, and other organization members. This was where I saw the changes I’d made to my design process after running into issues with developer handoff, stakeholder access, recruiting participants, and more.
These changes weren’t just my personal preference: these were changes I’d made to the daily design process to match my working needs. Because yes, you should change your design process: you likely already have.
Never assume anything: present “your design process” to your team
One of the things that I’ve learned to do is never assume that your team knows exactly how the “Design Process” works.
It’s led to more misunderstandings, from developers building off of low-fidelity prototypes or product managers not realizing that we need multiple rounds of user testing.
However, it can be a little condescending if you explain IDEO’s Design Thinking process to them after someone’s probably attended a workshop or course on it. What’s more important, though, is that IDEO’s Design process is likely not yours.
You might follow the “Three Phases of Design Thinking” in the large picture, but your processes are different. Otherwise, you would be conducting five-week courses or five-day workshops where everyone on the team is gathered in one room to work through your problems.
You use different software, have different methods, and have different project timelines. So what do you (or your UX group) do as part of your design process?
That is what you need to present to your team. You might think those minor details don’t matter as much as the overall design process. You’d be wrong: that’s the most important thing.
Other team members can look up a YouTube video on UX anytime, but they can’t know the specific resources, software, and timeline you need to do your job. Certain people, like project managers, need to plan and budget around them.
So whether it’s a presentation or an easy-to-reference wiki, here are a few things I’ve changed about my process that help my team.
Gathering requirements and resources early into User Research
One of the things I’ve learned since working in Healthcare UX is to plan and be upfront about who you want to talk to.
User Research in Healthcare UX means that you often are talking with medical professionals with less time than you, so you have brief meetings, tag along with other meetings, or meet at odd hours.
So I’ve gotten used to my user research process being partially about scheduling meetings and finding people or documents and partially about the actual research process.
Making that clear to the team as early as possible can lead to better responses. They can point you to people you might want to talk to, help set up meetings, or perhaps help you elaborate on why. In return, your user research should help inform one of the crucial aspects of product discovery, understanding your users and figuring out requirements about the problem you intend to solve.
Establishing this early on can save you a lot of headaches in the future, as it lets your team know who you want to talk with and what you’re doing so that they’re not surprised by who you want to talk to or why.
Design with content writers looped in early
One of the first people I try to seek feedback from nowadays, after the product team, are writers. Of course, UX writers are ideal, but I’ve found that technical, content, and copywriters are excellent.
The reason I seek them out is simple: they can give very targeted feedback regarding the content of the current design. I’ve talked about how content last design leads to problems, but there’s one other main benefit: writers likely know why we should phrase things a certain way.
There may be legal, technical, or other reasons you must use a specific phrase or wording. Or, sometimes, your original phrasing means something different to your target audience. Either way, they’ll likely take a fine-tooth comb to the things you’ve written in your prototype.
They might not be able to assist you as you’re designing a basic sketch, but once you’ve assembled a prototype they can poke around in, they’ll be able to assist you greatly.
Create different types of prototypes for users and your team
Lastly, I’ve found that an important thing to do for your team is to provide different prototypes for your team and users.
I’ve often found developers don’t want to work with a moving target: once we’ve said that we’re ‘done’ with a piece and handing it off, they don’t want to see that we’re making changes in the Figma or Axure file (even if it’s on the next piece).
So what I’ve learned to do is to separate things based on rounds of user testing. After user testing and making appropriate design changes, I usually create a new Page (in Figma) or save certain Pages as a new project (in Axure).
This allows me to work on the next part of the design while not appearing on the page developers might be on to ensure they’re not building something that’s changing.
This becomes especially important if there are a lot of comments on a particular design. Rather than deleting old comments or changing the design, so they don’t apply, it’s often better to leave them as a reference (and perhaps work on the next iteration).
Clarifying your process helps teams understand what you need
My design process has changed because I’ve mainly worked in Federal and Healthcare UX my whole career. That doesn’t mean that I’m not following the Design Thinking process: it just means that little things that I do daily might be slightly different than yours.
This is something that we, as Designers, are often used to. There is no ‘one-size-fits-all’ Design: we know that we need to adapt to different needs, problems, and environments. So why should our design process be any different?
We’re all designing for different audiences and solving different problems. So we need to ensure that our team doesn’t just know things like the “Double Diamond model”: they need to know how we design, to ensure that we have the resources to solve problems for our users to the best of our ability.
So spend a little time thinking about your design process and clarifying it with your team. Doing so early on can make all stages of the design process much more manageable.
Kai Wong is a Senior UX Designer, Design Writer, and author of the Data and Design newsletter. His new book, Data-informed UX Design, explains small changes you can make regarding data to improve your UX Design process.
