Why multidisciplinary teams are good
This is the transcript of a talk I gave recently, at CloudCamp’s 2018 Digital Transformation event.
“Let’s look at why multidisciplinary teams are good.
The bottom line is everyone in such a team has different skills, and brings unique specialist knowledge to the table.
But crucially, you get this range of expertise at the same time, allowing a very rounded view.
This leads to an informed, efficient design and development flow. “Pie in the sky” solutions can be quickly shot down by the user researcher saying “there’s no user need for that” — way before designers waste time prototyping a useless thing, and way, way before developers waste time building it.
OK, I’ve mentioned a couple of roles, let’s look at what a multidisciplinary digital team could consist of.
On the creative side, ideally you’d have at least a…
● user researcher
● service designer
● content designer
● developer
With smaller projects the designers and developer/s would probably need to be “unicorns” — though I’d offer “shapeshifters” as a more accurate descriptor! By that I mean these roles would also cover…
● user experience design
● interaction design
● technical writing
● front end development
● technical architecture
● back end development
With larger projects, dedicated resource for each discipline could be available!!
Then on the logistical side you’d have a…
● product manager (aka product owner)
● delivery manager (aka project manager)
If your product is one of many across a service you’d also need a:
● service owner
OK so we’ve looked at who’s in the team. I mentioned earlier that each team member bringing their unique professional expertise is good.
But what’s also cool is that they look at things from differing perspectives.
A user researcher looks from the user’s perspective. They don’t know about — or need to know about — system constraints or project budget.
Service designers and content designers look from the user’s perspective, but they’re somewhat aware of software and system constraints.
They don’t worry about the budget either, they just want to iterate the product to work best for the user.
They both talk to the user research part of the team A LOT.
A developer looks from the system perspective — how do I turn this design into a reality, what is technically possible and what is technically not possible. They are very aware of system constraints.
They’re usually on a tight time budget. They know how long it takes to develop something whizzy a designer’s dreamt up and have no qualms about putting the kibosh on it, unless the designers, with back up from the user researcher can prove a solid user need to justify extra time and resource spend.
The designers would need to put this justification to the product manager and delivery manager, because those are the roles clued up on money and time budgets, and limitations of project scope.
Let’s look at their perspectives.
The product manager looks from the stakeholders’ perspective, what is the business trying to achieve with this product?
The delivery manager looks from the project’s perspective. They are focused on timescales, removing any blockers clogging up the development flow and getting everything the team needs, within reason and scope. They tend to like a Trello board.
Delivery managers also look from team member perspectives. They can make the case to the business for more tools, resource or time — when they understand why the project needs it.
One delivery manager I worked with recently found that chocolate fell under “everything the team needs”. Yum.
So how do all these roles and perspectives work together successfully?
When it works well, the team discusses what’s right, what’s the best decision. When it works badly the team argues about who’s right.
Seriously, there are ways to get to this Elysium of what’s right not who’s right.
All the team:
- attend user research sessions
- are involved in user research analysis
- see themselves as equal and feel able to push for their professional, expert views
- understand each others’ roles
- keep each other updated on what they are working on each day, mention things blocking them and come to team presentations and meetings
Any one of the things not happening can undermine the whole project. They are all that important.
But when they are all happening…
★ The user researcher can say to the product owner, there’s no actual user need for this aspect, let’s get rid of that.
★ The content designer can supply user-friendly wording for the user interface.
★ The service/UX designer can talk directly to the developer about the most user-friendly alternative if the ideal functionality isn’t achievable, so
that the developer doesn’t have to take a guess.
★ The developer can advise the designers of things that ain’t never gonna happen — the pink flying elephants.
★ The delivery manager can, theoretically, bring in more resource if a blocker puts pressure on timings or an aspect of the project needs more work than estimated.
★ Everyone can co-decide what the Minimum Viable Product really needs and how long it’s likely to take.
This is some of why multidisciplinary teams, that work cohesively, are good.”
Talk given at CloudCamp, 26 September 2018.
Support the author?
If you found this article useful, why not buy the author a coffee. Not only will the author love you for it, but it helps keep content free to access. ☕️
