The “unicorn designer” has been a common trope in the design industry. While everyone may want that multitalented designer, it’s important to think about the implications of this idea on both designers and the relationships they have with developers.
What makes a designer a “unicorn”?
Let’s start by defining what a unicorn designer is.
A unicorn designer is the most in-demand and rarest of product team members – someone with excellent interaction design skills, visual design skills, and coding ability.
Link
The term was coined to summarise something seemingly impossible — find someone who can not only design, but also articulate design decisions, manage stakeholders, and code/ship those designs at the same time. It described something mythological, like trying to catch a unicorn.
As is their way, though, the design community took on this challenge and a new breed of specialised cross-functional designers were born. We’re here, we’re up—skilled – get used to it!
Why we should all be aiming to be unicorn designers
To me, being a unicorn designer is less about the skills we have in the coding arena, and more about the empathy and general understanding we have in how our dev teams work and build awesome stuff. Many designers, myself included, work primarily in the digital space, it’s where we live, laugh and love during our work hours but the very nature of working in digital means that as a minimum we need to understand the basic frameworks of how our designs are built.
If we design the greatest web experience known to humankind, but our dev partners can’t build it — that’s a frustrating experience for the designer.
If we design something that puts our web team in the position to either turn it down or attempt to build something impossible – that’s a frustrating experience for the developer.
Either option means additional back-and-forth between designer and developer and ultimately, a stretched out timeframe, frustrating comms and misunderstandings, and most dangerous of all, a bad experience for the briefing stakeholder. A stakeholder who might not understand the technical aspects of what, why and how, but now understands one thing more than anything else: “The two teams I rely on to bring my ambitious ideas to life, aren’t collaborating in a constructive way”.
We’ve all been there.
It’s an impasse. The typical designer wants to be the next Van Gogh, regardless of how it’s built. The typical developer is less interested in how something looks and more interested in how it functions.
Enter the unicorn designer. The unicorn designer removes this ambiguity. They’re a solid and communicative partner to the briefing stakeholders – giving them confidence in the project – while also being a strong representative for our dev partners as well. We work side by side, coming up with multiple solutions to a problem: one that’s super ambitious, one that plays it safe, and we expect to meet somewhere in the middle. We work with the dev team before showcasing designs so that all the wrinkles are ironed out before concepts are previewed. This means that the stakeholder only ever sees designs that are fully capable of being built, and the dev team is joining the showcase sessions as an active ally, rather than another stakeholder with feedback.
You’re presenting and defending the work together as a unit.
What’s beyond a unicorn designer
A lot of emphasis is placed on a unicorn designer being able to code, and while that’s always a great skill to have, I propose that it’s more important (or at least equally important) that as designers we understand how things are built in their most basic form. Understanding how CSS works and the rolling effects it has throughout a site, how tables and cells behave when responsive and the breakpoints and limitations they have, the importance of grids and alignment – I could go on.
What I’m saying is that it’s most important that we understand the playground our dev partners work in, as opposed to how each piece of playground equipment is built. To put this in Intuit terms, we should be having regular syncs with our dev team partners (Follow-Me-Homes) so we gain empathy and understanding of the way they work and in turn become better partners.
The funny thing about empathy and collaboration is that it’s infectious. A team who recognises your efforts in understanding their ways of working is suddenly also interested in closing that gap from their side to become a better partner to you too. It’s a rather pleasant and productive cycle to exist in.
But we can kick that up a notch. We should be aiming to achieve this sense of teamwork, empathy and camaraderie with every team we work with, not just our dev team.
Our marketers should have full confidence when submitting a brief that we understand their broad goals and audiences and that we’ll propose solutions that play to the best results of both those tracks. All our teams should all feel the same way.
Gone are the days where we place our berets firmly onto our designer heads and sit broodily in a dark corner as tortured artists, grumbling about feedback like “can you make it pop more?” or the dreaded “can you make the logo bigger?”.
Now we’re network builders. If we don’t like the way briefs are coming in we should be proactively re-training our partners to provide better briefs, if we have a reason for a design decision, we should defend it in a diplomatic, data-backed way.
Why relationships play a key role
Of course, a lot of this is easier said than done, and we need time and patience to build that level of relationship and trust. The end result, however, is a network of strong allies with confidence in the work you’re producing, so it’s worth every effort.
Some may be worried that by collaborating to this level it removes our ability to do outrageous and innovative designs. Let me clarify: I’m not saying that we designers shouldn’t be bold; I’m saying that we shouldn’t be bold alone. We’ve spent our careers building the skills and knowledge we have to make the things we can make, but so have our partners. To not leverage on their experience (while staying strong to our own core beliefs) would be a wasted opportunity.
As unicorn designers (or aspiring unicorns), let’s instead aim for collaboration over segregation, partnerships over isolation, and always best-in-class work.
The big asterisk attached to this goal
A note I’d like to wrap up on is that being a unicorn designer can come with a heavy price tag. That is the pressure you place on yourself to always be relevant, be at the top of your game, and try to master multiple disciplines instead of just one. Once you’re on that merry-go-round, it can be difficult to jump back off! We’ve learned over the last few years just how real burnout is, and it’s something we should always be keeping in mind.
Explore what excites you when working with other departments, set goals for overlapping skills, but also set time aside for yourself to breathe and celebrate your accomplishments. You’re not Sisyphus, pushing a boulder up a hill by yourself forever. You have the full weight and support of your team behind you — lean into them!
