Published: 4 years ago

Unicorn, Shmunicorn—Be a Pegasus


If you’re reading this, you’re probably a designer. Maybe you code, maybe you don’t. But it’s likely you’re feeling more and more pressure to hone your programming skills and become that mythical product development creature who can both create compelling designs and write production code.

There are plenty of reasons why being a unicorn isn’t all it’s cracked up to be. What you might not have considered is that aspiring to be a unicorn could be the biggest mistake of your career.

Conflict of Interest

Having a coder and designer in the same body is tricky. The coder must, above all, serve the machinery, the OS, and the programming language. They have to, or everything goes boom! in a really ugly way.

Meanwhile, as a designer, you focus on human-scale issues, and you’re comfortable grappling with the inconsistencies of human nature. Which is good, because there’s a metric ass ton of those.

Both roles are essential to the creation of great software, and close collaboration between a stellar coder and a top-shelf designer—along with a solid product manager—is the fast track to a world-beating product.

But when you try to package these skills in a single person, conflicts emerge. What happens when user goals and technical constraints collide as deadlines loom? Do you build the best product for the user, or the product you can implement in the allotted time given your technical abilities?

The hybrid coder/designer is not a new idea. Coders who designed software by default were standard issue in the 80’s & 90’s. The result was a flood of badly designed products that made an entire generation of normal people feel exceedingly stupid as they thumbed through the pages of their “Dummies” books. In fact, the primary reason software has improved dramatically is due to the establishment of software design/UX/IxD/etcD as a separate profession. Your profession.

The movement towards unicorns reverses this progress by assimilating designers like yourself into the coding collective, shifting your attention away from the user and towards the technology—which is what got us into that mess in the first place.

Checking the UX Box

A singular aspect of the Great Unicorn Quest that should give you pause is the implication that user experience & design as a discipline isn’t significant enough to be a sole focus. As if designing products that people love isn’t sufficient to justify a full-time position.

I mean, sure, you can get to know your users and customers, determine needs, wants, & goals, create personas, invent a concept design, craft the interaction flows, produce detailed wireframes, design pixel-perfect mocks, respond to last-minute feature requests, create production assets, and a million other details I’m glossing over, but when are you going to do some real work? You know, like code something.

Frankly, if your company doesn’t feel that UX & design is important enough to be a full-time position, you should question how committed they are to an awesome user experience. And for that matter, how you want to spend the next few years of your professional life.

Drowning in Details

User experience and design requires a lot of detail work; flows, wireframes, edge cases—you know the drill. You may already be so consumed with reactive and detailed design work that you don’t have adequate time to explore big ideas with the potential to dramatically improve the user experience.

Well, there’s one sure-fire way to make this worse: spend lots of time worrying about the details of a neighboring discipline—programming. Why isn’t this build working? What library can I use for this? What’s with this jacked-up PHP code?

Your time is the ultimate zero-sum game. The more you spend on the complexity and details of coding, the less you have to make the product experience better for your users or to influence product strategy.

A Better Idea—Be a Pegasus

It’s time to think bigger and more strategically about your career. The software industry needs high-powered product people in VP Product and Chief Product Officer roles. Today, these positions tend to be filled by people who came up from Marketing, Product Management, Engineering, or general Business backgrounds. And some of them are very good in these roles.

But who better to take on the product challenges of the future than cream of the crop UX & Design professionals? Who is closer to the intersection of people’s goals and a company’s products than the designers sweating over every detail of the user experience, day in and day out? Rather than re-inventing yourself as a part-time, mediocre coder, consider aiming your trajectory squarely at these product leadership positions.

Instead of diving into the tactical details of programming, level up. Shadow your product managers and learn how they operate. Take a deep dive into your company’s product roadmap. Explore your company’s market strategy. Discover the top three things that the CEO is concerned about. Understand the higher level strategies in play at all levels of the business.

Don’t aspire to be a unicorn, digging up nitty-gritty coding grubs with your horn. Unfurl your wings and see the 10,000 foot view of where your business is headed, then use your design perspective to help your company and industry soar to new heights.

