Rethink Your UX: The Case for Full Stack

Most maturity models for UX and design teams (examples here from NNGroup and inVision) thoughtfully lay out strategic placement of UX in an organization. These frameworks are positive north stars that address the most tangible points of people, process, and pipeline. Even with these models and the right people in the right places, there’s a fuzzy in-between that consistently brings UX leaders pause. The people I spoke with all had the same review: How does [x organization] do it? What are we missing? Why are we still struggling with [allocation, resourcing, research buy-in from product, etc.]? I challenged myself to not revert to the 2018 Tech Consulting Answer Of the Year (It depends 🥲).

A few months ago, I started connecting with colleagues over coffee or a virtual drink to talk about their role in UX and its relationship to other roles in UX on their team, in their department, or in their organization. I wrote out my thoughts a la field notes and changed the names and have been sitting on it for a while because it isn’t exactly the point I’m trying to make. So, first I’m going to touch on what I deleted and then I’m going to talk about Full Stack UX. Hopefully you’re bought in.

Let’s start by getting the obvious out of the way. Organizations are messy. Many organizations don’t have the budget for a UX team so they have a UX person that does everything and then ends up doing UI. Some organizations have a UX team that reports to marketing and actually does design, running critiques as usability with printed pages for any internal employee they can find. Most organizations are a combination of messy issues, yet still have powerful and developed talent in UX from diverse backgrounds. These people are equipped and mostly untapped, even though the work that they do is valued and consistent. They don’t mind messy (and we can get tangential about why this job field thrives so well in chaos another time) because they make it work.

Now let’s talk about Full Stack UX. In software development, “full stack” refers to all of the technologies that are needed to complete a project. In UX, we can look at it similarly: all of the sub-modules that exist between the business need that initiates a challenge and the wireframe delivery of whatever fidelity that completes the challenge. Consider the double diamond:

I didn’t make this, but I do stan for it.

Where does UX research fall in this framework? What about UX design? Where do you first start working through design patterns? When do you build a relationship to UI? I could facetiously write out more of these, but instead I’d like to propose a better answer: It doesn’t really matter. As a UX (researcher, designer, product designer, product owner) person, you’re always doing, and you should be always doing, all of this. The process to good product and good UX isn’t necessarily as linear as your deliverables and artifacts along the way. Just because you’ve defined and researched your user via segmentation, personas, JTBD, etc., doesn’t mean you aren’t going to go back to it and find holes or re-examine insights when you’re putting together wireframes, prototypes, or future state journey maps. Full stack in development considers a similar approach - yes, you follow a process, but sometimes you find challenges that impact the other pieces of your stack. You need to be able to communicate these challenges and coordinate how to solve the internal issues that impact the external problem you’re actually solving. And, in order to communicate and collaborate effectively, everyone needs to understand not just their own role, but the role all people on the team have.

I imagine a seamless team that operates in their expertise, but also shares the task management of their own UX competencies with the rest of the team. Silos are built in organizations not when they don’t share their work, but when they don’t optimize the best ways to share their work. Just anecdotally: I spoke with nearly three dozen colleagues in UX roles at companies large and small, and every single one told me that they had plans to scale in the next three years. So, let’s scale. But let’s scale properly. The case for Full Stack UX is simple and can be accomplishable with only a few tweaks to resourcing. Establish your UX org, and establish it well so that when you do scale, you scale for the opportunity and not to just fill in the gaps. Here are some things that I try my best to practice:

Internal rituals should include everyone

Design jam? Invite the researchers, too. Walk the wall of a heavy synthesis? Invite the designers, too. This applies for all of it (interview guide review, project planning, intake debrief, requirements planning, and whatever else you do ritually that includes another person and could include another perspective). The point to be made is the biggest point: Collaborate. Full stack is only accomplishable if people see what good work and good criticism looks like. Make everyone a consulting partner for 30 minutes a week.

Designers should ride passenger in research projects, and vice versa.

This is related to the first point, but digs one level deeper. Create a good partner who isn’t responsible for the work, but supports the work. Give them the opportunity to contribute and to execute within their lane, so that they empathize with the work you do and know when to ask for help when it comes to them leading the work they do.

Focus professional development first on core competencies, and then on strengthening tertiary competencies.

This is something that most organizations do well, but don’t necessarily do intentionally. To me, a good development plan first just says what someone needs to do in order to do their job well. What are the competencies that one is expected to practice at an expert level? How is that person in those competencies today? What will it take to build those competencies to the most appropriate level? That’s over with? Good. Move on the next set: What are the competencies that one could practice at an expert level? What would be most beneficial to help the growth of the team? Where does the team need expertise?

Set everyone on your team up to be able to do all work.

This doesn’t mean that everyone should do all work. But make sure that if your best researcher wins the lottery, you have a comfortable way to back-fill the multi-month contextual inquiry project they’re on - and it’s someone who can see the whole vision, from problem to insight to design delivery.

Full Stack UX is simply harnessing the talent of a UX team and inviting everyone to contribute to the insights and experiences that come out of it. It’s OK if you operate on a UX practice that separates its people between research and design - that doesn’t mean you shouldn’t be building muscle in both of these skills.