What does your product team look like?
Would you change anything if you could?
As part of agencies and in-house teams I’ve seen many different takes on product org design. Things got done one way or the other, but the teams were often far from optimised and it wasn’t always without friction. I saw a lot of overlap in skill-set, and role descriptions that narrowed down people’s responsibilities to a sub-set of their true potential.
It’ll become apparent that this article is written by a former UX designer (former not because I’m retired but because I refuse to use that title any more). Too often it’s a role being shoehorned between other roles when it shouldn’t be there in the first place.
To figure out what skills we can shuffle around and get a more optimised team we first need to look at our building blocks.
The typical roles involved in digital product design
Let me list some typical pre-development product team roles and what they are often expected to be in charge of.
Delivery / Project manager
- Plan activities and timings
- Coordinate and scope team effort
- Manage client and stakeholder expectations
- No issues here, they usually let us get on with work
Product owner
- Product strategy and roadmap
- Manage 3rd party relationships
- Track performance
- Final say and sign off
Design strategist / Business designer
- Typically an agency role overlapping product owner, user researcher and UX designer
- Functional and business requirements
- Product strategy
- Content strategy
- Research
UX designer
- User research and testing
- Functional requirements
- Journey mapping
- Information architecture
- Content strategy
UI designer
- UI and visual brand exploration
- Design system management
- Visual & Interaction requirements
- Production design
Business analyst
- Functional requirements
- User stories and sprint preparation
- Acceptance criteria
Usually backed up by:
- Head of design / Creative director
- User researcher
- Copy writer
- Quality Assurance tester
And to make the list complete I’ll also include the dev roles I’d normally work alongside:
- Front-end developer
- Back-end developer
- Systems architect
- DevOps engineer
You wouldn’t normally see a team with all of the above roles. Some are more common in-house and some are more agency related. It’s also not uncommon that one person straddles multiple roles. I’ve had product owners also acting as delivery managers, QA being dealt with by the dev team and UX designers doing BA tasks.
None of these roles are superfluous when combined correctly. They all possess unique skills that can be utilised with minimal overlap in an optimised team structure.
The question is; what is that structure? I think the answer is in the design process:
Discover, Define, Design, Develop.
Four distinct phases to product development, each of which requires unique skills. Let’s examine them and see what those skills are and what roles they might translate to.
Skills required for each step in the design process
Discover
This phase is characterised by problem/opportunity definition, business requirements gathering and market and user research. Skills you want here are product strategy, workshop facilitation, quant and qual research. The define phase could be a joint responsibility of a product owner and a researcher, or it could be handled by someone possessing both skill-sets.
We haven’t talked about the service design role up to this point, as it’s less to do with product development and more with organisational change. But if we look at the service designer’s toolbox we find all of the above mentioned skills.
Having said that, the product owner is essential to any product team and for that reason I’m inclined to say that a product owner with service design background would be my go-to candidate for the Discover phase. If it’s a large project and there’s budget for it they should probably take use of an external research agency, because research, as we know, is a time-consuming activity.
Define
Define is a proportionally short phase in the process. I considered merging it with the Discover phase, but in doing so I would’ve missed out on a crucial step. Once the discovery phase come to an end and presents its synthesised body of work, it’s the job of a strategist to decide how to proceed to achieve a desired outcome.
In one company I worked for, the discovery phase had presented a market opportunity to build a product that brought all household bills into a consolidated view. In this case the product owner was the one picking the way to market, deciding that we’d initially focus on the flat sharer segment, and due to the nature of the service would serve them via a mobile app. He could’ve chosen 100 other routes to market but this was his product strategy.
The point I’m making with the above example is that Define is extremely important since it will shape all the work thereafter. For that reason I’m choosing to break it out from Discover. What you need here is an experienced and visionary person who can spot market trends, use data to form an opinion but also trust their gut feeling. Finally they need to be able to communicate the strategy and inspire the team. This is not a small feat and it must land on the product owner’s list of responsibilities.
Design
Once the product strategy has been decided we enter the Design phase, which includes design exploration, concepting, information architecture, technical feasibility, design system development and screen design. Some of these tasks might happen pre-development while others happens alongside development in an agile manner.
We need skills like IA and systems thinking, visual UI design, interaction design and possibly animation, UX writing (i.e. UI focused copy writing), prototyping and usability testing. There’s a lot to cover in the design phase, and that’s why it has traditionally been broken into UX (function) and UI (form). However, if you have come across my writing before you know I’m not a fan of this separation and I much rather hire “full stack” product designers capable of doing all of this. I’d also get copy writers who can span everything from marketing to UI copy.
In reality it’s hard to find designers who can do it all, and you should consider a split between UI designers (or product designers if you like) and system designers. The UI designers do the product architecture and design from concept to screen layouts and testing. The system designers own the design system, including interaction design, visual styling and accessibility guardrails.
This means that for screen designs there will be close collaboration, but in an ideal world the UI designer can build the pages with existing components, and when components are missing they can request them to be added to the design system backlog.
Develop
In terms of development I’d be stepping out of my remits to say what the ideal team structure is. I normally work closely with developers, solution / system architects and business analysts and what stands out to me here is the business analyst (BA). As a UX designer I’ve always had a large overlap in duties. If there’s one in place I can be a lot less rigid in my documentation and trust that all requirements will be neatly added to the sprint backlog. If there isn’t one in place I have always made sure that the visual and functional UI requirements have been fully documented in a consistent format.
Can we afford the luxury of a BA on the team, or should we let the UI designer document their designs as user stories including acceptance criteria? This is an elaborate task, so for now I’ll keep a BA on the team and include them in the design phase by taking the product owner’s direction and translating it into product requirements and design briefs for the UI designers.
This way the BA becomes the interface between designers and the rest of the team. This doesn’t mean that design happens in a black box where designers never discuss with developers or business, but it can be a great relief to be able to fully focus on design and should in theory remove friction for the team.
What about designer/developers?
I was also considering bridging the gap between design and code by using front-end developers who are skilled in UI design (and basically exclude UI designers from the team). But skilled is not enough – most front-end devs know how to apply UI design theory. The developers I work with take a real interest in the usability and usefulness of the end product. But what they really care about is writing great code. Most developers that care enough about design to be great designers eventually jump the fence and become designers full time. The days of the web-designer is over, and the few that can generate both great design and great code are not called unicorns without a reason.
Summary
Looking at my dream team I realise I have made myself more or less redundant. But I guess I knew that was coming. My title was UX designer for a long time, and I don’t think UX designers should exist. If this was indeed my team I reckon I could either lean on my service design knowledge and be the product owner, or I could be the UI designer.
I’m keen to hear your thoughts on this theoretical team structure. Would it work in reality? Would you fit in? What does your dream team look like?