Design, With a Lowercase D

Design is a troublesome term. Does it refer to the artifacts and specifications upon which a thing is built? Is the title given to the “creative” person in an organization whose job it is to produce such artifacts and specs? Or does design represent a process of discovery, exploration, and solving?

What follows is aimed at engineers, business leaders, and designers alike. Don’t think it’s a criticism of you. (Also, don’t assume it isn’t.) But please do keep in mind that it is aimed primarily at myself, as a reflection on a topic that has been much on my mind, lately.

Let’s start by clearing the air

First, stop thinking that anyone in your organization “owns” design. Now, simultaneously, disabuse yourself of any notion that you are not personally responsible for shaping the product or service that your organization exists to provide. Regardless of your title, you are a designer.

Within the context of design — and I’m not speaking of “Design with a capital D” here, but rather the broader, more inclusive activity of identifying problems and documenting solutions — within the context of design, titles seem to me to cause as much conflict as they do clarity. At the time of this writing, I have the pleasure of working with a variety of talented individuals who excel at outputting great design artifacts. I also have the displeasure of having to navigate a sea of vague titles: Product Designer, Product Manager, Program Manager, Front-end or Back-end Engineer, Software Architect.

I, myself, hold the oft-misinterpreted moniker: “User Experience Architect.” When it was adopted in my organization, it was meant to convey an elevation of the role from the more narrowly-focused “Interaction Designer.” It was meant to reflect the broader, more strategically-focused nature of what I actually do, particularly the role’s focus on usability, user advocacy, and information architecture (among other things). Unfortunately, it is often misunderstood merely as a lofty variant of its “UI Designer” cousin.

Sidebar: When titles fail to convey role definition, or when the relationships between titles is unclear, the titles might as well not exist. Instead of establishing responsibility, they may be used as a means of excusing one’s self of responsibility. Instead of conveying expectations, they may only convey condescension or ambiguity. When titles are clear, mutually understood reflections of roles and responsibilities, great. Otherwise, they may be little more than the hats our egos wear to make them seem capable and worthy.

But I digress.

This isn’t an article about titles

It’s a reflection on design. It’s about you being a partner in design, and an owner in the result, no matter your title. To that end, here are a few maxims or principles that, while not necessarily from an authoritative source, I’d like to hope are self-evident. Or at least compelling.

When engaging in design activity, check your title at the door. This isn’t an advocation of design by committee, but rather encouragement that we get the right people involved in design and ensure the outcome isn’t just the reflection of the most “important” person in the room. Every participant has a role to play, so make sure that much is clear. There may be a facilitator, or even a decision-maker. There may be someone who’s more specialized in color or typography, others who bring illustration or motion to the table. Some may be subject-matter experts, usability gurus, or engineers. Hopefully, you’ve got a user research maven in your midsts, or at least the findings from their latest study. If you are going to keep your titles draped over your shoulders, at least make sure you know what yours means, that it’s equally clear to your peers, and that everyone is able to look each other firmly in the eye.

When engaging in design activity, have a clear goal. Have a shared sense of purpose to ensure you and your peers are collaborating, not conflicting or contradicting. If your goal isn’t concrete, do what you need to do to sharpen your focus before you start spouting ideas or taking any caps off any whiteboard markers. “Make it better” isn’t a goal; spend time identifying an actual problem or need, first. Then, spend more time making sure you’ve identified the right problem or need. Frame the problem or need as an opportunity. Now you have a goal. (You may want to make sure your goal is achievable, at some point.) Revisit your shared goal constantly throughout the design activity. I’m sure somebody has said this before me, but a designer without a goal is either an artist or a hobbyist.

When engaging in design activity, know who you are designing for. The term “user” is a good shorthand, but don’t forget that your users are actual people, and that they are probably not anything like you. Establish what you know about these people, and recognize what you don’t know. Do your research: go and observe the user in its natural habitat, if at all possible. If you don’t know what the needs, behaviors, and contexts are of the people who will use your solution, then you aren’t designing for them at all. Instead, you’re designing for yourself or the boss down the hall.

When engaging in design activity, always explore as many options as you can in the time you have. Find ways to alternate between divergent and convergent thinking. Alternate between working as a group and working individually. When considering who to invite to participate in design, err on the side of being more inclusive and more diverse. Abhor homogeny among your peers. A person who knows more than you about the technical implementation details, or about typography, or about the business goals, etc., has invaluable perspective that he or she can bring to the table. Give your peers a voice: an opportunity to not only express ideas but also help craft the solution. Time-box every phase of your design activity, and be strict about respecting the time constraints you set.

When engaging in design activity, always validate your solutions with the people who will use them. Whether it’s just a kernel of an idea, or a set of line drawings on paper, or a functional prototype, put it in front of your “users” and watch what they do. Where do they struggle? What are they thinking (have them think aloud)? What would they change? Shopping an idea around the office is great. We should all eat our own dog food, no matter how raw. But also keep in mind that dogfooding only tells you when a potential solution wouldn’t even work for the people who sit next to its creators. Unless you put your solution in front of a representative sample of the people who might actually use it, you don’t know whether what you’ve designed is spot on or just a spot. Validate early, validate often. Oh yeah, and make sure the person performing the validation research is capable of hearing unbiased feedback. If its your solution that being validated, that person probably isn’t you. And no matter what you think about the feedback you receive, resist the urge to think the person giving you the feedback is stupid or “doesn’t get it.” If they struggle or fail, look for the faults in the solution you designed, not in your test participants.