When cross-functional teams meet design
I’ve recently started getting into the topic of user experience, design and what it means to run a team of designers, thinking about how designers can effectively engage with cross-functional teams. One key pitfall I’m keen to avoid is having designers end up like architects, where they are always trying to get more engaged but only perceived to be desired when the team needs them.
These roles are specialized and not embedded in every single team. This tends to lead to the problem where these specialists get involved too late. This makes it hard for them to make impact as they are often seen coming in telling teams things that would effectively derail their work for weeks or months depending how much focus has been placed on the architecture and design of an application / product.
Having worked as an architect for several years, this was a common occurrence in the past. Teams would come looking for you when they realized that they couldn’t proceed to deploy without the architects ‘blessing’. This experience often ended up in a log jam as architects raise concerns that teams often don’t think of when they are trying to ship code.
Thankfully, this type of thing happens less and less, but many people are familiar with the anti-pattern of where an individual / SME is needed but the team only realize too late and then bring them in just before the team are looking to do their first release into production.
The moral of the story is to get engaged as early as possible, build relationships with teams, and get them to understand how you are there to help rather than hinder and if these discussions happen up front then collaboration and a smoother glide path is possible.
Back to design and user experience, engaging earlier and more often is an opportunity to create value and often to create cheaper and faster feedback loops. We know from ideas like MVPs and similar that validate your learning as early and cheaply as possible allows you to not fall victim to your own confirmation biases and validate or invalidate potential ideas as early on as possible.
Like all things in life, there can be too much up-front design / architecture / analysis, so it is important to do these things in a way that allows teams to learn and iterate with their approach. What is clear is that the later in the process a team is, the more costly change can often be. The alternative is often a refactor or a significant redesign and that often causes a lot of friction with the team and the SME often feels like the bearer of bad news.
I imagine it can be quite easy for a UX designer to over design an experience for a product, which can lead to the designer being too committed to their artefacts / design. Low fidelity wireframes and prototypes are often a good balancing way to keep things light weight and not gold plated.
If your product manager or stakeholders cannot stomach low fidelity mock-up of a design, then having a design system can allow for faster but ‘better’ looking wireframes that are closer to what you’d like in real life but be careful again with the biases that people can interpret a high-fidelity prototype / mock-up as a finished product, so keeping people aligned with expectations and context are key.
This experience will depend on the organization perspective and experience around design and user experience and product management as well. If the organization is focused on creating value and they are product centric, they are more likely to orient towards user needs. This is an opportunity for product people and UX people to truly collaborate.
I intend to keep this article concise but there’s several ways to get engaged with teams that are lightweight, low cost and yet incredibly effective.
Recommendations for working with teams
- Lean UX — Geoff Gothelf & Joch Seiden
- User Story Mapping — Jeff Patton
- Dual Track Development is not Duel Track — Jeff Patton
- Continuous Discovery Habits — Teresa Torres
- Sprint How to solve big problems and test new ideas in just five days — Jake Knapp
For future articles, I’m interested in sharing and exploring more User Experience related topics such as the value proposition of user experience, adding value to an organization, design systems, information architecture, experiment, and testing practices.
