One of the most satisfying things in work life is watching how ideas are realized and products shipped. All your hard work finally paying off in a tangible way. Almost assuredly you didn’t get there by yourself — it was a team effort. Well, teams effort. But you were in one — the product team, the design people. It’s nice to be in one, working as a well oiled machine. But if and when you find yourself in a new organization, tasked with launching product initiatives, how do you build such team from a ground up?
To make stuff, you need competencies
Your team is a product team, with a primary business objective to make stuff. To do that, you’ll need competencies, each one an entity build from theoretical knowledge, realized through will and determination in a practical expertise.
In the UX field, you basically have 3 main groups of competencies:
- information architecture and service offering — capability to see the broad picture and translate business requirements into a plan. Requires business outlook and knowing tech well enough to realize what might and might not be possible.
- experience — aligning service offering with user needs. Fine-tuning of the product flow, making sure stuff will be usable and useful.
- UI/visual/haptic — making sure stuff is pleasant to use with whatever sense it requires. Deals with aesthetics, microinteractions.
- content — filling in the architecture and flow. Mostly thought of in a way of UX writing, but content ≠ text! Images have semantic load too. Just don’t mistake content designers for marketing copywriters, their goal is to deliver content suited to user needs.
- qualitative — insights, feelings, life stories. Observing behaviour of people, talking with them, empathizing with them.
- quantitative — numbers in sample sizes large enough to do statistics on them.
- communication — delivering actionable insights from qual/quant/mixed methods in a language suited to the person the research is intended for.
- everything that needs to happen so designers can design and researchers can research.
People have these competences in different proportions, as they should. It’s necessary to be able to speak the language of your co-workers. In practical terms, you can expect that from mid level up, people should have at least basic idea about every single UX competency — not to be proficient in them, mind you, just know what they are about.
How to scale your dragon
Moving on to team setup. Your goal should be to build a team of specialists, each capable of dealing with a slice of the problem, and with project conditions that support development of deep expertise in the team members. However, to reach that goal, first you need to start somewhere.
If you’re the only hire, you are likely a senior designer, capable of translating complex business requirements and user needs into smooth product flow. Depending on your background, you might have some familiarity with content design and research.
Some successes and budget adjustments later, you can hire another person. Since you already are proficient with designing products, next step is to ensure you can design in a data-informed fashion, not just based on your experience (which isn’t proper UX, but hey, tell me you haven’t worked like this). A good mixed-methods researcher will come in handy. If one is difficult to find, I’d recommend hiring qualitative researcher first, quite likely it’ll be easier for you to schedule 5 people for a user interview and testing than gather robust data set for statistical inference in a way that’ll suit agile environment.
Time for competencies assessment. Who are the people in your team now, what more do you need to deliver business goal completion? It’ll depend greatly upon what you are actually trying to build. Design system or a major redesign of a product? Go hire a person with strong visual and UI design skills. Improving existing product, creating new stuff for it? Content person might be a better fit.
After your team grows to 5-6 people, it might be prudent to consider your daily operations. How do you manage your design files. What about research, raw data and insights? While it is a relatively new thing to be hearing about, finding someone who, in addition to design/research skills, has ops competencies, will greatly improve your team’s efficiency in the long run.
Hiring the goods
Finding just the right people for the job is like finding a diamond in the sewage — you’re not looking for right things in the right place. Talent that is proper, and visible at that, is snatched out of the market pretty quick. Prestige of your company will play a role, also a town you’re located in, even with hefty relocation budget at hand.
When faced with such adversities, what can you do about it? You need to grow your team. You need the new hire to not be ill suited for the job, for that’ll cost money, time, and more money. What you can do is to ditch the unicorn mindset. Assess what competencies will be required. Separate those that are necessary foundation from stuff than be learned as they go. Former is made distinct in people’s CVs and portfolios due to similar structure of business issues they faced, not due to actually working on near-identical stuff you try to build now. An example of the latter is the tooling — Sketch, Figma, Tableau, Lookback, DataGrip. One can become proficient in them in a month or two, but it’ll be exponentially more difficult in that time for them to learn how to create great user flow, or navigate user research interview with a difficult participant.
After defining requirements for the new hire, you’ll need to sift through all the applications. Plenty of HR techniques exist for that and you’ll be better served to look for the minutiae of them on the internet, but I can give you examples of what I found to be a process that gets you a good candidate, and leaves the ill-suited ones without the feeling of resentment after rejection.
- Remote interview — dragging candidate down to your headquarters just to reject them is a meh idea, both for you and them. Set-up a call with them to get a general idea of their competencies. Stay mindful of the fact that people can get nervous. Try to ease their worries and carry the flow of conversation — having general talking points written down will help with that, especially having more of them that can be talked about during 45-60 mins call, so you can put them into the interview as required. If they stay nervous, decide if this is a deal-breaker, because for some positions it is not.
- Recruitment task — basically a homework. I like it quite a bit more than a whiteboard interview — give me a coworker who can google up the necessary information in an hour rather than one having phonebook in their head, unable to adapt to real-world tasks. Select a business issue that will test competencies similar to these required in your project. Define your requirements thoroughly, though. When delegating a task to an actual employee or an outside agency, it’s great when they approach you to ensure their understanding of the business requirements. Your new hire is not an actual employee or an outside agency. You don’t pay them for the task (unless you do, but that’s rarely heard of). Write down what you want from them and see if they can think inside that box.
- Final interview — presentation of the recruitment task solution. I said in the first point that it’s sometimes ok to give a chance to people who get nervous in an interview, because their job might not require exceptional communication skills. That still holds true. What everyone’s job will require is to communicate the effects of their work with the team, and that needs to be tested as much as their competencies. Also, money stuff. It’s customary to ask people about their financial demands, and I see why, a lot of money can be saved that way, but give people the pay range for that position. An employee happy with their compensation, trusting that the company treats them fair, will generate more value in the long run.
- Feedback — No matter how much you thought the candidate was bad, they might improve, and the talent pool is not limitless, no need to burn bridges. Give them a call at the end of the recruitment process regardless of how they’ve fared.
So, you got your new hire. Time for onboarding — a thing just as important as finding the right candidate. Taking care of properly settling in the new team member will add to your workload in the short run, but long-term you’ll be thankful to yourself for this extra effort.
Onboarding, in a sense that you as a UX team leader are responsible for, ends with new hire being fully embedded into the team, and no longer considered “new”, which probably will be when their trial period ends (likely around 3 months). How exactly will you plan this depends on the scope of your team, project, organization, budget, deadlines, etc., but assuming corporate environment, ~5-7 people in a team, and project being somewhere around the middle of it’s time frame, I’d go like this:
- First days
- meet the team — make the newbie feel welcome! Introduce them around, make sure they mingle, take the team out on town to break the ice.
- meet the organization — they should know who will they impact with their work, what are the different departments, and the open secrets of the organization (like which floor has the better coffee machine).
- meet the tools — where is the stuff they can use, both physical (post-its, markers, whiteboards, glue, scissors, kitchen stuff) and digital (data and knowledge bases, toolkit and possible software licensing, user rights, admin and support systems)
- First few weeks
- get to know the workflow — include the new hire in team’s daily rituals, show them how the feedback loops work, who to delegate tasks to or accept from.
- gather domain knowledge — great exercise for that is to have them make an expert review of your company or project’s product. Help them gather knowledge necessary for taking on actual workload.
- regular 1-on-1s with mentor/lead — shorter feedback loop equals faster results. If you have hired junior/mid person, one of your seniors can mentor them through the trial period. If that’s a senior, it could be beneficial if you (as a team leader) monitor their progress.
- End of first quarter — here you’ll ask whether they found their place in the team and the project. Assess the past 3 months of their work and decide whether to sign a permanent contract or start looking for someone else. Upon deciding to carry on with them, review their work cadence and self-organization capabilities. It’ll be the basis of performance reviews and give you general idea about the workload now not-so-new team member can take on.
Leading your team
It ain’t easy being a boss. Being the face of the team comes with full responsibility of what your subordinates deliver. Keeping track of what is happening all the time, while ensuring your own deliverables are of sufficient quality starts to take it’s toll on your mental wellbeing. Or maybe it doesn’t. Maybe you don’t try to micromanage — maybe you lead, instead.
Being a team leader is an exercise in implicit trust in people’s competencies. It doesn’t mean yielding all control, not at all, rather focusing on fostering self-organizing mindset within the area of responsibility for a team member. Your subordinates are adults, not children — you’ll judge them based on their results, not looking busy.
People will thrive when they feel safe, both from physical and psychological harm. In a feedback-oriented environment, where small mistakes and larger failures are treated (up to reasonable, non-disciplinary-action-requiring circumstances) as a learning opportunity, you as a team leader will be able to discover their unique talents or ways to contribute, utilizing this knowledge to nudge them gently and watch as they grow. Increased output and employee satisfaction will follow. Feelings of exhaustion after you crash on your couch after work will be much more rare, too.
The way to achieve it all is through presence. Actively listen and strive to understand the team’s worries. Make sure they know what and why they are doing, it’ll be easier to stay motivated if you know what goal lies beyond the horizon. Clear communication will bring greater understanding, and you’ll start seeing it in things big, like shipping a product, or small, everyday routines.
Choose your style. Give people trust and honor theirs. You’ll be fine.