Stop telling designers to stop being designers
Every so often, I’ll see a fresh wave of articles pop up with questions like:
- Should designers code?
- Should designers learn product management?
Designers, we have been asking ourselves things like this for years. Of course, it’s a great idea for us to speak the language of our cross-functional partners. But why do we keep asking these same tired questions? And should we stop?
I have a theory. The root of this relentless interrogation is not How do we become better designers?
No. What we’re really asking ourselves is this:
How do we get taken seriously?
In other words, these persistent questions devalue our profession and our contributions. If your goal is to become a better designer, you need to ask a different question:
What makes us special?
What makes designers special?
We have unique skills and intelligences that we need to lean into.
1. Empathy.
Regardless of the person’s job title, I always know that I’m talking to a product manager at heart when I hear the term “customer pain points.” And this is a great place to start — but it’s not a substitute for human empathy.
Human beings are more than just “customers.” We all have ambitions, goals, and things we think about when we use a piece of software. This goes a lot deeper than “pain points.”
Designers help the team answer questions like:
- What are this person’s goals — not just in using this software, but in life?
- Why do they have these goals? In other words, what are their motivations?
- What behaviors do they engage in to achieve these goals?
Good designers go deeper than “customer pain points” (or even “jobs to be done!”) and help a tech organization keep the human being at the center of every business and technical conversation.
Everyone in a company should have empathy for the human beings we create software for, and bring that empathy into the product. However, for a designer this is a baseline job requirement. If the design team isn’t able to do this, we are actively bad at our jobs.
2. Vision
Empathy is a good starting point, but it isn’t enough. It is the unique role of the design team to turn empathy into action.
There are many roles that can describe and imagine what a product might look like. But designers have have the skills and proclivities to turn these ideas into tangible artifacts. These artifacts make the vision feel real and can rally the cross-functional team around the path ahead.
Visual design can be particularly important here, especially if you want to generate emotion in your audience. But high-fidelity mockups aren’t the only path to a shared vision. I’ve seen teams get excited around wireframes, hand-drawn storyboards, or even task flows.
As a designer, you have a broad toolbox of techniques. Use the right ones for the job at hand to communicate the future.
3. Connecting the dots
The most experienced designers see and create connections in everything. We think about software not as a collection of features, but as a way to allow humans to achieve goals.
Even if you are designing a small feature on an isolated screen, it is your job to answer existential questions like:
- How did I get here?
- What can I do here?
- Where do I go from here?
It’s the designer’s role to imagine and uncover these connection points, visualize them in the appropriate fidelity, and evangelize them as part of a complete narrative.
How do we let our lights shine?
We’ve identified some particular skills and approaches that make us unique. Here are a few ways to emphasize those strengths.
1. Do less in high-fidelity
Sometimes, you need a virtual stack of high-fidelity screens. Maybe you need them for a client presentation, or marketing materials.
But in the day-to-day, providing every screen, or every state in high-fidelity, is a massive waste of your time. It is a distraction that diminishes your capacity for strategic thinking. If you spend too much of your energy in the weeds pushing pixels, you’ll never be able to show off what design can bring to strategic conversations. What to do instead?
If you have a design system, use it.
If you don’t, create a few key screens and work directly with your engineering and product management friends to think through different states and edge cases. Then document those decisions, and add them to your emerging design system.
Recently, an engineering colleague introduced me to a technique called Example Mapping, a structured way of creating acceptance criteria and thinking through edge cases. Especially when design is in the room, Example Mapping is a wonderful, effective collaboration that works to create not only great features, but also great relationships. Try it out.
2. But get the details right
Doing everything in high-fidelity is a waste of time, but it’s still important to think through the details when they really matter. Prepare for your chats with engineering by thinking about details of interactions, such as:
- What happens if the API fails?
- What happens if the user enters letters into a number field?
- How does this typeahead form field work?
- What are the error messages, and when do they show up?
- What does the instructional copy look like?
3. Never forget the human
I recently led a team building a mobile app for a specific group of professionals. This app helped them connect and communicate with their clients; it was part of their day-to-day workflow. When I attended our annual user conference, I noticed something — every single one of our customers had increased the font size on their phones. Some of them had even increased the font size to the point where it broke the design!
What happened? It turns out that the median age of people in this particular profession is about 52. As people age, their vision changes, and many of our customers couldn’t see the app because of the default font size we’d chosen. Our design and product teams, comprising mostly people under 40, had not accounted for this.
Oops.
“Advocating for the user” is more than just building personas. Your job as a designer is to keep living, breathing human beings at the center of every decision you make.
The “product” problem
As a discipline, we have a nomenclature issue. We can’t figure out what to call ourselves; the multitude of titles within digital design is confusing even to us. And recently, there’s been a trend of companies favoring the title “Product Designer” over “UX Designer,” or simply “Designer.” Fundamentally, Product Design and UX Design are the same discipline (fight me!) but semantics matter here.
Imagine for a moment that we start referring to our Engineering colleagues as “Product Builders.” What comes to your mind?
Do you imagine someone who has a significant grasp of technical infrastructure and Engineering best practices? Someone who can architect entire systems and create new, innovative things? Or do you imagine someone who receives directions and builds to a spec that someone else creates?
I suspect it’s mostly the latter.
The same is true within the design discipline. If teams have Product Managers and Product Designers, we implicitly set up a hierarchy in which one person manages or owns the thing, and someone else “just” designs it. We might have a holistic understanding of our craft, but the “Product Designer” title can imply a narrow interpretation of our capabilities.
By hiring UX people as “Product Designers,” companies may fall into the trap of leaning too heavily on visual design. And while visual design is an important discipline, it is only the top layer in a multilayered approach to building useful things for humans. The “Product” aspect of the title makes it convenient to ignore tools like workflow design, mental models, user research, human psychology, and so on; it becomes easy to assume that the product manager will handle those tasks. Or more likely, that no one will.
If we’re all “product” people, no one is truly centering the human being using the product.
Ultimately, the title is less important than what we do with it. If there is a team who uses foundational UX concepts to design the product, call them what you like. But if the company uses the title to create an implicit hierarchy and an inappropriately heavy focus on visual design, that’s a problem.
This “product” approach fails to center what’s most valuable about our profession.
Wait, what’s wrong with being a product person?
Nothing. I love working with product managers. They juggle so many things: strategic planning, communicating business metrics, coordinating with many different stakeholders, all while keeping an engineering team running efficiently. They are wonderful, work really hard, and deserve so much respect and credit. I am in awe.
But.
Designers, is that what you really want to do? We aren’t product managers, though some designers can create product strategy and roadmaps. And similarly, we aren’t engineers, though some designers can code.
The more product or engineering work you do, the less you will allow your designer perspective to shine through. And you shouldn’t have to turn into a PM or engineer to be heard, share your unique perspective, and lead at the highest level.
We are enough
The best companies keep the needs of their users — human beings— at the center of their decision-making. As designers, our primary job responsibility is to ensure that real human needs make it into the product. In other words, good designers are crucial for a company’s success.
So here are those insidious questions again, with my answers:
Should designers code?
Who says we can’t?*
Should designers learn product management?
Who says we haven’t?
In other words, do those things if you want to, but don’t devalue your existing skills. You are enough, and you are needed as a designer. The unique perspective you bring to the table needs to be heard.
Use your unique voice, lean into your special skills, and watch your company—and our profession—succeed.
For a deeper dive on this topic, I highly recommend reading Christina Wodtke’s excellent piece Design’s Unsexy Middle Bits. (Or really anything she’s published.)
* Hat tip to the lovely Laura Klein and Kate Rutter, whom I’m quoting here. Go listen to their podcast What is Wrong with UX.
