To that end, a bunch of us (virtually) attended Config this year to hear more from our favourite tool. Amongst the excitement of new features and functionality – FigJam! Branching! Audio! Be still our beating hearts! – there were some equally exciting talks.
Spoiler alert: we think they should. And more than that, we think everyone should.
Designed by developers
We frequently work with product teams who have a platform that’s profitable and has plenty of users, but that is running into limitations due to a lack of design input.
This tends to be a classic ‘designed by devs’ situation, often where leaders have great ideas and in-house developers have great technical aptitude, but neither have a great deal of UX/UI skill.
The outcome is a product that’s powerful, with a lot of functionality but that users find confusing or tricky to get the most out of.
(um…wow….that’s quite the UI 😅)
If this is something we’re familiar with as a problem, why the heck do we agree with Mina that devs should design?
If we’re the design experts around here, and devs don’t have the same skills as us, then why shouldn’t we alone be the guardians of user needs, and the ones to produce beautiful interfaces and slick interactions?
Why shouldn’t we then throw these complete designs over the wall to the devs at hand-off time, letting them focus on their coding, unencumbered by thinking about users or brand considerations?
When both sides stay in their own lanes and don’t interfere with the other, we produce better products, right?
Well, no. Quite the opposite in fact. Let’s explain why.
Creating the perfect workflow between UX/UI and development teams
Getting separate teams to work in unison is tough, but we’ve got top tips for getting design and dev teams aligned.
Collaborating product teams
Handoff culture, where everyone works in their own silos, doesn’t lead to better products. It’s just a fact.
In the segregated scenario above, what do you think happens if…
- the designers create something visually stunning but difficult or impossible to implement?
- the developers don’t have adequate documentation, so they have to guess which parts are important and fill in the blanks, implementing what they can as best they can?
The result isn’t pretty, (and it’s not very usable either, as Pablo Stanley‘s illustration above shows). Both sides get frustrated, things don’t work as they should, delays are liable to happen and stakeholders aren’t happy.
Mina revealed that an average of seven hours a week are wasted by product teams stuck in handoff culture, due to poor communication and collaboration. That’s 364 pointless hours a year! 😱
To be clear, moving beyond the design handoff into product collaboration isn’t throwing your devs into Figma and making your designers learn React.
Instead, successful collaboration hinges around getting everybody using the soft skills involved in UX design; we don’t just think this should be confined to devs.
Project managers, business analysts, marketers – anyone involved in a product can and should be involved in the process of designing it.
Design thinking for teams
Design soft skill #1 is empathy for users, and a great place to start.
How about bringing team members who aren’t designers into user research, as a starter for ten? Could they observe? Take some notes? Even ask questions directly themselves?
Four ways to win at user research
Which user research methods do we rate, and when should you use them?
Could you even get everyone running some user testing, perhaps on an existing element of your experience for a low risk but high value learning experience?
Experiments of this kind can seem scary for design teams who’ve been used to being the sole point of contact for users, but letting others into ‘design spaces’ is a key part of ridding product teams of handoff culture.
Every single person in your organisation has ideas for a better product that should be listened to, and every last one of them can learn to use these skills to good effect.
Why autonomous teams make awesome products
What happens when a product team runs as an independent unit, setting their own KPIs and choosing their own tasks?
It was great to hear Mina and dev colleague Sam explain the positive effect of trying this out at IBM. Both spoke about increased empathy – not just for users but for each other.
Devs reported feeling happier and more motivated to produce better work as they felt a stronger connection with the user, and greater insight into the necessary nuances.
The team also saved a whopping 50% of the time it used to take from design to implementation, just by getting non-designers involved from the get go.
Once we’re out of our silos and design isn’t kept under lock and key, we’re happier, more efficient, and our products are better.