Five rants from a cranky designer
After two decades in design, I’d like to believe I’ve earned the right to rant (respectfully and, I hope, constructively) about our profession. But long, tedious rants are boring…so here are five short ones.
1. Don’t Mistake the Mockup for the Product
As designers, we care about attention to detail in our deliverables. The extra time ensuring dimensions are correct, icons line up along pixels, text lacks typos, and so on is well spent — up to a point. But it gets out of hand when we start to mistake the mock for the product.
Nobody uses your mockups. Let me say that again, because it’s important and I want Medium users to highlight it: Nobody uses your mockups. Your work isn’t done when you hand it off, and the extra effort you spend getting it from great to perfect is not worthwhile. (And if every pixel has to be perfect in order to achieve the right in-product result, focus on your relationship with developers rather than your deliverable.)
A mockup is a description of a plan. If you never execute the plan, the mockup didn’t serve its purpose. If you can execute the plan without doing a mockup, then by all means save yourself the time. Your success is defined by no more, and no less, than your impact on the product itself.
2. Enough with the Design Systems, Already
It feels like design systems occupy 80% of design discourse these days. I keep seeing posts like, “How to Keep Your Design System Current,” “How to Create Your Own Design System,” and “Design System Pulls Puppy From Burning Building.” There are more Sketch files and GitHub repos than you can shake a stick at. And meta-sites for posting, browsing, and downloading design systems. I came across an article the other day asking whether we even need designers now that we have design systems.
And design systems are great! They’re a valuable tool for ensuring consistency and reuse. But design is problem-solving: unearthing user problems and finding elegant solutions. A design system helps us solve problems without reinventing the wheel or creating chaos. But a design system, on its own, cannot solve user problems; and you can solve user problems — that is, do design — without a design system. Which means that even faced with an unsystematic, chaotic product, a design system may not be the right priority.
Look, I get the appeal. It’s fun to simplify complexity, create taxonomies, streamline processes, generate order out of chaos. And it’s productive to talk about and evolve our tools. But can we please spend a little more time on the whole problem-solving thing?
3. Stop Asking Users What They Want
Here’s what you’ll learn if you ask a user what she wants: She wants the thing she has now, but a little bit better.
And what does she think of your design? She wants it to be more like the thing she has now.
There, I saved you a user study. You’re welcome.
I know, I’m being extreme. You can learn all sorts of things by asking those questions: How have existing solutions shaped expectations? What feels especially foreign or unfamiliar? Where are mental models out of alignment? How might you onboard a user and ease the transition? What steps can you take on the sales and marketing side to overcome the hesitation?
Qualitative research is hard because it requires so much interpretation. Researchers have to filter what they’re hearing to compensate for low fidelity, self-reporting bias, and the simple fact that users haven’t spent time analyzing their own fundamental needs. These challenges are nothing new; but with the increased use of design thinking outside design, we don’t always recognize them. There’s a sense, within and outside design, that we can validate an innovative idea by putting sketches in front of people and asking what they think.
That’s not wrong, exactly. But it’s only right to the extent we bring to bear sufficient understanding of what questions to ask, how to ask them, how to interpret the answers, and — most importantly — which answers we just can’t get (or trust). Otherwise we produce incrementalism, or just bad signal.
4. There’s a Reason They Call it “Work”
Most of us expect something more from our work than a paycheck. We look for fulfillment, growth, maybe an impact on the world.
But our employers are businesses with revenue goals, stakeholders, and responsibilities. Organizations hire people to help achieve those goals — not just to give them growth opportunities. Only one type of organization exists for that second purpose: a school. And you don’t get paid to go to school.
If you’re thinking, “Dave, I don’t get this rant. You’re describing the basic tenets of the employer-employee relationship; of course you have to work in service of employer goals,” then you haven’t been in an organization where people refuse to work on tasks that don’t excite them. You’ve not had the pleasure of asking someone to do something and then, a week later, hearing, “Oh…yeah…I decided not to do that.” You’ve never asked about a timeline and been met with confusion or hostility, simply for asking the question.
If instead you’re thinking, “But what about servant leadership? Shouldn’t leaders enable employees to be their best selves?” You’re absolutely right. Great managers are servant leaders: They understand the strengths, goals, and needs of their teams and work to enable and unblock them — in service of company goals. It’s a two-way street: leaders synthesize goals and work with employees to translate them into projects. Employees take projects and run with them. In exchange, leaders help employees grow in the course of tackling those projects, and ensure their voices are heard in determining the goals in the first place.
But not every project is fun, not every goal will be the one you wanted, and not every moment is a growth opportunity. That’s not a philosophy; it’s just the cost of doing business. And no employee is an island: effective teamwork means overhead, coordination, and sacrifice. I think some of us have forgotten these things.
5. Stop Isolating Yourself
Designers like to talk about “having a seat at the table.” We don’t seem to have any other phrases for this concept, so we say “seat at the table” a lot. And semantic monotony aside, we’ve made real progress in recent years. I was comfortable taking a design role this year (rather than product management) because I had confidence I’d be a real partner in driving product strategy.
But we endanger our stools at the bar (OK, it’s not so easy to come up with an alternative) by isolating ourselves. We create closed “design studios” where we can hide from stakeholders and do designey things. We run multi-day “design sprints” where we explore Big Ideas, freed from the constraints of our day-to-day product roadmap and requirements (and unlikely to affect them). Or we insist we can’t compromise on a pixel of our visions for the sake of the timeline.
When we do these things we reinforce our reputation as divas, as sensitive ideologues who need to be treated with care. We risk excluding ourselves from the conversations where the tough decisions are made, because we seem out of step and unwilling to sacrifice. We force others to make design trade-offs because we won’t do it ourselves. We ask to sit at the table, then refuse to eat our vegetables.
Design is for everyone. The best products emerge from highly collaborative teams, on which designers are shepherds of design rather than gatekeepers. Where engineers, PMs, marketers, and others are empowered to participate, and educated with an understanding of design so everyone can be a part of creating a usable, delightful product.
So get out of your studios and do your critiques in the open. Ensure your ideations are aligned with the roadmap, then bring your stakeholders along. Work with your engineers — and understand the medium they work in — to find acceptable compromises. Stop isolating yourself.
These rants aren’t new for me. But they’re top-of-mind as I build a design team, culture, and process from scratch at Heap. I want to ensure I learn from my past experiences — the things that have worked, the things that haven’t, and the hypotheses I’ve built along the way. And I’d love to hear other perspectives. If you have thoughts, drop me a line; and if you’d really like to help…well, I’m hiring.