Be a Pegasus.

  1. Ingmar says:

    Or even better: drop design as profession and get paid for your work being a 100% coder!

    • Tim says:

      Most of the software industry (at least that I’ve encountered) seems to be built around the ‘fiefdoms’ of UX, Product/ Marketing, and Engineering. It’s both a culture-and-control thing as well, with groups jockeying for position in the development lifecycle.

      I’ve personally tried to convince others (including showing them HTML / CSS / JS scores from tests) of my abilities and willingness and desire to tackle code, as well as product management, but the data alone does not determine your fate in these things. I for one would love to completely disrupt this entire profession in that respect.

      This is a human and organizational problem, with many of the most progressive organizations not understanding the fuzzy and porous boundaries of these disciplines. Also, how do you measure and promote in a large company once you level up and assimilate other entire disciplines into your arsenal? Do you promote the amazing product manager or the great product manager that can also do UX and code some stuff?

  2. This +1000. Where do I buy the T-shirt?

    I want to contribute, but I think you covered what I (and others) have been trying to say for so long, so well, it’s hard to find a gap to fill.

  3. I like! 🙂

    You could say the exact same thing about separating UX and Graphic Design though. How are you going to think about all those weird edge cases in your user flow if you are busy looking for the pixel perfect font?

  4. Steve Henty says:

    Like the idea of spreading UX influence, not a fan of the tone or the implications.

    The reason to become smarter about delivery is to collaborate better with those delivering the product, and help them (and you!) search for solutions. The same can be said, incidentally, of how to collaborate with PM and others who are responsible for prioritizing the deliverables… learn something about their process, pain, and joy.

    What seems conveniently overlooked in your quest for PM and VP roles is why having your UX focus “collide with” the demands of scarce business resources and client demands is any less an ugly master than the demands of broken builds and production problems.

    As many in our profession discover, we play a critical role as the third leg of the stool supporting a successful product, those legs being: Business (PM/VP), Delivery (Engineering), and Experience (UX). I believe the Unicorn argument serves to highlight the benefits that accrue when *all* the legs recognize the value of the others – the stool is greatly diminished by the removal of any its legs.

    The Pegasus argument, by contrast, appears to lead to the conclusion that either a) Business and Experience are both easier than Engineering, and therefore can be balanced by one person, or b) Experience is the wrong leg to bolster, since the power is in the Business. Either of those two conclusions may easily serve to weaken Experience in the face of Engineering or Business, which I would guess is not the intent.

    At the end of the day, perhaps the best path to being a good Experience steward is to understand enough of both the business and the engineering to know how to pick the right battles, when to press firmly for a design, and when it’s either okay or in the best overall interest to give on the design in favor of other priorities.

    And I’m not sure it matters which mythical creature we ascribe to that set of characteristics.

    • Wayne Greenwood says:

      I agree that the collaborative triad of UX, PM, and ENG yields the best product development results. I mention that briefly in the “conflicts” section of the article.

      It’s also true that being a pegasus means spending more time on business issues. But the collisions between UX and business issues are where strategy is formed—strategy that we’ll have no part in shaping if we’re buried in code when it goes down. UXers with a strong grasp of business will strengthen UX as a field by demonstrating an ability to balance user goals with business goals and the constraints of schedule and technology.

  5. Hmm. You make a good point, but it’s a bit too black and white for me. Flapping your wings and getting all strategic isn’t for everyone. Not all interaction designers and IAs have the aptitude or the desire to be a Pegasus.

    Ditto for the so-called unicorns. Some designers can pull it off. Most can’t or just don’t want to. Which is fair enough. Different strokes and all that.

    But I think that having some coding ability is useful—especially in agile environments, where being able to muck in and help with things that are a bit outside your own field is extremely valuable.

    • Wayne Greenwood says:

      I believe that a UX pro is well-served by having a solid understanding of the technology, in the same way an architect knows enough about brick, steel, and wood to ensure that what they design can be built. But that doesn’t necessarily mean they should spend half of each week swinging a hammer.

      Being a pegasus isn’t for every UX professional, for the same reasons that not every engineer wants to be CTO. If what you really want to do is focus solely on product design, then strategy and management could be an unwelcome distraction. I understand and respect that.

      My suggestion is that UX pros who desire to influence product strategy should put themselves in a position to do so, rather than accepting the idea that they must instead become a hybrid designer/coder.

  6. AnnMaria says:

    I’m both a designer and a coder – as well as CEO – because we are a small start-up and all wear multiple hats. I completely agree with your point about the POTENTIAL problems with having design done by programmers. One example is that we are this minute completely re-doing our installation process to be one or two clicks. The flip side of doing both design and coding, though, is that I know when I am asking our team to do something really difficult for a very minor improvement in user experience. In some cases, as with the install, I don’t care how much work it is, it needs to be done. In others, like adding a time stamp to data collected so parents or teachers can see how long the student player a game, the extra effort is minimal. There are those mid-range cases, though, where we are asking A LOT in terms of either processing demands of the hardware or programming effort from our staff. In those cases, having both coding expertise and some hardware knowledge can be really helpful.

  7. Ricardo Zea says:

    I wholeheartedly agree.

    Funny thing is that right now I’m actually looking for a new job and the job descriptions I read are hilarious because these businesses are SERIOUSLY looking for that Unicorn: Someone that knows about Web Design (design principles, UI design, Interaction Design, HTML, CSS, CSS Preprocessors, JavaScript, jQuery, etc.) and Web Programming (PHP, .NET, Java, Classic ASP, C#, Node.js, Backbone.js, etc.). I’m seriously not making this up.

    Also, I’m a Web Designer that can also do Front End Dev and have had employers ask me which one I do most, design or development and when I tell them both 50-50 they don’t seem to get it. Seems they either don’t expect to find someone that designs and codes his design, or expect to only find people that do either one or the other but never both.

    “The software industry needs high-powered product people in VP Product and Chief Product Officer roles. Today, these positions tend to be filled by people who came up from Marketing, Product Management, Engineering, or general Business backgrounds.” — 110% agree. This is EXACTLY what I experienced in my last job and the quality of work being done and the speed at which it was done… oh boy.

  8. Jon Bell says:

    Liked your post a lot, and I agree with a lot of it and the general tone of the comments here.

    But I remember history exactly reversed. I saw a boost in the quality of software/websites around the “web 2.0” timeframe. Flickr, Blogger, later Twitter, etc … these were companies who stopped the old habit of “designer makes psd, cuts it out, and tosses it over the wall to a dev”.

    It’s not that all their designers could code, but there was clearly a synergy between the professions that hadn’t been seen before. It upped everyone’s game.

    • Wayne Greenwood says:

      Most of the bad software I refer to came in the form of desktop software and early websites. The buzzword “Web 2.0” wasn’t coined until the end of those decades, in 1999.

      I agree that designers throwing stuff over the wall isn’t very effective. I believe in a close collaboration between a designer, engineer, and product manager—the magic trinity of software development.

  9. Robb Beal says:

    There’s a lot of truth in this and it’s great advice for designers with those ambitions!

    That said, if any company is looking for *production-level* engineering skills along with world-class design skills, then they’re insane. What they may be looking for, but asking for poorly is a) logical skills generally or b) *prototype-level* engineering skills. The former is a very reasonable given the nature of digital products and the latter is a consequence of the rise of the importance of the (active, browser) prototype.

    For junior designers or senior designers who couldn’t imagine not being in the trenches designing products, here’s how to shape the conversation…

    Prospective Employer: Tell us about your technical/coding/engineering skills

    You: Good question! I’m a highly analytic/logical thinker. Designing complex digital products requires making decisions on and communicating hundreds of “Design Rules” that aren’t part of the visual blueprints used to build the product. I often communicate these “Design Rules” using pseudo-code (which is a structured, human readable description of the rules) that my engineering colleagues will turn into production code. So that’s one level of “coding”.

    Additionally, I’ll be prototyping key parts of the product in the browser, so, I’ll be doing some prototype engineering, especially to convey key animations and opportunistically pulling in a client developer if the prototype engineering requires it.

    Later, after the prototype(s) has been accepted/finalized, the engineering team will be turning the prototype into product. Often, lots of my style and animation code will make it directly into the product’s code where I’m able to make refinements myself as the product goes through a final coat of fit and finish.

    Sometimes I even leave little easter egg comments in the code. The last time it was about unicorns!

    Prospective Employer: When can you start?!

  10. Lefteris says:

    I’m a PHD architect that designs and builds sites since 1995. Code has always been my building material.

  11. Sam Morgan says:


    The author takes one premise: that being a designer and being a coder are fundamentally different mindsets. They aren’t. Both are solving problems, and skills in one area can help to articulate problems better in another.

    An ability to streamline UX is instantly transferrable to an ability to streamline CSS, if you have the technical aptitude. A deep knowledge of how the architecture works from a user perspective enables you to construct code in a sensible, thoughtful way. Coding is not just writing lines to implement functionality: it is structuring a complex body of functions, each drawing off one another. In many ways, design is the same process: systematically taming complexity into a coherent, cohesive product.

    As with most human taxonomies, the problem is not a matter of aptitudes. It is a matter of attitude. Being a ‘designer’ does not preclude you from gaining a skill-set somewhere else, but it does give you an excuse to believe you cannot. Ditto coders who ‘can’t design’. There are no ‘mythical creatures’, only those who’ve decided to put their self-classification aside and jump in.

    There is huge intersection between design skills and coding skills. Occupying the middle ground is simply a matter of approaching one with the same mindset as you do the other: but you have to make the approach first.

    • Wayne Greenwood says:

      Designing for humans and coding for machines are absolutely two different mindsets. Yes, there are people who can do both at a high level, and if you fit this category that’s awesome. But don’t assume this combination of skill, aptitude, & desire is commonplace—the scarcity of this combo is why these individuals are referred to as “unicorns.”
      (BTW, when I say “code” I don’t mean just HTML and CSS. Native mobile apps are the new black, and that means Objective C, Java, C#, etc.)
      That said, the debate about designers coding is only a sidebar here; the premise of this article is that UX professionals with the aptitude and desire should use their non-design time to learn product management & business strategy with the goal of filling VP Product and Chief Product Officer roles in the future. Do you disagree with this idea?

  12. Dennis says:

    Always felt there was a need for a C-Level design position like Chief Design Officer. But Pegasus is cooler.

  13. Ed Lea says:

    The only part of “designers should code” camp that I sympathise with is when you use code for design. For example, in the flash days, Action Scripting some easing effect or using expressions in After Effects. I see that kind of scripting as just another design tool.

    It can extend into front end dev or ios/android development where you design the interactions/physics in code. But equally, you can use more graphical tools to demo the same functionality to a developer.

  14. Jake Hawkes says:

    I have learned more about development by learning design that I could have ever learned through mythology.

    If you want to delivery the best possible solution you have to either understand both code and design or work very closely with someone beyond your skill-set and trust that they know their shit. There are big limitations in implementing application design on the web. If you don’t understand the environment you’re designing for you’re not helping anyone!

    EXAMPLE: I have spent days learning the best implementation methods for many seemingly simple and ‘solved’ UI patterns. Take the simple web font. There are literally thousands of designers and developers working on font legibility on screens, enough said!

  15. Michal Kopec says:

    Enjoyed reading your post Wayne. Your point “if you want to have more influence over a product = move into product management” instead of “learn to code to build the product yourself” is a good one.

    I design and code prototypes. The code is yet another vehicle for communicating with the audience I’m selling ideas to: users, VPs, PMs, engineers etc. Code is yet another tool in the designer’s toolkit.

    Funny, over the years I’ve noticed that doing design isn’t the most difficult part (not to belittle any profession) but getting it into a product is a whole different story. This is where understanding and speaking the business and technology lingo is crucial. And there is no better way to learn the technology lingo then getting your hands dirty coding prototypes a.k.a “conversation starters”. Want to learn about business? Do a freelance project or start your own company (and no, do not get an MBA).

    As with most things in design having the right design vs code vs business BALANCE is vital. And this is where your competitive advantage *should* come from.

    I also believe the distinction between designers are coders is mostly a function of archaic tools we use in either role. Bret Victor does a great job re-defining what it means to be a designer/coder in a world where the tools do not stand in the way of our creativity. Please see http://worrydream.com/MagicInk/#designing_a_design_tool or take a look at http://www.kickstarter.com/projects/noflo/noflo-development-environment

    PS. watch out for the “you do not control what you’re not building yourself” camp 🙂

  16. Joey Golaw says:

    Your position seems defensive, albeit packaged in an unsurprisingly edgy, yet HR-friendly tone.

    I always thought adding skills and abilities to your arsenal was a good thing. You seem to be advocating the idea that UX has nothing to do with the other components of building a product, and that your responsibility to the user should not be burdened with constraints that others on your team deal with, constraints that are just as real as those “human” ones UX designers like yourself seem deterministically obsessed with.

    To continue with your construed analogy, get off your UX high horse and put down the guns you have aimed at a shift and change in the design profession. What could possibly be so bad about understanding the language and techniques that directly influence the work you do? That’s almost as naive a viewpoint as a diplomat not learning the language, customs, and cultures of the country he works with because he feels (if we were to apply your logic to that profession) that “understanding anything but what we want out of this relationship is counter-productive to fostering greater, more productive relationship with those we work with.” That’s a dangerously narrow-minded viewpoint to employ.

    Ultimately, I think your intentions are good, but you’re speaking from a soapbox with your head in the sand. Outside the world of Startup Land where there is exhaustive amounts of capital (and egos) to push around, designers strive to grasp and understand the other roles that influence their work because it’s a good thing. You make zero arguments as to how this could actually be a detriment and turn to reinforcing the fence around your position and role in the design process. Maybe you’re just threatened by the fact that UX design is actually a part of everyone’s job. UX is really just a fancy, startup buzz-word for thoughtfully considering the people who use and enjoy your product, an age-old idea that many people across all kinds of professions have employed to be better creators and providers. The tech world didn’t invent this idea. Rather, they’ve “branded” it and elevated the idea to astronomically pretentious heights.

    Humble yourself a bit, thumb through one of those “Dummies” guides on your smartphone you have such disdain for — one explaining whatever languages your team works with — and understand the problems they have to deal with too. You’re team will thank you (and probably like you more). At the very least, learn how to mockup that PSD of yours on the front-end. To me, as a designer, not knowing HTML, CSS, and enough JS to implement jQuery functions shows an unwillingness to grow and expand the bounds of your profession. To utilize the analogy other commenters have pointed to, even architects mockup their blueprints (albeit on a miniature scale).

    …and I won’t even go as far into your argument that learning more about the management structure is somehow a better and more valuable idea than learning to “code.” I will say though that the higher you make it up the corporate ladder with the views you have will only further sequester and alienate your role in the design process, something I imagine you’d prefer.

    • Wayne Greenwood says:

      Is it your position that user experience & design professionals should not learn business strategy or aspire to leadership positions in product companies?

      • pratalife says:

        Umm.. when I read the post it was pretty blatantly obvious the answer to you question is clearly “no”.

        But at the same time as learning skills “up” the ladder, the OP was questioning why learning skills “down” the ladder has become so disdained.

        • Wayne Greenwood says:

          Designers who enjoy writing code should absolutely learn Java, Objective C, or whatever language their chosen platform requires.
          On the other hand, designers who want to influence product strategy will not benefit much beyond learning the basics of coding. What they need most is an understanding of how the business works.
          Still other designers will want to focus solely on UX, leaving both the coding and product strategy to others. This is also a perfectly valid choice.
          Ultimately, a designer needs to decide which course they want their career to take—the sooner the better.

  17. JasonB says:

    You lost me at your “reasoning” for bad UI/UX in the 80’s and 90’s. This really reads like someone who hasn’t been around development for more than 5 years.

    You clearly do not understand how software evolved, was built, developed, or designed. If you had any knowledge of the evolution of the command line/shell, the implication of the memory usage of a GUI, even the simple algorithms needed for fluid layouts, you’d understand why UI’s looked the way they did. You’d also understand why today’s UX designer would have been laughed out of the room. We have better interactions now because we can afford to. We’ve built machines that can handle the extra work a nice UI creates.

    Alleging developers don’t know how to design UI’s because of the past is simply bad research.

    • Wayne Greenwood says:

      Actually, I was there, designing software in collaboration with clients who understood the value of design even if they weren’t equipped to do it themselves. VCRs did not blink 12:00 for years because of technical limitations or even cost considerations, they did so because that level of crap interaction was industry standard at the time. Even the most rudimentary interfaces—LCD segment displays, low-res e-ink displays, and even command line interfaces—have the potential for good design within their limitations.

  1. By Designers Shouldn't/Should Code - jpreardon.com on August 4, 2013 at 2:55 pm

    […] good articles: One holds that designers shouldn’t code, while the other argues that designers should learn some code. For the most part, the […]

  2. […] a recent blog post, designer Josh Seiden offered a rebuttal to a friend’s argument that designers shouldn’t code because being influenced by implementation needs would compromise their design. I definitely side […]

  3. […] Le débat “les designers devraient-ils savoir coder” reprend de plus belle avec trois articles tout neufs. […]

  4. […] #Code – Back to the non stopping “should designer code” debate with three articles on this […]

  5. By Bølgeskvulp uke 32 | Making Waves Blogg on August 9, 2013 at 1:50 am

    […] Mer om «designeren som enhjørning« i denne bloggposten fra Joshua Seiden. Eller hvorfor ikke være en pegasus? […]

Have a Comment?

Some HTML is OK