The job of a Product Designer is creating true product-market fit through constant innovation, iteration, and learning. They should have smart processes that allow for creativity and breakthroughs, speed and efficiency, deep brand alignment, user-focused thinking, and a good bit of fun.
Design is a fundamentally creative task: It takes time and space. It takes a certain kind of nourishment and focus. Yet at the same time, design is production: The first major potential bottleneck in a lengthy string of steps that lead to shipping a product. Mediating this dual quality of design is perhaps the most fundamental challenge in building great design processes.
You need to create an environment of openness, flexibility, and collaboration in order to allow for truly inspired design. Simultaneously, you need the rigorous time-lined flows that get shit out the door on time. It's possible to strike this balance, but it's not easy. The deep task here is to build processes that help designers internalize this give-and-take through a philosophy of constant, steady, smart iteration.
What designers make is what everyone else is stuck with, for better or worse. Developers can change things in the building process to some extent, but most decisions are made in design.
This means that designers need to be thinking big—thinking about what it will take for the engineers to build this feature, thinking about how other future features will interact with this feature, thinking about how these styles will hold up over time, and thinking about how their work will be applied across many platforms.
Designers need to be thinking—more than almost anyone else in the company—about resources and the long-term. This is seldom understood, and the results can be extremely problematic. Often designers aren’t trained to do this. Processes should be built to help designers do this thinking systematically, as part of their creative-productive flow.
If you look at the design quality of the apps that are being built now—consumer and enterprise—compared to even two years ago, you see a massive shift.
And it's not just that it's becoming easier to design slick interfaces, or that good design patterns are becoming more widely understood, or even that design tools and resources are improving (although these things are all true). What I suspect is that we are entering a period of artisanal goods and craftsmanship, which manifests in our increasing appreciation of and demand for beautiful software.
The point is: Design matters, so you better get it right.
A bit of background on our design team in particular: @howaboutwe has an extremely flat design team, embracing neither the UX/visual divide (I don't like hiring visual designers who aren't UX thinkers) nor the product/marketing divide (we have one brand and I believe every interaction with it is key, whether it’s a mobile app or a banner ad).
This means that every designer is expected to be able and happy to take any job from research to wireframes to visuals to pixel-perfect delivery. Some people are better at certain things than others, and we honor that—we’re not dumb or dogmatic—but in general the load is carried equally, and that makes everyone better. The work benefits, and our members benefit.
Okay, that said by way of preface, here's a practical overview of the nuts and bolts of the @howaboutwe design process:
Every Monday morning the design and product teams meets to estimate and assign the work for the coming week.
We discuss all stories for the week. Occasionally new stories will sneak in during the week (usually based on my executive call) but the general rule is: If you don't get it to us by Thursday so we can prep it for Friday's meeting, it ain't happening next week.
“Get it to us” means submitting stories to either our Director of Product Management (for product jobs) or to our Creative Director (for marketing jobs). (For a longer discussion of “stories” see my piece on engineering flow.) These two directors ensure that each job is thoroughly spec’d and that the stories for the week are prioritized. We use Pivotal Tracker for this, which, when it comes to design flow, is a bit like using a bow and arrow to pick a lock—but whatever. Each director checks their plan with me, as Head of Product—my other role besides co-CEO—and with the Head of Product Design, and we informally ensure that the quantity of work for the week is about right.
In the Sprint Planning Meeting, we start by checking in on long-standing projects. Then we go through all smaller design jobs for the week. For marketing jobs, our Creative Director attends to talk about that work. For product jobs, a Product Manager or I discuss what’s involved. We talk about each job briefly, decide who will do it—usually just based on designer preference—and then estimate how long it will take. For estimation we use a point system that basically correlates to predicted hours of work. The meeting takes under an hour.
Then everyone dives in. If you’ve conducted all the previous steps in this process carefully, each member of the team will know exactly what they need to get done over the course of the week, and they will each understand how it fits into the big picture.
When a designer is working on a new, complex project, we have a Work Start Meeting. This is a meeting where the designer gets from our Product and Data folks any relevant information including analytics about past performance of similar features or marketing materials, possibly research that has been pre-compiled, product thinking or specs for the feature, and engineering requirements/restraints as appropriate.
These meetings tend to be relatively informal, except for very large-scale projects. But they are essential.
Each project is different, but for most significant projects in which styles have not yet been defined, a tricky product problem is being solved, or something brand new is being built, designers move through six phases:
- Visual options
- User testing and more refinement
This is an explicit list, so I won’t belabor the explanation except to say there are reviews at each stage. It is the designer’s job to know how to move effectively through these steps.
The @howaboutwe Head of Design does small reviews throughout the day with designers when they want help or think their work is ready for formal review.
From 2-3 p.m. each day, the VP of Product and I do a formal review. Any designer who has work ready can participate. They present their work (their thinking, their opinions, options, and so on) and we give on-the-fly feedback. Sometimes I will ask the designer to deliver image files to me so I can review the work over more time or with other stakeholders—then I’ll follow up either via email or in person. Marketing also engages in a similar review cycle. These daily design reviews are essential for keeping everyone on the same page and on-track.
We often bring developers into these reviews. We solve problems collaboratively, talk through styles, review options, make decisions, make sacrifices, and decide the next move.
Designers are responsible for never delivering any designs that a developer will later say were—from an engineering perspective—ill-conceived. They need to check with developers as they go to make sure what they are designing is going to really work, including in evil swamps like Internet Explorer. It took me years to get this even close to right. It’s hard. But it’s essential. Designers should feel like they are responsible for delivering great products to users—and this means making sure that what they are designing can be efficiently built.
When developers say something “looks good” and “is possible but will be hard to build,” it’s the job of the designer to bring this situation to the product team for discussion. Some things are worth the time, others aren’t. There are no rules for such decisions, just a group of people talking and making choices.
Our user testing processes—when we’re on our game, which candidly isn’t all the time—consist of the following:
- We watch users engage with any significant new feature we release through usertesting.com. It’s pretty cool and often revealing.
- Build the equivalent of an Apple Keynote presentation allowing you click-through designs. There are a bunch of programs for this—hit us up on Twitter @howaboutwe if you want recommendations, as what’s best depends a bit on your circumstances. Show designs to users around the office before delivery to the engineers, so you can refine based on user feedback. You can even use other employees as “users” for this.
- Focus groups are something we do occasionally, too. We ask questions to a group and listen.
- Regular, in-person user testing sessions are also helpful. We have people come into the office and engage in pre-defined tasks. Usually these tasks are related to new features or hard problems we’ve been thinking about. The sessions are run by anyone who wants to participate—designers, engineers, marketing team members—and whomever runs the session takes notes and shares them.
- Email-based user surveys help us understand how people are experiencing our products.
In some cases this person could also be responsible for maintaining the HTML/CSS style guide and icon font, building sprites, or other miscellany that will aid in the dev process. This can be done by engineers as part of the regular development lifecycle, but I find that that’s often not the most efficient solution, particularly if your site doesn’t have extremely strong CSS.
Using data as a part of the feedback process can be tricky. Here’s why:
Let’s say Jane Doe designs a new feature. It goes live three weeks later. We have statistically significant data about it two more weeks later. It’s been, say, seven weeks since she got the original assignment. It would be ideal if she had a smart data feedback loop, and ideally it would be quite granular: How exactly are people using what you built? Which means the feature needs to be built with fairly advanced analytics built into it...which is harder than it should be. So...good luck on this one!
You should totally aspire to do this well. We’re okay at it. We have good company-wide goals metrics. We’re good at reporting on AB tests and general platform performance. But the hyper-detailed feedback on very specific design implementations is hard. If you know how to really do this, please let me know at email@example.com.
The design team has full team retrospectives every two weeks. I discussed Engineering Retros in detail in an earlier post. Design Retros are the same, except they involve designers.
That’s basically it for design processes. Ironically it seems pretty simple now that I’ve put it on paper—but, woah did it take a while to get it even close to right.
The most important point here is that your design processes should be awesome. Design is the soul of your product, and the soul—though completely free at the root—benefits hugely from structure and process. It’s actually the structured processes that set you free to design beautiful, functional, inspiring products. Free to make things that transform people’s lives and make everyone cooler and happier.
You are reading Unblocked: A Guide To Making Things People Love, a series in seven parts.
Part 2: Value-Driven Product Development: Using Value Propositions To Build A Rigorous Product Roadmap
[Image: Flickr user Evan Blaser]