Cross-functional teams without UXD

This title is a bit of an oxymoron. You can’t really call it a cross-functional team if there isn’t UX and Design in it to deliver your product. But we see so many times we have to dig deep to keep these disciplines in our delivery teams.

There are a couple of common reasons why clients request to take out UXD from our team structure.

  1. The UX and design work has been done already
  2. They already have UX and design resources

Sound reasonable to you? Let me explain why they are not.

What do UXers and designers do in cross-functional teams?

We’ve often found the expectations of UX and Design roles do not match what we actually do. These expectations were set in the days of linear, more siloed ways of working. UXers do user testing, produce IAs, wireframes and spec documents, then toss them over to designers. Designers produce flat designs and PSDs, and cut assets for development, then toss them over to developers. We still do some of those activities, without the tossing over bit, but they are a minor part of our day to day work.

Our week usually consist of:

1. Understand the product vision and strategy
It is UXD’s job to ensure the vision(s) and strategy are reflected in what we deliver.

2. Validate requirements for delivery
Do we have enough information to build? Are there any big assumptions that need testing before committing? Are there any last minute external requirement changes such as legal and APIs? We validate each story just-in-time.

3. Facilitate shared understanding
We organise sketching sessions to bring business, design and engineering together to form shared understanding of each story, and facilitate and contribute to innovation.

4. Ensure the cost of development is justified by user experience benefit
It is not about doing latest and greatest, but to do the right thing to deliver value to users. Some ideas might look great, but come with heavy development time. We make sure these costs are justified. If not, find a less costly, but equally appropriate solution. If it’s still a brilliant idea, we can always come back to it in later iterations.

5. Pair with engineers and testers
We sit with the team to solve any design issues that arise during development by making just-in-time design decisions.

6. Ensure the design quality of the build
It is ultimately our responsibility to ensure the product has good quality user experience.

7. Follow up on the hypothesis with users after the story has been delivered
We keep track of hypotheses that needs validating with users after delivery. We organise user testing and feed those learnings back into the product backlog.

8. Help product owners prioritise backlog
We help product owners understand context and impact of existing backlog items and new items added because of the learning from what’s delivered already.

9. Prepare layouts and assets
We produce assets required for delivery of the product. However, we do not see this as our deliverable. Our deliverable is the live product. The amount of output here does not equal to our productivity. In fact, we encourage our team to produce ‘just enough’ to communicate the solutions to the team and stakeholders.

As you can see, what is assumed is only a very small part of our role in a cross-functional team. And the measure of ‘doing work’ is completely different – it is about how good the product is and not about how many wireframes / flat designs we produce.

What happens if there’s no UXD in the team?

The short answer – it will slow down the delivery, and the quality of output will be worse.

Let’s look back at the reasons for not having UXD again.

A. The UX and design work have been done already

Let’s face it, upfront UX and design work are never perfect no matter how much you try. There’s always something that’s missed out in their thinking. There are mistakes in documentation. There are explanations that are incomplete or missing. Without inputs from engineers, some ideas can be too costly to build or offer seemingly very little benefit for the amount of effort. There are some ideas you may have spent ages on that are not required because of the way the product ends up being built.

On top of these issues, the biggest problem is that this work is done ahead of time. Some specifications can be out of date by the time they reach the development stage. New, much better API with different requirements might be available by the time you get to development. Or the service you were planning to use might not be available yet. And now there’s no one who can answer those questions in your team.

Of course, the team can ask questions to a UXer or designer who did the work upfront. But they will have moved on to other projects already so it can take some time for them to come back, causing delays and costing more. They have also probably forgotten why certain decisions were made, potentially causing a drop in quality.

B. They already have UX and design resources

The good news is that we can make this work successfully if the client’s UX and design people are willing to participate fully as a part of a cross-functional team.

But unfortunately in many cases, these people are sat elsewhere, available only on a part-time basis and they tend to come armed with upfront design work. They are not available to answer questions promptly, and they are constantly context switching – not massively productive. This causes both delays and a drop in quality.

So… let the team make UX and design decisions?

The team can decide to make these decisions by themselves, but they have to context switch from their main tasks, causing delays. They are not the best people to make design decisions either – would you ask a designer to make tech decisions? Decisions made by people who lack the core skills required causes a drop in quality.

The team could ignore the problems to try and avoid all these hassles. They can just do what’s been specified even if it has a massive development cost for very little benefit, causing delays. Or building out mistakes, causing a drop in quality.

Create a truly ‘cross-functional’ team for a successful product

If you want your team to be hitting the ground running at optimal speed to produce a successful product, make sure you have a truly cross-functional team with UX and Design fully integrated into it.

The keyword here is ‘successful’. You can deliver a set of features on time on budget without UXD. But if you want to deliver a successful product, you definitely need them.

Maybe we need to be called something different so that people have a greater understanding of what we do and the value we deliver. Any suggestions?

---

We are looking for a new digital designer to join our team; if you'd like to find out more check out our current vacancies page here.

Sari Griffiths

Chief Design Officer

More from Sari