How to survive suddenly becoming a UX team of one
Written communication is critical to managing expectations
“It’s just me now.” I said, after wishing my colleague the best. She just accepted a new job offer, meaning I was back to being a UX team of one.
This wasn’t my first time as a sole Designer, but it was still unexpected. Due to layoffs (and people leaving), I, like many of you, went from a team of UX professionals to just me.
In these cases, it’s not just a matter of doing more work: it requires shifting your and your team’s mindset. You must set clear boundaries to avoid trouble when you’re the sole designer on a project.
In this case, it starts with defining your workload in writing.
Define your workload in writing to manage your limited resources
When you’re a UX team of one, you might feel incredibly pressured by the rest of the team to “Hand over deliverables.”
It wasn’t until Debbie Levitt pointed this out that I remembered being gaslit about this.
I remember one such project manager always rushing me through my design process to hand stuff over because we didn’t want to have the Engineers sitting around doing nothing.
Listen to that statement again, and tell me what’s wrong. It’s simple: I was the sole UX Designer on a team of a dozen Front-End/Back-End Engineers. Of course, I will be the bottleneck—I’m only one person.
This is one of those ways that Levitt says organizations gaslit you: in any other case, asking a person to match the output of a dozen different people would be considered ridiculous.
When organizations say this, it’s usually for one of two reasons:
They think design is easy, and I can quickly mock up a complete prototype in an afternoon
They don’t understand the (largely invisible) work behind creating a full-fledged prototype
So one of the first things you need to do is define your workload through written communication to cover your ass. When you are the sole designer, having a ‘checklist’ of tasks, stories, and things to tackle can help people understand that you can’t rush design and are making progress.
Make UX progress visible because it often is not seen
The invisible work I highlighted above is an ongoing problem that UX sometimes faces, especially if you’re creating with a design system. When you use design system components, your prototype might look like it’s 90% there visually when it may be 40% complete.
In addition, teams sometimes have this fuzzy notion of what work you do until I magically pop out a mockup or prototype.
This is why writing down tasks like user stories, JIRA tickets, and other things becomes incredibly important as the sole designer. It’s essential to document the stages of your work to show progress and ensure that the team knows what’s happening.
If you’re not quite sure how to break down the design process into subtasks, consider this template of steps you can check out:
Define product requirements with the team (with it written down somewhere)
Low-Fidelity Design exploration and User Research (if possible)
Presenting Low-Fidelity ideas (and gaining approval) from the Product/Engineering team
Design iteration (if needed)
Refining chosen Low-Fidelity ideas into High Fidelity prototypes
Creating interactive clickable prototypes/Visual design focus
Final approval from the team
When you follow this template, you may notice that the sub-tasks also show visual progress. The low-fidelity prototype might be “Boxes with Squares” or “Cutting and Pasting images together,” but it’s meant to be a rough concept.
However, once we’ve decided on the right low-fidelity idea with the team, they should be able to tell the difference and how much progress was made with it the next time they look at it.
This way, it’s not just a “task list” progress meter; it also shows visual progress. Doing this can help alleviate anxiety around your work as a sole Designer and showcase your progress. That, in itself, is an important idea.
This also allows you to do one crucial thing: decline due to priority.
When you have a written task list, you can easily decline requests
I’ve worked for managers who, every other week, might have a new idea and direction for a project.
Or Executives with a cool new idea want me to design it. These seem like simple asks, but you can easily find yourself stretched thin among tons of random tasks.
But by documenting your tasks, you have a built-in obstacle to prevent yourself from being overwhelmed: priority. If you can point to your list and say, “I’m working on these specific stories this Sprint, and I have a full plate,” you can either decline to work on it or tell the person to work with your Project Manager to figure out how your priorities can be shifted.
This sort of crystal-clear communication not only helps you avoid tricky situations but also helps you avoid conflict.
Set specific timeframes for sending out e-mails.
This seems silly, but it’s necessary, especially if you drive efforts like user research and stakeholder interviews forward.
When you’re busy working on a dozen different things, setting aside a chunk of time (like 15–30 minutes) dedicated to tackling your inbox can be a great way to ensure you don’t get sucked into e-mail conversations instead of focusing on your work.
This is especially helpful if some conversations are difficult, such as responding to your manager’s changing priorities.
By making it a short block of time (like 15–30 minutes), perhaps twice a day, you’re ensuring that you can respond in a timely manner while also saving your focus for deep design work.
Understand that you may not get the feedback that you used to
I spent my formative design years as a UX team of one, which meant that I tried (and failed) to get more detailed feedback than “That looks good” or “I don’t think that will work.”
As a result, you will need to seek feedback in many weird places to grow. It may not be perfect, but it’s necessary if you want to grow as a designer and improve your career.
By setting goals, understanding what the business asks you to do, and seeking feedback from additional sources, you can help yourself grow as a Designer, which will become incredibly important for your next position.
If you suddenly find yourself a UX team of one, it’s survivable
It can be a shock when your large design team suddenly becomes a UX team of one. It can feel even worse when it’s no one’s fault (except a weak economy).
However, I can tell you that it’s manageable once you recalibrate everyone’s expectations through written communication.
When you do that, you may find yourself designing meaningful changes and having a more significant say in things. By ensuring that your work is more visible, having clearly defined written communications, and managing design requests in a scarcity mindset, you can ensure that you can spend most of your time designing and not getting sucked into a million projects.
I’ve revamped my Maven course to teach Data Informed Design. If you want to learn this valuable skill, consider joining the waitlist.
Kai Wong is a Senior Product Designer and writer for the Data and Design newsletter. His book, Data-Informed UX Design, provides 21 small changes you can make to your design process to leverage the power of data and design.
Hey Chris,
I've recently found myself a solo designer, This piece couldn't have come at a better time.
Great advice, looking forward to implementing it.