What is this? In my spare time I mentor designers at the beginning of their interactive product design careers. This blog is a mix of the ideas and references that come up in these conversations. I encourage asking questions.
Previously I wrote about going into a feedback meeting knowing what you want to get out of it. This time, I’ll focus on walking through the work itself.
First: I strongly urge you to avoid the popular approach of presenting three designs. I personally try to only show a single direction, and many smart designers I know are going this route as well. It lets you focus more on one solution, and you avoid giving your team a “menu” where they pick their favorite aspects of each. That’s a form of compromise, even though the ideas are all yours.1
The key to pulling this off lies in how you frame it. Asserting a single design as “the solution” makes people antsy about potentially better, yet purely imaginary, alternatives. Here’s the gist of my spiel:
So, when I show this to you, I don’t want you to think of this as a proposal. This is a zero point on a graph, it’s a conversation piece that helps us know where to go from here. I want your feedback to be phrased relative to what you see. It could be totally wrong, or very close to right (though the odds are low), the important part is that this isn’t final.
This small shift in context actually gets you a lot:
First, it lets your team know that you don’t have an ego about this, which you shouldn’t. You get good, critical feedback with no politicking.
Second, the nervousness that comes with pulling the trigger disappears. You aren’t asking for a commitment, but you get the depth of feedback that comes with serious consideration.
Third, the feedback you get has a vector. “Less silly than this” is much easier to work with than “something that is silly but not too silly.”
So: you’ve made it clear what level of feedback fidelity you’re looking for, and you’ve calmed everyone’s nerves. Next remember that you’ve been thinking about this design every day, but the rest of your team probably hasn’t. It helps to review your inputs. By that I mean:
Your team (and especially clients) will appreciate this, even if they seem fresh in your mind. Not only does this help them get up to speed, but it also demonstrates that you listened and took their feedback to heart.
When you walk through the design, tell the story of how you got there. Tie each decision you made to the various inputs:
“You said you didn’t like how small the font was, so I bumped it up from 14pt to 18pt.”
You don’t have to be so literal. Often you’ll need to acknowledge feedback, then side-step it:
“You said you didn’t like how small the font was, so I opened up the whitespace around it to give it more prominence on the page.”
Or refute it entirely:
“You said you didn’t like how small the font was, so I tried increasing the size but it took too much attention away from the button, making it a net loss.”
This is passively participatory: your team gets to peek into your process, understand the logic behind the end result, and appreciate that you tried and tossed ideas along the way. By letting them see it from your perspective, your team will trust you made the right call.
This is just the beginning, of course. You still have to deal with that icky part: the feedback. How to untangle that mess in the next post. As always, I welcome questions & feedback: you can use the Ask page, or send me an email.
Yesterday I wrote:
Every startup needs designers but they’re nowhere to be found.
I’ve been getting feedback on this, specifically from designers who are looking for work at startups. To clarify, I was speaking from the perspective of the market, and it’s both the buyer and the seller that need to readjust their sights.
Startups need to understand that they can lower the floor on design recruitment, opting to foster talent rather than buy it. And designers, too, will benefit from learning how to flourish in a startup environment — a skill set that I’m not seeing taught well, and the foundation of this blog. Both topics interest me, and I may very well veer into the company perspective. I’m still figuring this all out as I go.
There’s also the additional problem of matching designers up with companies. It’s far from a solved problem, and I’d be curious to hear what people have tried, what works, and what doesn’t. So, if you’re a designer looking to get into a startup, please do write me. I aspire to be a direct resource for you. And if you’re a startup looking to figure out how to work with a designer in this model, I’d love to hear from you as well.
Reading: How to Run a Meeting — Rands →
Essential text on running meetings, which new designers rarely feel comfortable doing. In general, the archives of Rands In Repose are worth your time if you want to get better at the whole people thing.
On a recent mentoring call I talked about presenting design work to your team. This is far too dense a topic to cover in one post, so consider this the first of a series.
The first point I want to stress is one you hear about any type of meeting: you have to go into it knowing how you’re going to get out of it.
There’s no one type of design feedback session. When I was starting out I would just toss my work up on a screen and say, “What do you think?” But if your team doesn’t know what kind of feedback you’re asking for (which is to say, why they’re even at this meeting), they’ll just start giving their opinion about anything visible. It’s not uncommon for people to point out concerns with aspects that have already been approved, or are months old and not even part of the current project. One common pitfall is getting mountains of feedback on copy, even though you’re not the one who writes copy.
So what kind of feedback should you be asking for? Here are the most typical goals of design feedback meetings:
There are others, but the common thread is this:
How do I move past the deliverable I’m currently showing you so that I can get closer to shipping this project?
In my own head, I call this concept feedback fidelity. Ask only for feedback that gets you to the next jump in fidelity. Certainly consider any and all feedback that comes in, but don’t get bogged down in debates about a problem you won’t be solving until you’re in the next phase of fidelity: there are too many moving parts and if you haven’t been working at the fidelity of the problem, you probably aren’t working with a complete picture.
You should also feel comfortable pushing back on feedback that’s lower fidelity than the phase you’re in. The time for your team to submit those thoughts has passed, and only severe red-flag problems should be considered. It happens far too often that stakeholders don’t take any design feedback meetings seriously except the last one, catching critical issues with decisions that were approved weeks or months ago. But by focusing on fidelity, you also focus their attention, and limit the scope of what they need to be considering. That means there are no excuses for getting feedback in too late.
In practice you’ll probably find that politics can hinder a focused process like this, but if you’re running the meetings (which you ought to be, if you’re presenting) then you have the power to focus everyone’s attention on those aspects that get you closer to shipping.
I welcome questions & feedback: you can use the Ask page, or send me an email. Next I’ll discuss what to show, how to show it, what they’ll say, and what you’ll say back.
The big narrative going around right now is that design has been crowned king of the solar system. A Braun-esque super-future is in the works for 2012, and by Thanksgiving we’ll be downloading perfectly cuboid turkeys with rounded corners and all will be well.
But to get there, we need to solve a really big problem: the huge demand doesn’t actually seem to be creating supply. Every startup needs designers but they’re nowhere to be found.
I get a steady stream of startups contacting me, at first to recruit, and then to ask me if I know anyone looking. The answer is always the same: no and no. But over the last year I started to participate more in these conversations. I met with founders, asked them how their search had been, pointed them in some directions, and continued to track their progress. Many of them, to this day, still don’t have a single designer on their team.
Every experienced designer I know is either a founder, a lead, or working at a top tier company. No amount of cash could lure them away. Startups are having to pick between getting an experienced designer on contract or an inexperienced designer in-house.
So I started to recommend this: take a bright, motivated young designer full-time and pair them with a more experienced designer to advise and mentor with minimal time commitment. Conceptually this makes sense, but it was just a theory, and one that I’d never seen put into practice. Eventually I decided to put it to the test and pursue the model in the advisor role. I’m doing this with a few designers (that shall remain nameless) and so far it’s been very fruitful.
Well… it’s been fruitful for me, at least. Bringing my fuzzy, subconscious process into focus has given me a new sense of clarity about my work. Breaking & Mentoring is the public-facing component of those conversations, a mix of links, thoughts, and references. In many ways, this is the blog that I wish existed when I was starting out. I still have a long path in front of me, but if I can leave some footprints, Supply might have some help catching up with Demand.
