Design process and how designers communicate their design decisions to others is kind of a obsession of mine. I’ve been lucky enough to have been involved in just about every aspect of digital product design and I’ve seen the process from the eyes of a product manager, a designer, a coder, a creative director, etc.
All of this thinking has led me to the following conclusion, which I think still holds true:
Communicating design, in general, needs to be less about documentation and more about clear, concise and ongoing two-way communication.
In other words: spend your time designing, not documenting. I don’t know about you, but contrary to what I sometimes hear from designers, I’m not in the business of making flow charts, personas and wireframes. In the end, these things literally do not matter. Even in the best cases they usually cost valuable time and energy. Worse, can be a source of miscommunication or used as an excuse for when a product’s experience fails. I’ve seen a few great ideas die a premature death due to an inability to gain consensus on documentation. It’s ridiculous.
Very often designers spend way to much time producing ineffective—yet often impressive—deliverables and not enough making sure the decisions within those deliverables are handled appropriately throughout the process.
There is no doubt that an essential part of the design process is communicating (not necessarily documenting) design decisions. But it’s those ideas and decisions—and their impact on the end product—that matter, not the documents themselves.
In most cases:
if you’re doing high-level design (goals definition, roadmaps, feature definition, content planning, flows, etc.) you should be spending your time doing research, thinking/problem-solving and then, as briefly and clearly as possible, communicating the outcome of that thinking.
if you’re doing detail-level design (visual design, UI, interaction) you should be working on the details and assets that go into the final product. If you have the ability, you should be producing (or working with an engineer directly to produce) fully functional prototypes or, often better, working on the final product itself. I’m a big fan of the “design in your medium” method.
if you’re producing mid-level design documents—like wireframes and personas—do them with extreme care. Remember, these are means to an end, treat them as such and you’ll have fewer problems. There are a few cases where they work, for example, coming up with the tone (for copy and visuals) of an app or site.
I realize (trust me) that the above isn’t always doable. Usually it comes down to the makeup of your team. You might have UX folks who aren’t strong with look and feel, or a designer who doesn’t code much. And that can work out just fine, again, if they’re good communicators. I’m not going to touch the specialist vs. generalist argument, except to say that everyone on a product team should strive to have a solid understanding of what their teammates do.
Designers should, at the very least, be able to communicate effectively with engineers and vice versa. And if you’ve got people who’s skills span many parts of the stack, that’s awesome. Even if they don’t actually do all that work. For example I can code, but usually there is someone around who’s better at it than I am. It’s good for me have that ability, and to be able to speak to it, while at the same time letting my co-workers do what they do best.
(A quick side note: I’ve noticed that large teams are very often slower. More resources doesn’t usually equal speedier, or even better, product development. The issue this post is trying to tackle is more process related, but I think many of these issues could be solved by simply making teams smaller and more focused.)
Communication
A designer’s ability to communicate: listen, answer questions, etc. is probably their number one asset. Keeping a clear and open line of communication between you, your teammates and your stakeholders can make all the difference.
All of this takes trust in those you work with as well as a willingness to let others in. You may feel like you’re giving up control, and it some ways you are, but through that sharing you will often actually have more control over the final outcome. You know, the thing that’s important.
I feel pretty strongly that designers should be willing to share and accept feedback throughout the process. I believe that great design requires a solid, singular vision but acknowledge that allowing more people into the process can be a good thing if it’s done right. It’s not about building consensus, it’s more about sharing and taking advantage of the full talents of your team. You can have a strong vision and still be open to new ideas and feedback. In fact, this is a big part of what makes a good designer great.
I love the idea of boiling the design process down to really quick rounds of design/build where designers and engineers work closely together and iterate often. Make no mistake, this is difficult and requires understanding on all sides as well as a remarkable ability to communicate.
Having said all of this, I think that at the end of the day, a designer should be flexible and able to adjust to whatever process works for the rest of his/her team. Ideally though, I’d prefer to spend most of my time working on my final product and less on the details of my design deliverables. These things can be useful and sometimes necessary, but, in my opinion, the focus should always be on that final product.
And, trust me, while you're busy documenting your ideas, your competition is out there iterating on a product with real data. The quicker you can get a product out the door, even an imperfect one, the better. I think most would agree on that, so why do designers still waste time with this stuff?
*Note: This is a revision of a post I wrote a couple years back, I'd started writing something new and realized that I was echoing some thoughts I'd previously jotted down
I sort of like where you're going with this Jack, but, it's not going to work. Like it or not, we're stuck with the word users to describe people who use our products.
You make a fairly good case; suggesting going with “customers” instead. But, the problem there is that not all users are customers and, well, that makes things confusing. I often co-mingle the two, refer to people as user/customer, etc. It's harder to keep straight than you might think. And I'm one of the lucky ones where all my customers ARE users.
But that's not the real problem. The real problem is you've put the focus in the wrong spot: on a word and now that's all you've got people talking about. The focus should be on your users, not whatever word you choose to use to call them.
Look, I've tried this. I used to run a small consultancy in Seattle, Blue Flavor (holy shit, the old site its still there, crazy) and we did our best to present ourselves as a “peoplecentric” design company. Our branding was thick with it. “We speak people!” was our motto. We tried to refer to users as “people” whenever we could. But our customers (the people we were paid by, not the people who used our work; see how it gets messy quick?) were confused by it, and that became a problem.
It turned what should have been a conversation about people into a conversation about a word.
Which is exactly what that little memo did. So, yeah, nice work, Jack. :)
ps - Jack, if you're reading this, some advice. You should never listen to Howard Schultz. That guy's a liar and a jerk. Just ask any Zombie Sonics fan.
Good post from Braden Kowitz. Lots of sense in there and it's a short read. I really liked this bit:
It’s tempting to think that you can outsource product design: hire someone who goes away, does some design work, and returns with a magical solution. But because product design is so complex, it can’t be outsourced and solved in isolation. Great design requires the knowledge and experience of everyone on the team.
This applies to ANY design effort, IMHO. It doesn't mean you can't bring in folks to help you out—clearly, given who's writing this—but it needs to be a true team effort.
One thing I'll never get, though, is calling out visual design.
Often when people think about design, they think about the surface visual design. But early in a startup, visual design is probably the least of your worries.
Is that really true? Is there so much confusion about what design is that we can't just roll visual design in as a part of the basics of what you need to get a product going? I don't dispute his point, I'm just not sure why it still needs to be made. Then again, I guess he would know. :)
Just read this post by Francisco Dao that echoes closely some of my thinking on the recent trend of celebrating failure. He makes a solid point:
Even worse, many entrepreneurs now celebrate their failures as if they were an indicator of their skill. This is as ridiculous as a race car driver saying his numerous crashes are what make him a good driver.
Amen. As someone who's gone through a few pretty major failures—in just about all aspects of my life—I've never really understood the “celebration” many entrepreneurs associate with failure.
I have learned a lot from failure (the biggest lessons are around not making the same mistakes) but I can't say failure is the primary learning tool in my life, and, frankly, it's got some horrible downsides, especially when you're aiming high.
Failure sucks. It hurts. It can lay a person low. It can cause wide-reaching problems and, despite the learning and strengthening that can come from it, it's not always worth it. I finally came to accept my failures and, oh yeah, I learned from them. But you'll never catch me celebrating them. I'd prefer to leave as much of the actual failure part of those experiences behind me. And for good reason.
I don't think it's something we should embrace and more importantly, I don't think it's something we should be putting on our resumes and holding up as some kind of badge of honor. It's part of a process that, ultimately, should lead us to successes? You know? The things we should be celebrating.
For me, I'd like to put failure in the same place I put boredom, anger, sadness, etc: In the past. Not forgotten, but in a dark place reflected upon only when necessary. I don't know, maybe that's just me. What really gets me here is the embracing or seeking of failure. I don't get that at all. Embrace risk, sure, but seek success. Right?
Failure is a part of life, and if you think risk is a good thing (I think it is) you're probably familiar with it. Is failure an awesome learning experience? Hell yes it is, but so is success. Is it worth the risk? Most of the time, yes, it is. Should we celebrate it? Hell no.
Learn from failure, don't go seeking it out. And for crying out loud, don't brag about it.
“You came here because we do this better than you, and part of that is letting our creatives be unproductive until they are.” - Don Draper
There is some subtle truth about how we all work in that statement. It's not all about creatives (hate that word) being productive, it's about creating an environment for people—anyone really—to succeed by doing their best work.
At the core of this environment lies a culture built on trust, empowerment and ownership, but, beyond that there are the nuts and bolts of how, where and when people work.
We all work differently; different things recharge our batteries, get us excited and drive us forward. Some of us need other people around us; some need alone time. Some need silence; others rockin' tunes. Some need routine and some great variety. Many, like me, prefer different things at different times and for different kinds of work.
Working smart is all about figuring out how best to structure your world so you can do your best, while at the same time letting others do the same. It's about working with intention and eliminating arbitrary or unnecessary barriers and rules. It's also about working to grow a culture of trust and empowerment, resulting in better work and happier workers.
Many companies (and probably more importantly, many workers) are figuring this out. Look at the developments around Results Only (or Oriented) Work Environments ROWEs. A company like Gap or Best Buy puts lot of thought and reasoning into the decision to go to with ROWE. But let's boil it down to this: it works.
According to that article, something like 44% of American workers feel overworked. I think the feel part of that is important. Hours put in doesn't translate to a feeling of being overworked. I know many people who work long hours (or, more often, many hours in a week, spread out) who don't feel overworked at all. They feel engaged and energized, passionate and purposeful. Sometimes to do a job well takes time, and that's cool, but that time needs balance; I don't care how much you love your work, if you neglect other things and you'll likely burnout eventually. You can't thrive without balance, it's simply not sustainable.
Some of the most productive and inventive people I know have put themselves in situations where they can work however, whenever and wherever they want. I firmly believe this is the best way to work and if companies want the best people doing awesome work, they need to figure out how to embrace that flexibility.
Why would you limit your ability to work to a single place or timeframe? Why limit your ability to create to a cube, or a desk? That just doesn't seem smart.
Having said all of that, this flexibility needs to be build on a framework—like ROWE—that everyone understands; it needs a structured environment spelling out clearly what's expected.
It also needs to be inclusive for as many work styles as possible. That means taking care of those people who absolutely thrive on the energy their co-workers bring, and who need that energy to do their best work.
There is real value in face time, and getting people together to bounce around things in the same room or via a Google hangout, etc is an awesome way to work. I like going into the office, and I love and find great value working directly with my teammates, customers and colleagues. As well, spending time with co-workers, both those on my team and others in the office is key to building the relationships that are very important to a great company culture.
Which begs the question: how can we work flexibly and smart—leveraging the full opportunity time and space offers us—while at the same time get that buzz and energy you get having your team all in the same room? How can we build and maintain relationships when everyone is on their own time and in their own spaces? Can technology help? Do we simply need to pair a lot of freedom with a little bit of structure?
I'm thinking the focus should be flexibility of structure, but I've a few ideas on how this could work:
Designated teamwork days. Many companies have the concept of a flex day. What about flipping that around and having a day or two each week where you're expected to be available to the rest of your team.
Break into smaller teams and self-organize schedules. Instead of adopting a company-wide policy, let teams/groups negotiate their own way of working. Let them also hold each other accountable to keep things moving and not become blockers, etc.
Make meetings optional. Seriously. If you throw a meeting, make it something I'm going to want to attend, but won't keep things from moving when I don't. Bonus points: don't call it a meeting. I think meetings are one of the biggest problems with modern work. They are non-essential to getting things done and often the primary cause for slowing things down. Let people work and touch-base with their co-workers on an as-needed basis.
On-the-fly office hours. Meaning, you let people define their own times (and places) when they can meet face-to-face. No set schedule.
Redefine “face-to-face” with technology. I've had some great brainstorming/working sessions with remote members via Google Hangouts or Skype. It's not ideal but it works.
If you really want butts in seats, make your office space a place people want to come to and spend time in.
So, anyway, I don't have a solid answer, but I'm always looking for new ways to work smarter and flexibility with time and place is essential for people to do their best work.
What do you think? Do you have ideas on how we can effectively have more freedom in how we work? What do you think of mine? I've started a Branch to discuss.
Jeremy Bell over at Teehan+Lax has written one of the best posts I've ever read on the sometimes controversial subject of designers who (should) code.
It's thoughtful, with many compelling arguments, and, more importantly, it doesn't throw designers under the bus. Rather, he describes a sensible path towards bringing them up to speed, while at the same time letting them work in a way that takes advantage of their valuable skills.
The new Myspace is creating a lot of buzz and getting some serious kudos for its design. And, yes, it sure does look pretty slick in that demo video. It's all very sexy and Metro and full if of nice interaction touches and transitions. I got a little excited. Nice work JT.
The direction seems smart too; if there was one place Myspace held, and still holds to some degree, it was entertainment. Myspace, despite a horrible experience, is the place many artists go to connect with fans.
Sure, Facebook has made some strides there, and there are some interesting publishing tools out there like BandPage and Onesheet, but Myspace still lingers and dominates Google search results.
So, yeah, it's interesting and sexy. And a great experience might be just the thing to breath life into it. As well, from a visual design standpoint alone I think it can be applauded, even if it's not actually all that new. Windows 8?
So, yeah, it's worth talking about—Hell, I give 50 bucks to app.net and I find this more compelling—but, please, people, lets actually use it before we start calling it a design and user experience success. And, designers, whatever you do, don't start copying this stuff yet. I'm excited about some of what I saw too, but I'd advise caution. And lots of testing.
I mean, hell, that seemingly infinite horizontal scroll might wreck the whole damn thing. :)
Recently I've heard some talk questioning or knocking the value of UX (User Experience) and design for startups.
This bullshit is derived, as usual, from how is UX typically defined.
Most people think of UX in the wrong way. They associate it with an expensive, time-consuming Process and fuzzy deliverables that don't actually add a ton of real value to a product. As well, when it's associated with a job function, I think many people picture an expensive consultant or specialist that runs this time-consuming Process and produces these fuzzy deliverables that don't actually add much real value to the product.
So, based on that definition of UX, startups definitely wouldn't have a use for it. I'll take it a step further. Hardly anyone needs that. Big, small, startup, established…it doesn't matter.
Instead of saying startups don't need UX, let's change the way we look at UX.
I think UX needs to be defined closer to the context to the actual words used: the overall experience a user has with a product. Based on that definition, we're talking about an experience that incorporates many things that fall across many different job functions.
In essence, if you're building a product for use, everyone involved is a UX person.
What these companies need is a way to discover, define and refine their products from a customer/user perspective. They need leadership that understands—and people who practice—user-centered design and who aren't afraid to get themselves and their product in front of customers. They need people who can work directly on the product. This is key for early stage startups, for a number of reasons (design debt is as big a problem as technical debt, for instance), but I think this carries on to larger, established companies as well. If your UX people aren't involved directly with the product in some way, you should ask yourself, “Why not?”
I do think it's good to have someone who “owns” UX, and as you grow, someone who's focused on bringing it all together. What you don't want is a “specialist” that defines their work by the deliverables they produce. It's not about deliverables or process, it's about thinking about your products in a way that helps you define value from a user's perspective and taking that thinking directly into improving the product.
In my post about what I do as a product designer, I mention a bunch of things I do on a daily basis. In thinking about that, I realized something that I try to do often to help “get me going” on things.
Often, when I'm not sure where to start, or have a mountain of daunting tasks piling up, I begin by asking someone else if they need help with anything.
To me it's probably the single best motivational/productivity tip I can think of. Sure it's slightly counter intuitive, as you're potentially taking on work, but the rewards are mighty. I find that after I spend some time helping someone else get started (or finished) I'm refreshed and ready to get going on my own stuff.
It seems like there are many ideas as to what a product designer (and/or product manager as I feel there can/should be a lot of overlap) is and does. There are a lot of articles out there describing these jobs and what goes into them. And don't get me started on the job descriptions; they're often confusing as hell. I do get where some of the confusion lies, but when I think about it on a day-to-day basis and look back at my career it doesn't all that complicated.
So, I was thinking, maybe it'd be interesting to sit down and detail what it is I do as a product designer. I've been doing product design for years and while my role has changed a bit over time, I thought I'd have a pretty good handle on the day-to-day.
Half-Elf Fighter/Cleric/Magic-user 10/8/8
Turns out it was harder than I'd expected it'd be. So here's the deal: while I'm no unicorn, it turns out my work covers a pretty wide range of disciplines and job functions. My guess is that this is the same for many other product designers. I was able to pin it down, kind of, but it took a little while.
Anyway, after a week or so of analyzing and recording my daily work, and going over previous jobs and projects, I came up with the following; all percentages rough and rounded for easy reading:
30% Design. In my mind there is a ton of overlap here, so I've got no problems calling all of this design, but since this is usually a sticking point I've tried to break it down further:
30% Interaction (UX, flow, states, etc.),
25% Conceptual (research, sketching, ideation, etc.),
25% Interface (UI, IA, layout),
20% Visual
20% User research. Interviews, testing, scheduling interviews, follow-ups, talking with our support folks, etc.
20% Other stuff. Design reviews, prototyping, coding, asset building, etc.
(It should be noted that I'm not including “admin” time. We're I to do that meetings, mentoring, management, HR/IT stuff and email would take a hefty chunk away, so I'm taking those off the table.)
But, wait. You said product DESIGNER.
It might be interesting to some that so much of my time is spent doing things other than “design”, but it's necessary to do them for my design work to be successful. I often say my job is part designer, part productivity guru, part lawyer and part investigator. And there is some truth to that.
As well, there are many modifying factors (size and make up of your team, where the product is in its lifecycle, etc.) that can change this up day-to-day. Overall and over time though, it's probably pretty representative of what I do.
Also, I consider myself—first and formost—a designer. So there.
Roll a saving throw vs. scope creep. You'll need a 20.
I also thought about the skills I use on a daily basis. For the most part, the skills that are most important to my work are soft skills: communication (writing specifically), listening, learning, time-management, being easy to work with, etc.
As far as the hard skills, I think there is a wide range of skills you could employ to be successful. Some product designers are focused on design, others on tech and coding with many falling somewhere in the middle. My advice to people get into product design is to be “t-shaped”: skilled in a few areas, knowledgeable in many.
One thing you must have is an ability to learn, adapt and see the bigger picture. For example, you don't have to be the best visual designer, but you can't ignore visual design as an important part of your product. Same could be said for code, or infrastructure, or marketing. You need to engage on many levels with many subjects.
A product designer acts as a bridge of sorts. We connect customers to products and experiences. Management to engineering. Design to code. Business requirements to user needs. A great product designer will sit in the middle and be somewhat invisible, it matters less to which side you actually lean. If I'm doing a good job, for example, no one will notice I'm there. It's essential to be able to get comfortable, on some level, with a lot of different kinds of work. This is a challenge at times, but can also be very rewarding if you look at it right.
So, what do you think? Are you a product designer? Maybe a product manager with a different background? How does your daily work break out? It's a harder question to answer than you might think. Head on over to Branch and let's talk about it.
