How to solve a designer’s biggest fear with startups: wearing multiple hats
Startups offer tons of value to designers if you know how to handle the extra work
In this economy, mid-size startups (50–350 people) are the best environments for Junior Designers to accelerate their career growth.
After making the switch half a decade ago, I’ve experienced tremendous career growth and helped mentor Junior Designers to do the same. However, one fear that often comes up when considering working for a startup is the need to wear multiple hats.
I understand that fear perfectly: I left a ‘safe’ design job working for the government to join a startup in my 30s with a wife, two kids, and a mortgage.
I was afraid I wouldn’t get to see my family because I would be working nights and weekends wearing multiple hats, and suddenly getting fired from my first startup didn’t exactly help either.
However, now that I’ve made it out to the other side (and still wear multiple hats), I can say that it’s not as bad as I feared. Over the past couple of months, you might have seen the multiple hats reflected in my writing, which included:
UX Writing
Strategy
Analytics
User Research
Data Visualization
Design systems
and more
There’s one piece of advice to keep in mind with this extra work: you’re wearing the Design/User Research hats as your job and other hats to solve a problem.
Here’s a guide to surviving while wearing multiple hats.
Being flexible as a designer is a competitive advantage
Here’s the harsh truth about startup life: sometimes, the organization is lean enough that you being ‘only’ a designer is thought of as a negative. I’m pretty sure that was the reason I was fired from my first startup: they loved my design work but felt like they weren’t getting enough value for my paycheck.
It’s not just the startup world, either. Product Design is overtaking UX, and part of it is that it’s hard to justify ‘pure UX’ in a weak economy. Only doing UX may not be enough for the market anymore.
However, it’s also unclear where designers should dip their toes. While some of us might know how to code, that’s not always the most straightforward transition for many of us.
Instead, there are four hats that tend to be easy for us to slip on:
User Research (& Analytics)
Content (Writing/Data Visualization)
Product/Business Strategy
Documentation
Designers undoubtedly have experience working with (or creating) some of these things. In addition, they’re things that aren’t too much of a stretch to learn.
While I won’t delve into each of these categories that much (as I have in other articles), I will say that understanding that you need to switch between multiple roles can be intimidating, but t shouldn’t be.
Here’s how I’ve approached each new hat that I’ve taken on.
You probably won’t be asked to take on a role, but you should
Here’s the weird thing about Designers: we’re usually not asked to take on an additional role.
In my time at startups, I’ve observed Engineers being asked to figure out QA/Backend/FrontEnd duties. I’ve observed Product Managers becoming Product Owners or Business Analysts, but Designers are usually left out of the loop until much later.
I believe a lot of this is due to the perception around Designer’s ‘expected’ purpose: we’re meant to create mockups, prototypes, and user tests. As a result, many team members might not think to invite Designers, as “we’re not ready to visualize anything just yet.”
However, we have another essential pair of skills that people often need to remember: sketching and the user perspective. Often, teams discuss ideas and projects while having a vague sense of what everyone is talking about, only to be surprised by the first round of designs.
Likewise, the first time you hear about a set of requirements, you might be shocked to hear about how the user’s perspective has been ignored up until now.
These skills are part of our toolbox, but they’re not the first things other team members think about when planning a meeting. So it’s often the case that we can contribute a much-needed perspective to the team, but we need to bug the organization to invite us.
In many other environments, designers may not have enough impact due to a hierarchy of job titles. However, there’s often so much work that needs to be done at startups that any help is appreciated. As a result, you can (and should) take on additional roles to help out and gain valuable career experience.
Just keep one thing in mind: you’re wearing a hat to solve a problem.
Wearing a hat means solving a problem instead of understanding a field
I’ve worn the “Strategy” hat at organizations but wouldn’t claim to be a UX strategist.
After all, I’m uncertain about some aspects of my startup’s Strategy, such as SWOT Analysis, Five-forces analysis, and several other terms. As a result, I couldn’t get a job as a UX strategist, and I’m not aiming to. All it means is that I understand Product Strategy from a UX perspective.
Wearing a hat often involves understanding just enough about a field to solve a well-defined problem. So one of the critical skills to learn for wearing multiple hats is problem framing. This is where you learn to ask enough of the right questions to define the problem and what you intend to do.
In the strategy example, I know the Unique Selling Point of my product, how to design for value, and who our main competitors are. These things dabble into Strategy, but they’re mainly things I know to solve one particular problem: how do I need to design to motivate users to take specific actions (like scheduling a demo or buying a $25,000 product)?
You’ll find that most hats you wear (except User research) will be at this level.
For example, here’s a list of the most valuable things that I’ve learned from each of the four hats I’ve highlighted above:
Lessons learned wearing the Research hat:
Learning how to define user testing in a way that your Product team can understand (i.e., it’s not just random UX testing, it’s essential)
Understanding the basics of analytics and surveys (i.e., Ensuring you don’t user test for questions you already have the answers to)
Learning to prioritize user research questions (i.e., If all you have is 5 minutes with a user, what’s your most important question?)
Learning to squeeze in research when you have an opportunity
Learning to present your findings in a way that drives action for your team
Lessons learned wearing the Content hat:
Writing better microcopy, titles, and headers
Understanding computer-based editing tools (Grammarly, ProWritingAid, HemingwayApp)
Learning when to use the three types of visual content: Illustrations, photographs, and diagrams
Learning where to source images, icons, and more to pair with content
Lessons learned wearing the Strategy hat:
Learning about pricing models (i.e., How the business will charge users)
Understanding user motivation and psychology behind large purchases
Documentation:
Understanding the difference between Engineering and Design documentation
Learning how to research other design systems for gaps in knowledge
Understanding what type of documentation is required and what is optional
Looking over this list, you might find that many of the actions I’ve discussed are just extensions of the design (or research) process to accommodate a new requirement. That’s on purpose: you don’t have to reinvent the wheel when trying to wear a new hat. The purpose is often to learn enough to inform the team or guide decisions.
Only user research is slightly different. You have more expertise in the field, so you must guide others on its importance and show how to integrate it (and why) into the process.
However, one more aspect to wearing multiple hats that is essential for designers to remember.
Wearing multiple hats is about prioritization and time management
I’ve mentioned before, but Designers have a terrible reputation around time management, and it’s one of the most important things to consider when wearing multiple hats.
After all, each hat, in itself, is enough to be a full-time job. When you’re wearing multiple hats, you might have many unexpected time constraints and must learn how to prioritize.
I talked about this before, but the critical aspect is breaking things down into smaller tasks and learning to prioritize each task to get things done.
However, there’s one other thing you should keep in mind: the hierarchy of prioritization is usually straightforward when involving other hats:
Design work (i.e., your job responsibilities)
Design-related work (i.e., Work that you do with other hats related to design)
“Other hat work”
Simply put, ensure that the job responsibilities and duties the organization pays you for come first, then expand things from there.
Startup life can be stressful but rewarding
After making the jump nearly half a decade ago, I don’t think I could return to my old job. The responsibilities, skillset, and teams I work for now have accelerated my career growth (and experience) beyond the years I worked.
I’ve also dabbled in wearing several hats, which has been a fun and exciting learning experience. In my case, I’ve found that the mid-size startup (50–300 people) is my ideal design environment: I have experienced a ton of growth with less volatility (and the need to pull all-nighters) compared with a 10-person startup.
However, it’s also comforting to know that the entire product’s success does not rely on me and my limited understanding of an entirely different field. So if you have been interested in making the jump to the startup world, but have been fearful about wearing multiple hats, don’t be.
The requirement to wear multiple hats isn’t always as scary as you might think.
Kai Wong is a Senior Product Designer, Data-Informed Design Author, and Top Design Writer on Medium. His new free book, The Resilient UX Professional, provides real-world advice to get your first UX job and advance your UX career.