Navigating the UX team of one
Being in a team of one can be like sailing on a solo voyage into open waters.
This is an edited transcription from a talk I gave at UX Tree: Things to know When Starting in UX.
There’s a lot of information to process here, so I’ve broken it down with headers — dip in and out of sections of interest. I hope this helps you, reader!
Illustrations: me, with the help of the wonderful Phosphor Icons.
Starting in a team of one can feel a bit like veering into open waters — suddenly, there’s nobody you can turn to that understands your language as a designer. There might be a few sharks about. There’s no safe landing for the eye to see, but… it offers a really special kind of freedom that you can’t experience if you’re on a cushy cruise ship (otherwise known as an embedded design team). You get to chart your voyage, define your goals — you can really charge design decisions that shape the product and service for the better.
🎂 If you did get that job — congratulations! A new design role is a bit like a first day of school. It can be very exciting, and you want to jump into everything at once, and of course, you’ve got a lot of idealistic notions about what you’re job is going to be, which you’ll inevitably have crushed, but that’s okay! If you’re new to design, you’ll feel an urge to jump straight into an assignment. You’re potentially also the first in-house designer in the organisation, so don’t forget… somebody thought you were worth assigning a new department for and hiring, so it’s really important to remind yourself of that after the initial excitement runs dry and you’re wondering if you belong in this role.
👑 Something that can happen, especially for new starters, is the initial overselling of their position. “I am the UX, the Alpha and Omega, I am here to fix all of your problems. I speak for the user, I am the sole bastion of the user’s voice!”. There’s nothing more off-putting than descending from the design heavens and treating the org like a poorly patient that needs to be fixed. My first recommendation when you start a new job in a team of one is to keep it cute, keep it mute, and learn everything about the internal environment of the organisation. It’s really important to listen and show openness to everyone around you. You really want to sow your seeds of future influence and accumulate those brownie points.
🪵 Cut with the grain, not against. Do a lot of listening and don’t show resistance to your initial toolset or the initial processes and ideas. You don’t know where they’ve come from, it’s important to not make a lot of assumptions. You need to gain credibility as well for the big moves you want to make later on.
Document your every move
📚 It’s very important to document your role and expectations clearly from the start. This is to protect you when others misinterpret your job, particularly Product and Engineering. Make an assessment ofyour skills, your own weaknesses, and take notes about other departments — what’s the org structure? Don’t assume that others know what you do, and more importantly — don’t assume that you know what everyone else does. Talk to people and make yourself known to every team. Send hello messages, make sure you schedule 1 on 1 calls with other teams. It’s a bit harder to do remotely, but it is important to reach out to a key figure from every department. That’s how you leave a lasting impact and build your credibility and social capital.
📚 Again… document everything! Document your projects, workshops, exercises you do, make a short weekly review of how well you did that week, what you achieved or missed, reflections on how you handled a challenge. It’s surprising how quickly you forget everything when you’re in the moment, even a few weeks into a new job. When it comes to review time or a future interview, you’ll have a rolodex of growth moments to pull out.
On relationships with others
🤲 It’s important that you make friends with all the non-designers — everyone in the organisation from the bottom to the top. You want you want to find points of commonality between different members of different teams. As an example — maybe there’s a data scientist on your team, and you might think “I have nothing in common with a data scientist”. They might need help designing a dashboard, and in exchange, you might need help making sense of data that they’re producing, and now you’re interested in how you can use data to inform your work and they’re thinking of new opportunities to synthesise user feedback to tell a story of data. It’s really important as a higher-maturity designer to be amongst different groups of people and different disciplines. It lets you open your mind up and understand every facet of an organisation.
👋 Find your friends and allies. Your allies are a particular group of people in an organisation. You’ll need them in times of stress and when you need to make important calls. Having a support network is one of the biggest assets any employee can have. Do also consider external mentorship. There may not be a traditional track of design leadership. It’s very important to have someone to bounce back ideas or navigate through issues.
On detractors
😡 Unfortunately, it’s almost a certainty that you’re going to have detractors. People who don’t share your vision or spark, or people who see you as a subordinate task-doer. Watch out for “Can you do my clipart for my document”, “Can you do the logo for the email”. How you handle that will define your role and how other people see you. You’re also going to have co-workers who like playing designer, often at your expense and without the expertise and insight you bring to your role. I used to think it was important that everyone got in on design, then someone made a really good point to me about being a professional designer — non-accountants don’t tell accountants how to run their books. In that sense — don’t let people tell you how to run design. It’s important to foster collaboration and facilitate it, but you’ve got to still be the owner of your work and use your authority.
💭 Maybe when you started getting interested in design, you imagined yourself spending your hours doing wonderful design work, and everyone would be like “oh, your designs are so wonderful, we’re so glad to have you here”, and you complete user flows, flawless usability tasks, fabulous design systems. The fact is is good design execution is really all about relationship management. I would say managing your relationships and navigating those battles is as important if not more important than the task work itself. You’re not an island as a designer, and you need those people around you to translate the recommendations into action — they are key to the business too.
Managing relationships
🤝 With remote and hybrid work, I find it can be extra hard to manage relationships and get a feel for the atmosphere amongst colleagues, so try to read the chatroom in a situation and check yourself too; how you react to other people is important to know. Your feelings are going to be on high at times and things can get tense. Text chats and long meetings can be the seeds of bad feelings and misinterpretations. Not everyone has great communication skills — and that might include you, Almighty Designer! A developer that you’re talking to and having a clash with, they might seem to be acting difficult, and you might think “Why are they so against me?” but it might have nothing to do with you at all, or maybe this individual is not receptive to the conversation style you use. It’s important to see their perspective. They might be overloaded with work, they might be having an issue with their team, they might be having a bad time personally. They may also feel that you’re getting all the credit for their work.
☁️ When you’re managing relationships, when you get more comfortable with your teams, here’s a piece of wisdom Debbie Levitt has to offer to ensure you retain respect — “no soft cloud landings”. When it’s needed, give your point firmly. Make it clear that if your time isn’t being valued or you have nothing to contribute, you don’t need to be at that hour-long meeting. Ask a team if they can move on from a point that isn’t constructive or is sidetracking you constantly. If things start to go awry, take a breath, take your hands off your keyboard, go for a walk, talk to your allies, if you have a mentor, talk to them too, because they can really help.
💬 Understand the language of each different departments. Different departments can speak very differently to one another. It’s not uncommon for there to be information silos and for people to have different ideas of the same project. If lines get crossed, use the defined rules of engagement, take it easy, don’t go straight to nuclear, see if you can resolve it internally. Try to get the big picture, try to understand other people, and try to be a communicator, and empathy goes a long way.
Timekeeping and productivity
⏳ It’s likely that you’re going to be your own boss as a team of one. You’re reporting to someone who probably isn’t a designer. You’ll need to define your own time outside of task work. It’s a blessing but also a curse, so be strict in your own time planning. It’s to protect yourself from overwork as well as getting through a slump in a week where you don’t have any goals. It’s definitely okay to have off-days, it’s a universal experience, but structuring your time helps in the long run.
⌛️ Figure out where you add value to the company and figure out where you’re being valued in weekly meetings — if you don’t feel like your presence is giving value and you’re not learning everything, you don’t always have to be at every meeting. Ask yourself, “What would this look like if I wasn’t here?”. If the answer isn’t significant, your time is probably better spent elsewhere.
📝 If you’re a productivity goddess you have nothing to worry about here — for the rest of us, it can be really hard to find a system that works for you. However you manage your thoughts and outputs, here are a few core principles. Keep it consistent, keep it impartial, and make it easy to refer to and share with others.
I document work on Confluence, which is highly visible to team members. Once, I got a message from someone I never worked with, who told me that they found my documentation interesting, as it gives a peek into the work I do, of which previously they were blind to. That really helps with getting leverage in decision making.
I also use Sharepoint and Powerpoint for corporate-facing work. I’m not a fan of these tools, but I know my audience is. Nobody wants an invite link to sign up to a tool they don’t know how to use. They just want to see work.
Inheriting and maintaining design docs
🗄 On the subject of housekeeping from a design perspective, you’ve probably going to be in one of two situations: You’ve inherited designs (and hopefully documentation), or you’re starting from scratch.
It could be that there are no standards established by the company. That can give you the flexibility to suggest tools that you’re most comfortable with. If you’ve received a messy document set with no workability, consider rebuilding or using another tool. Once, I got a crazy set of Adobe XD files that looked like it was built in a website builder and copied as SVG. Nothing made sense and I knew I’d need to scale these documents over time. I made a decision to rebuild everything, but that time was saved tenfold when everything was built for scalability and ease of use. I’d like to think the designer after me was grateful!
🦸♂️ If you are starting from scratch, don’t try to be the hero that builds everything from scratch. Do you need a bespoke icon set, or a design system from the ground up that doesn’t have developer buy-in? If you’re starting off as a team of one, don’t make this your primary output and time-sink. There are hundreds of people who have come for you who freely share comprehensive icon packs, design systems, and UI kits. Use these to kickstart your work and adapt it into what you need. You’re going to deliver so much more value when you can focus on the high-level experience and strategy.
🗑 One thing that I used to do a lot, and I really regret it now, is I’d work on a few designs and I’d delete or overwrite them, realising later that I couldn’t go back to those older designs, or they had no context attached. I suggest version control or other non-destructive methods of design progression, and give context to everything you do as you go along. It really helps to build a story and show what you went through to make decisions. Personally, I use a mix of Figma’s page feature (one page per iteration/exploration) and Confluence to reflect on decisions made (also accessible to team).
Strategise for the future
Let’s fast forward — you’ve gotten settled, you’ve gotten your first project work done, and you’re working quietly (hopefully) building your influence. Now it’s time to strategise and grow your presence. You may be the only person who has both the on-the-ground and the bigger-picture view. If you wait for permission, it’s never going to happen.
If you don’t stand for something in your work, you run the risk of being an SX Designer (Stakeholder Experience), and there are enough of those around.
Talk about UX as a business tool to drive customer delight, revenues, and as a competitive advantage. Nobody in management wants to hear “what about the user?”, they want money and success metrics, and you need their buy-in.
Promote your processes when you’ve developed them. Depending on how mature your company is, there may be no formalised research. It might be the case that “research” is a few members of the team testing the app during a coffee break. It’s important to slowly push for the right thing. Aim for the easy wins. Evidence is always harder to fight with than subjectivity. You need evidence to be able to make the bigger design wins in the org.
Avoid design theatre and the design thinking parade — you are the professional, and the team can contribute to the process, but if you don’t make yourself known as the person who has the expertise and influence, you’ll end up being steamrolled, because everyone can design now and you will be relegated to ‘kind, passive design person’ role, code for; ‘we tell you what to do and you be happy’.
When to take the next steps
The next big job is always tempting, but it may not be time. Before you jump overboard, consider your position, the pros and cons, growth opportunities, what can you still try here? have you seen through the projects you’ve been involved with, can you still take them somewhere new afterwards? Maybe there’s more strategy to be done, maybe there’s a research repository to be built. This is your sandbox space, and you may not always get a safe space like this to continue refining your skillset without the pressure of performance in a larger team.
Be realistic about your career needs. If you’re hitting a wall — why is that? Can your org support training to help you grow? Are you stopping yourself from raising the bar? Maybe nobody is challenging you — it might be an opportunity to rise to the challenge. Watch out for premature promotion offers. You’re still gaining experience, and you don’t want to create an awkward spike on your career track. Being the Chief Design Officer when you know how to use Figma and you completed a usability test may not prepare you well for your future employment. Make sure growth is sustainable.
Above all else, take care of yourself. Make self check-ins, mark problematic behaviour. Around the 12 month mark, make that call — but if you’re working in a toxic environment and you’re hating your job, just jump.
I keep a folder on my desktop filled with achievements, messages of thanks, impacts I made on others. If I need a boost, I go through that, and it grounds me. On a related note, consider vision cards.
Some helpful links and resources
And lastly — a collection of helpful links and stories that helped me along my solo voyages:
Reading List:
The User Experience Team of One, by Leah Buley
Articulating Design Decisions, by Tom Greever
Just Enough Research, by Erika Hall
Jobs To Be Done, by Intercom
Some great sources of UX knowledge:
vaexperience
DeltaCX
Hang Xu
Tanner Christensen
Smashing Magazine
Cognitive Bias Codex (so fun!)
