So I’ve been called a “UX Unicorn” a time or two, and depending on your definition of UX unicorn, I think I can be considered one.
There are a lot of web articles about UX unicorns. But none of them fully resonate with me. So I thought I’d share my perspective on being a UX unicorn and what my experience have been.
The direct meaning and connotations of a UX unicorn can mostly be extracted from the term itself. Let’s break down the term UX unicorn.
The “unicorn” is the easiest part of the term to understand. Unicorns are a mythical creatures that have a unique combination of magical powers that enable them to do what no other creature can do. For this reason they are highly sought after, and are thought not to exist by those who haven’t found them.
It’s the “UX” part of the “UX unicorn” that’s the vague part. UX involves usability research, human-centered design, information architecture, and a bewildering array of skills and activities, including prototyping, site-mapping, empathy mapping, visual design ,branding, frontend development, and content strategy. It’s rare enough that all these skills could be found in a single UX department, no matter how large. But finding an individual who has all these skills is almost as unlikely as finding a unicorn. Almost, but not quite.
The Web Design Days
I started web designing in 2000. During those days, the web industry was still quite immature, so making features work was the priority. Naturally, web designers felt the pressure of acquiring all kinds of skills in order to do their job and stay marketable in a constantly changing market. For this reason, the web designer was often unapologetically referred to as a Swiss Army knife: he or she needed to be creative, logical, technical, and really good with people. Many of the “how-to” books for web design stressed things like design principles on one page, then code chops on the very next page. This is when I was cutting my professional teeth.
Just to illustrate what it was like in those days, here’s a list of things I was doing in just the second year of my professional journey:
- Leading other frontend developers
- Site maps / flow diagrams (information architecture)
- Sales calls
- Running point in client meetings
- Leading visual design
- Print design
- Desktop application design "GUI Design"
- Flash animation
- Some Flash ActionScripting
- Coding a bit of ASP.net, XML, XSLT
After practicing web design for another 7 years, I accumulated a bunch of other skills as well:
- Content strategy
- Tradeshow exhibitions
- Book design (using InDesign)
- More ASP.net coding
- PHP coding
- Working with version control
- Flow diagramming
- Writing requirements
- Light project managing
- WordPress Development
- Narrated Flash demos
- Hybrid Flash websites
You may be looking at this list thinking, “Either he was winging it or he never slept.” The truth is that I rarely worked late nights and, for the most part, I accumulated most of these skills organically on an as-needed basis over the course of 10 years. For example, I learned how to produce graphics for a Tradeshow booth over the course of three months. Not long after that, I worked on a 150-page book for two months while simultaneously overseeing the development of a high-impact corporate website.
My time as a web designer tended to swing like an out of control pendulum back and forth between interactive design, frontend development, Flash animation, email marketing, project management, and web production. If you’d asked me then, I wouldn’t have said that I felt special, and I certainly didn’t consider myself a “unicorn.” I just felt like I needed to get better at more things, and I appreciated the changing seasons.
Something important I want to point out is that I never felt I was doing activities that were that totally separate. In my mind, I was always designing for a variety of purposes with a different set of tools. When I was creating Flash movies, I was designing. When I coded, I was always tweaking the design through code. When I created WordPress sites, I was imagining how the client would use the system. Somewhere deep in my mind, I knew all these activities were serving a single purpose.
Maybe that’s why I especially feel that my front-end coding experience helped me design better. That’s for several reasons:
- I clicked on a lot of things so I got to know more scenarios.
- Designing on the screen was the best way to design for the screen.
- Seeing how the database “broke” my design was very good “real-world” experience.
- I got a feel for why and when things are technically difficult.
- I was clear about the importance of rule-based design.
- I got the “big picture” on how information architecture works for many different types of websites.
- I internalized the fact that good coding practices were key for keeping design consistency.
Transitioning to UX
In 2011, I accepted my first true user experience position as “UX Lead” working with American Airlines. For the first time, I was working with 15 or more other UX leads. After adjusting to a new way of working, UX became my new professional path. I really enjoyed becoming hands-off and solution-oriented. Working at American Airlines helped me realize that I enjoy the process of discovering and crafting the best user experience. For the first time, I felt like I was finally given the time and resources to dive deeper into the design solution.
After a year of working as UX Lead, I was promoted to a more senior UX position: UX Global Strategist. In this capacity, I oversaw the UX for merchandising projects on AA.com. The base of skills and experience that I accumulated from my earlier years in web design were tremendously helpful, and were the main reason for my rapid promotion. These skills and experiences included:
- Experience with all kinds of scenarios on “big dog” websites
- Seeing how important it is to be a steward of the brand
- Developing an eye for detail
- Creating countless flow diagrams and site maps
- Creating hundreds of navigations
- Maintaining UI consistency (for me, this was more instinct than theory)
- Understanding business logic
- Being able to participate in all kinds of technical conversations and contribute rapidly to technical solutions
- A deep understanding of UX that came from years of working closely with customer support, understanding marketing, fixing bugs, and doing QA
- Designing interfaces I just need to make them low fidelity
Of course, I still needed to learn usability testing, low-fidelity wireframing, and how to step back from hands-on design and coding. But without doubt, the skills I gained in the past had a very positive—and very direct—benefit on my transitioning to a UX architect.
After two years at AA, I began to feel my HTML/CSS chops were getting rusty and my design sense wasn’t staying up with fashion. To stay fresh, I began taking on freelance projects here and there, but even then I felt I was falling behind. This didn’t have a direct impact on my job performance—I was in UX now—but still, it bothered me.
Picking Up Code and Design Again
Fast forward to 2014. It had been three since I’d done much coding or visual design. That’s when I began consulting work as a UX architect. I found being a jack of all trades can be quite beneficial in the world of consulting. With consulting, it’s beneficial to optimize the (project billing) utilization of each consultant. One way to do this is to broaden your skills. Every consultant faces time on the “bench” (the time you are not billable towards a client). What I found is that consulting is very helpful to generalists like me because I only need to wear one hat a time.
After rolling off a heavy-hitting year-long UX project at the end of my first year, I was asked if I wanted to help code an employee portal. I took the project and was pleased that I got caught up with many of the changes that transpired in the FED arena—responsive design techniques, SASS/Less technologies, using vector, etc. I then had the opportunity to take on a visual design project. After that, I did another UX project.
Today, by working in dedicated streams for definite periods of time, I stay focused and advance my learning in each discipline without being a “Johnny on the spot”—someone doing everything all the time. As a UX architect, I get to dive deep into the solution, conduct persona workshops, interview users, and conduct usability tests. As a FED, I’ve recently had the opportunity to work on immersive parallax, responsive websites with extensive SVG animated integration points. As a designer, I not long ago had a chance to create a style guide for Neiman Marcus. I don’t feel these are watered down experiences. This way of distinctly “switching hats” gives me the chance to keep going deep and to learn continually.
At this point, I still spend more than 70% of my time on UX projects. But I get to work as a FED and designer often enough so that I feel I could go out and get a job in each of these areas.
My Takeaways about Being a UX Unicorn
- Always have one discipline that you feel you are really good at. It doesn’t have to be the skill you are best at—just one you enjoy and feel you have a future in. Tell your manager that you want a given skill to be your focus but that you still want to work on other projects from time to time.
- Switching hats is rewarding. It’s rewarding to be a well-rounded person and it helps prevent burn out.
- Don’t be “Johnny on the spot.” Try to focus on one thing at a time, as much as possible. My years as a web designer and then my years as a consultant have been like different seasons with different and changing focuses. Try to avoid working on blue-sky, art-of-the-possible ideas while trying to squash bugs. Otherwise you won’t do either well.
- Don’t be pressured to be—or ashamed of being—a unicorn. We will always see job postings that make us go “You GOT to be kidding me.” Interestingly, the job postings with too many skills tend to be lower paying. Some people are born to be more specialized. Others of us are born to be more general. Just be who you are.
- Appreciate specialists and generalists. I’m so glad I have a family doctor for most of my needs, but I’m also really glad he sends me to a specialist when I need one. Bigger companies tend to need more specialists, but usually need generalists as well. Smaller companies tend to have a hard time keeping specialists fully utilized.
- Stay in your lane if you pick up another hat. For example, if you take up a design role for a project, respect the UX lead as the UX lead. Don’t change his or her interactions because you feel you know better. If you are the UX Lead don’t tell the FED how to do his or her job. If you aren’t responsible for a role, don’t be insistent on how the person who is should do their job—even if you feel they are junior to you. Of course, anyone on a project team should feel free to collaborate about anything, but there should always be an underlying respect for the role your teammate was given for a project.
- Remember: practical hands-on disciplines complement your UX abilities. Here are a few skills that get developed from visual design and/or coding, which every UXer can benefit from:
- Having a nose for what is in style
- Being keen on what is on-brand
- Being attentive to typography and readability
- Possessing an understanding of how UI interactions really work
- Understanding what maintainable code is
- Having a working knowledge of accessibility standards
- Developing a sense of proper margin and font size for all screen sizes
- Understanding vector graphics for wireframing
- Understanding Responsive web design tactics
- Developing an accurate sense of screen real estate
- Remember the Renaissance Era. Ignore the people who say “You can’t do that.” There’s always a need for both specialists and generalists. Don’t be afraid to be the latter. There are tremendous benefits to having expertise in a wide variety of subject areas. Just ask Leonardo da Vinci.