Building a team from scratch isn’t easy. I’ve had the opportunity to build some really great UX teams for several different companies. These are my experiences, trials, and successes in building these teams from scratch.
Starting out
Walking into a company on day one to get the lay of the land can be daunting, especially knowing that you’re a department of one doing the work of three different people. For me, the biggest goal for the first week is to understand the software I’ll be working on as much as possible, connect with all the other division heads within a company, and review the upcoming work on the product roadmap.
When I take a look at software for the first time I like to learn about what it’s built on. Knowing this can help determine development capabilities for future front-end design. I also like to learn about the variations the UI has taken on since conception. A few questions I ask are ‘How many different versions have the customer experienced so far? What are the things that worked really well between these versions? What hasn’t worked well?
Getting to know the folks you’re going to be working with is crucial to promoting and implementing a successful user experience. There are three main departments I meet within the first week. They’re engineering, customer service, and product. I see that everything I work on is groomed and signed off on in some way by one of these departments.
By working closely with engineering you can establish how mockups are handed off in the most efficacious way. You’ll learn how to best iterate on a design that is a perfect mix between upping your UX game and delivering something developable.
If the organization you’re stepping into doesn’t have any formal UX processes in place then most customer feedback is coming in through the customer service department. When I engage with this department we work together on how UX tickets are created and handled. Instead of the tasks being passed off to engineering or deprioritized they can be effectively given to the UX team to undergo proper evaluation.
Working with the product team seems like a no-brainer. They’ll be the ones that set the development roadmap and have a pulse on functionality that needs to be explored and created. The UX department should sit under this team, however, sometimes a UX team will find themselves a part of the engineering team. Regardless of company structure proper communication with the product team is essential.
Question Everything, Even Yourself
Keep in mind that sometimes not everything is going to work out as planned when building up a department. Oftentimes, various other leadership roles will have opinions on how you should run things. Each company is different and it’s important to take all points of view into consideration. Make decisions based on data. Don’t be afraid to fail early and learn from the experience.
Creating a UX framework
While making the right connections I also put focus on creating a few basic components that set the overall structure of the software. I put these components in their own document that serves as a UX design source of truth.
Socializing this document with the rest of the company ensures you gather early feedback on overall usability, that it aligns with branding, and can actually be implemented by the development team. Once you have your team built out it will also ensure consistency between different designers.
A few of the key components I like to start with are
- Headers
- Main navigation
- Inputs
- Buttons
From there I like to define a few different interactions:
- Hover, active, and disabled states
- Input validation
- Contextual awareness via micro-interactions
While this is a great starting point I make sure to revisit the document as a team to make sure it evolves and is best serving the SaaS tool.
Determine company needs
After I’ve got a handle on communicating between departments and a strong base for all future design work I take a look at who can help further establish the best possible user experience. UX is a company-wide effort and different teams can help shoulder some of the work.
Interfacing with the user is critical for any UX department. I find that customer service reps often have the best rapport with user issues. They can often tell you how often a certain bug or feature is causing tension in a workflow. I will usually ask them to help me make introductions to folks that are interested in participating in further UX research. From there I can evaluate specific workflows and design ideas with actual data.
The engineering team is a great resource for examining bugs and other related reports. Bugs not only expose issues with a piece of software but also help identify discrepancies between expected user actions and what is actually happening. I find it helpful to initially design for how the user expects a certain piece of functionality to work. Users spend most of their time using other applications and sites so they have a preconceived notion of how things should work.
One of the most underappreciated departments for understanding customers is sales. Working with sales can be tough for an engineering-centric company because they can sometimes talk up features that don’t exist or don’t do what they pitch them as. However, sales staff often know exactly which features need to be implemented in order to get a new customers, upsell existing customers, and reduce overall churn. I find value in the occasional meeting with the sales staff to bring in greenfield technology to my mockups.
Evangelize UX
Sometimes working in UX can be daunting because you can create really excellent workflows and mockups just to have them shot down for one reason or another. Overall this is a good thing as it can expose important issues in workflows. It’s important to push UX best practices to all parts of your organization to make sure that lack of understanding isn’t one of the reasons for sub-par software.
I like to create a series of lunch and learn events that discuss design and usability that are open to the entire company. This allows your coworkers to ask questions and better understand that mindset you’re working in. I’ve found that once other departments better understand why things are created a certain way it takes some pressure off design iteration. They’re already anticipating how something is going to be designed because they understand UX and the component system I’ve created.
Constant communication is a big part of evangelizing UX as well, especially to the folks you report to. I’ll set up twice-weekly meetings with stakeholders to ensure any design work is aligned with the company goals and product roadmap. The first meeting is to discuss what’s going to be worked on and the second is to review work generated from the first meeting. I also split the meetings into two halves. The first is to go over weekly assignments and the second is to review long-term work and discuss new items that were derived from other departments.
Hiring the team
In my experience, once I’ve established these main pillars for a strong UX team I’m ready to make the case for hiring more individuals. There are a few different key players that fit into creating a strong team.
Skillsets to look for
Initially, team members should have a bit more of a generalist skew. Unexpected things can happen during the hiring process and the last thing you want to do is to hire a hyper-specialized employee and then have a hiring freeze and have to make up for the team’s shortcomings.
A generalist is a UXer that can do a little bit of design, research, and light development. They’re extremely useful when you’re a small team with lots of responsibility.
Additionally, if I have the capacity, I’ll hire a designer and a researcher. This way design and research activities can happen independently. I’ll also encourage each team member to pair up and learn each other’s skillsets to some extent. That way, when work fluctuates the team is prepared to handle any scenario.
A UX designer is someone responsible for wireframes, low and high-fidelity mockups, and even some interactivity. They’re the ‘how’ portion of the team. A researcher will be interacting with customers and distilling feedback into items to bring back to the team. They’re the ‘why’ portion of the team.
Lastly, I like to work with engineering to hire a flex developer as someone who can transition mockups into a functional component library that the development teams can use. This eases the transition between design and implementation and allows the UX team to iterate freely.
Where to find the right team members
Now that I’ve identified the types of team members I’m going to bring on I have to determine what level I’m going to bring them in at. I want to make sure that whoever I bring on will have the opportunity to grow, learn, and hopefully move up as the department becomes more established.
Interns are great for trialing individuals’ skillsets without wanting to commit to bringing someone on full-time. You’ll get a good sense of an intern’s time management soft skills while they juggle school and work. I’ve found that connecting with local universities is a great way to sponsor students for a flexible team.
Entry-level employees are eager to learn and are usually well adept at learning ancillary skillsets. Connecting with local design groups, such as the AIGA, has been really useful for finding folks at this level.
Senior-level folks are great when you need a honed skillset to really push a project to new heights as well as mentor more junior team members. Generally, I work with recruiters for individuals at this level because the list I’ll receive has been catered in some way and provides me with high-quality leads.
Mentoring your team
As I grow the team I want to ensure forward progress and growth on an individual basis as well as overall team growth. I set goals and checkpoints and allow members of my team to learn things they think would be helpful. For every goal, they decide on I try to pick one that I think would be helpful for the company. Goal setting by itself is a great tool but I also give them the time to explore these things by giving them at least a few hours every week to focus on their goals.
I find that the next most effective way to push a team to better understand their craft is by having them present their work to other parts of the organization. This shows they’ve thought about a design thoroughly and are able to articulate the reasoning behind their design decisions.
Maintaining consistency
No matter how tight a department is with its processes having some sort of design debt is inevitable. There are a few key principles I’ve worked by that have helped my teams reign in outlying designs early and often.
The first is by creating a culture of openness by allowing a team member to get something wrong, discuss it, fix it, and learn from it. There is no shame in learning something new and I want my team to know that.
I encourage them to try out new design systems, even when they don’t necessarily design with what’s already been created because they could bring something new and better to the table.
Lastly, I encourage my team to try to figure out something by themselves first but ask for help when it’s needed. They also understand that there’s no shame in consistently asking for help as long as they learn along the way.
At the end of the day
Do what feels right for your team and what fits best with your scenario. There is no one roadmap that spells out the perfect design team. My best advice for new design managers is to be adaptable, accept criticism openly, and listen to your team.