UX Team of One
Building relationships with other departments to ensure your success
Coming from an art school and design studio background, I had no idea what was in store for me when I moved back home to NYC. I had accepted a UX designer position at a fast growing startup. I was beyond ecstatic.
Everything was going great until the second designer on the team moved on to another company, leaving me as the sole creative. I had no one else to rely on except for the engineering department.
This was not going to be like working at a design studio anymore.
I was the only designer for three high performing teams. I had deadlines to
complete multiple features every week. All the meetings, researching, and
designing made it difficult to dive deep into a single idea.
I needed to get shit done.
In this article, I’m going to share how I built a scalable design system by crafting cross-departmental relationships. All while being a UX team of one.
Engineering Department
Build trust and be humble
It is crucial for engineers and designers to work together. At first, I did not want developers interfering with my creativity. I thought that design was something that only product people focus on.
I was wrong.
Engineers often have as many good design ideas as designers do! This is because they understand how the codebase works. They wrote it! They were always thinking about how the product works and how it could be improved.They know exactly what ideas are worth pursuing and how they will fit into the code.
This knowledge is priceless for designers.
A great way to build trust with developers is to get them involved in the design process. From feature spec to launch. This is how you ship a product.
The product development process should be about finding the shared values between product and engineering. Itʼs not only beneficial to you as a designer, but to the business as a whole. Friction between design and engineering leads to countless hours of bickering and delays. That’s thousands of dollars or more down the drain depending on the size of the company. It’s in everyone’s best interest to make that process as seamless as possible.
This process is going to be different for every company.
I saw this resistance first hand at this startup. We were moving so fast that my communication with developers was often slow, broken, and asynchronous. I knew there was a lot of room for improvement.
I began inviting front-end engineering to monthly retros where we would discuss blocks and possible resolutions. How did I lure meeting-adverse engineers to such get-togethers? With bomb homemade cookies and snacks. I’ve found that developers are more willing to listen to reason when they get some butter in their system.
These retros worked like a charm.
I approached them like user interviews. I asked them what they think we can improve and listened to their responses. I did not input any of my own opinions. This way the developers felt heard and included. By the fourth or fifth retro, the engineers were excited to participate and gave their opinions on what could be better. One of the engineers even told me that these were his favorite meetings. Trust was built.
Together, design and engineering built the product development process. We worked as a single team instead of two opposing forces. I understood their pain points and they understood mine. We all shared the same goal of building an awesome product with awesome people.
By the time I left, we were humming. The work we produced was beautiful and intuitive. Best of all, the developers did not spend a ton of effort building it.
How to get it built
Find a CSS Guru
There are specific relationships you need to build to manage a scalable design
system. One of the most important is your goto CSS Guru. This person will be the Bonnie to your Clyde. They will be the one to build your elegantly reusable components and advocate that the rest of the front-end team adopt them.
I was able to trust my guru with any feature without giving them a single redline. The work they produced would be exactly what I designed, down to the pixel. Additionally, they built the components to work like lego blocks. They helped ensured the components could scale as the product grew. This relationship is key for any designer on a growing and fast-paced team.
However, finding such a developer is often a tall order. What a rarity it is to find a front-end developer who actually loves working with HTML/CSS? If youʼre fortunate enough to have a guru on your team, hold onto them and get them on your side.
Win the heart of your FE bull
Your frontend bull focuses on hitting their sprints. They may have very strong, or even very biased, opinions. These developers have the loudest voices on the team and are often the most senior.
Getting them onboard will influence the entire team to follow.
The best way to win this personʼs heart is to get them involved in the process as early as possible. If this person cares about hitting their sprints, tell them your design ideas while theyʼre still forming. They may have valid input and/or reasons to focus on other ideas.
Knowing that they reduced the scope of a feature by a few points will let them
know that you care about their opinions. This will only be in your benefit. Since they know that you are looking out for them, they will do the same for you. Instead of finding any way to wriggle out of a design request, they will dedicate their time to finding the best tools for the job.
Aligning with Back End Developers
This advice may not apply to larger companies where the divide between design and the backend is a chasm. However, for small, cross-functional teams, itʼs beneficial for backend developers and designers to align before they start working on a feature.
Your mental models of the product and corresponding APIs need to match. An
amazing relationship with the frontend team will be for naught if the backend isnʼt cooperating. If the backend devs want to live on their own island, there will be issues in the product.
For example, they may push out an unintuitive feature that has unintended side-effects on the client interface. This will happen when you take design out of the picture when building back-end APIs. It takes the human element out of why we need that API to begin with.
Developers need to understand this. Unless they work for a company thatʼs
building its product for other developers, their end users wonʼt think like them. Theyʼre non technical people(NTP).
I was lucky at this particular startup. The backend engineer was always open to answering any questions on how the APIs worked. I wanted to make sure that I was designing the right thing.
Working with backend developers will make sure your work is right.
The Revenue Organization: Sales and Customer Success
Your teammates aren’t always engineers
When I began working for a new startup in late 2017, I found a whole new
opportunity for growth. By this I mean, I discovered a whole new set of problems to solve.
I had to undertake the daunting task of redesigning an entire B2B enterprise
platform. This proved challenging as this was an industry that was new me and my customer base included heavy hitter “blue chip” customers.
That was where Sales and Customer Success teams came into play. After conducting several user interviews within the company, it became obvious that customer success and sales felt like they were not being heard. They felt as if they lacked clarity around what the engineering team was developing and why.
There was a huge opportunity to bridge the gap. I could use the vast knowledge that the customer success and sales team had about our users for the benefit of the product.
Learning to be vulnerable and take critique from anyone
If youʼre a designer in a B2B company, you should get sales and customer
success involved before shipping a product. Since they are the frontline for
customers, they can bring up red flags and amazing ideas for future iterations.
I collected this feedback by holding public product demos of features that we
were shipping out. I wanted to give them the chance to react to the product
and voice any concerns. At first, it was hard to make myself that vulnerable. To let a room of 20+ non-designers judge my designs and give honest feedback was not easy.
In these situations, my advice is to come prepared.
Be ready with the top three aspects you want them to understand by the end of this session. Let them know what kind of feedback you are seeking. It was
valuable for me to hear what the sales team was hearing from customers.
If done right, these product demos can provide essential information in a short amount of time. Itʼs essentially like doing 20 UX validation interviews at the same time.
Customer Success will guarantee success with your customers
The customer success team knows your customers better than anyone else. They talk to them every day. They know how your customers feel about your current product. They hear what they are hoping to see from the product moving forward. They hear their every grievance.
Customer success teams will always advocate for you and get you whatever you need. Whether it be face time with customers to do discovery sessions or joining you in UX validation sessions to take notes. They know that the better the product becomes, the happier their customer interactions will be. They will do anything to make that happen.
Customers are also dying to get involved with the product youʼre building. Work with your customer success team to get in-front of your users. The CSMʼs will ensure the success of any meeting that you conduct.
Understand users pain points through the Sales perspective
The sales team are another great asset to have when you are designing a new product. They understand your users pain points and are trying to solve them with your product.
The sales team brought up critical points when I was doing internal interviews. They walked me through the pitch they tell future prospects. They revealed the usual client questions that would trip them up due to lack of knowledge. This is key information in understanding the first user experience of your product. Itʼs important to work alongside sales and enhance the story they tell future prospects. One of the best feature ideas I received came about due to this collaboration.
One of our features is a home page for users to find learning content. After user testing, I found out that users did not understand the purpose of this page. I had come up with a couple of ideas for improvements and asked the sales team for their opinion on them.
The main feedback was that there was not enough emotional pull. There was not much that attracted the user to that particular page. That is when I had an “Aha!” moment.
I showed them an idea I had thrown away because I did not think it was going to work. It was a simple idea that would add a headline reading “I want to develop my skills as <user supplied role>”.
That was the idea that resonated with the team. After a lot of testing, we found it to be a huge success among users and admins as well.
The best ideas can come from anyone.
Every company is different, as are the people inside them. How you manage those differences will depend on your ability listen, learn, and build cooperative relationships. A little empathy (and homemade cookies) can go a long way in your career. That is how I have found success as a UX team of one.
If this article has resonated with you, please leave some claps 👏!
