I recently had a long conversation about coffee with the manager at the flagship TRUTH.coffeecult retail store. Talking to people who have a passion for their craft — regardless of what that craft is — always invigorates me in my own work as well. One of the things Dominic told me is that since they’re a roaster that supplies coffee to other businesses, TRUTH’s retail coffee shops aren’t their most lucrative business opportunity. So why do they even bother with retail spaces? His answer really got me thinking:

We want to give people the tools they need to tell that our coffee is better than others.

TRUTH realizes that for most people, coffee is just coffee. Whether it’s Starbucks, Denny’s, or Ricoffy doesn’t really matter, as long as it has caffeine in it. But people like Dominic and the team at TRUTH aren’t ok with that. They see a city full of people who are losing out on the joys of an artisan coffee experience, and they want to change that.

But they also know that in order to accomplish their goal, they can’t just give people a cup of TRUTH and leave them to it. They have to teach them why it’s better. They have to explain the roasting process, show the care and precision that goes into pulling an espresso shot, and provide guidance on the flavours they need to look for. Only then will their customers be able to appreciate why TRUTH is better than other coffees.

This is not unlike the work we do in web design. When we work with clients or internal teams who are not aesthetically inclined, or don’t immediately see the value in prototyping and user research, we can’t just yell, “BUT OUR WAY IS BETTER!” and storm off in a fit of righteous anger. Instead, we have to give clients and teams the tools they need to tell that an iterative, research-led approach is better than just pumping out some PSDs real quick. We have to show case studies, and we have to explain how the investment will result in major returns for the business. We need to show passion for our craft, we need to speak confidently about what we do and why we do it, and we need to communicate the benefits to them in a clear and concise way.

Dominic went on to tell me how one person came into TRUTH earlier that day and asked to see how they make a cappuccino. The barista brought her around, showed her how the machine works, and she ended up pulling her own shot and steaming her own milk. The barista didn’t care about sharing secrets, or letting some “lesser being” touch his espresso machine. Because his goal isn’t to show people how good he is. His goal is to get people to love coffee. And if that means letting someone pull their own shot — imperfect as it may be — then so be it.

Our role as designers isn’t to show people how good we are, either. It also shouldn’t be our primary goal to win industry awards. Our goal should be to get the people we work with to fall in love with the design process, and to utilize that passion in them and ourselves to design great solutions. And the only way we’re going to be successful at that is if we invite our clients and teams to step behind the counter to see how and why we do what we do.

Des Traynor did a great interview with Ryan Singer, Product Manager at 37signals. I’m a huge fan of Ryan’s, and I agree with most of what he says in the interview. But there’s one part I’d like to challenge a bit.

Answering the question “Did you ever consider techniques like personas or user journeys, or any of those UX design methods?” Ryan says, “That stuff is all terrible”. He then obliterates the use of personas before going into a bit more detail a couple of questions later:

The things that get called User Experience come from the agency world. It really seems to be like that. Every time you meet people who are doing all of these UX methodologies they come from the consulting world. My background isn’t in the agency world; it’s in the product world. The whole game changes when you don’t have the pressure of delivering to a client on time, or trying to convince a client that you’re worth hiring or worth sticking with.

For example, if you’re working on products, and you’ve got a really capable team that can prototype things in real code, of course you don’t need wireframes, because you don’t need to get sign-off on something from a client.

This is where I disagree. I started my career in the product world. I worked at big companies, startups, and now an agency. I’ve used (and have observed others using) these “terrible” UX methods very successfully. Ryan is extremely lucky to work at a company like 37signals where personas, user journeys, and wireframes are not needed. But that is evidence of how great the 37signals culture is, not that certain UX methods are useless. I think Josh Brewer said it best:

Re: design processes—Everything depends on the context and the needs of the project. There are no absolutes. You do what needs to be done.

— Josh Brewer (@jbrewer) February 22, 2013

To get a bit more specific, here are just a few scenarios and contexts where using personas, user journeys, and even wireframing (which was pronounced dead again this week) can be really useful:

• At large organizations, not everyone is focused on and has an understanding of what experience design is about. There’s often a lot of “I am the user” thinking going on, and an inability to see interactions from the perspective of users. In those circumstances, personas and user journeys in particular can be enormously beneficial to help the organization see their products from a user’s perspective. Personas aren’t prescriptive, they’re descriptive. You can’t identify a persona and then try to predict people’s behavior off it. But you can use personas to help focus development efforts on users, and help define what features are included in (and just as importantly, excluded from) the product.
• At startups as well as large organizations, we’ve used user journeys effectively to guide the organization away from systems thinking that’s focused on internal structures and technologies, to user process thinking that results in the design a of much better experience. Once again, when you’re dealing with people who come from non-UX backgrounds, making this shift can be tougher than it seems.
• At agencies, we like to help companies wherever we can. To do this, we say that user experience and user-centred design scales well. Therefore, running a task-based usability test in a controlled lab environment will get the best results, but if there isn’t budget, guerilla testing is better than nothing. Similarly, sketching interfaces and then building a clickable prototype for iteration is absolutely the preferred way to go. But lacking budget, flat wireframes for quick iteration is better than doing no iteration at all. We can’t be so idealistic that we’re not willing to scale down our processes when we need to.

So, just to reiterate my point. 37signals appears to be an organization that is in lock-step agreement about their vision and goals. This means that they can build prototypes in code, iterate on that together, and they might not need reminders about their user personas and journeys. That is a fantastic place for a company to be in.

But to call UX methods “terrible” ignores the fact that most of us work in organizations where building good experiences is only 50% design challenge. The other 50% is organizational challenge to get all stakeholders pulling in the right direction. And in the right context, UX methods can be extremely helpful to address both types of challenges.

Further reading:

• Love, Hate, and Empathy: Why We Still Need Personas - UX Magazine
• One Size Fits None - Happy Cog

Here’s some great advice from Joshua Porter: when you’re in a design meeting (or any other meeting, for that matter), Always be capturing:

“Always be capturing” is about the habit of continuously recording the value from your conversation. For example: If you’re talking about a new concept, you should be sketching it as you talk so your team has a shared understanding and an artifact of the conversation.

Joshua gives some great tips, including taking photos of your sketches and uploading them to Dropbox immediately. We do this as well, except instead of Dropbox, we add the photos directly to a Trello card related to the project at hand (using the iOS/Android app). Those photos are then immediately accessible to everyone who works on the project:

We’re increasingly using Trello not just to schedule our work, but also to make our thoughts and sketches immediately available to the team within the context of the task at hand. That’s something Dropbox can’t do.

In my latest article for Smashing Magazine I discuss How To Sell Your UX Design Solution To Clients:

How do you convince clients to trust you with their valuable and much-loved product? In my experience, the best way to sell work to clients is to apply user-centered design not only to the work we produce, but also to the clients who commission that work.

We have to understand who our clients are, what is important to them and what their goals are. And then we have to deliver work that not only meets the needs of end users, but also satisfies the personalities within the company itself.

I go through three different “client personas”, and how we adjust our process slightly for each. If you’re in the business of doing client work, I hope you’ll find the article useful.

Rus Yusupov talks about the design process at Vine in Design at Vine: Everyone needs an editor. I love these kinds of posts because I always learn something — either confirmation that we’re not the only ones doing things a certain way, or that we’re doing something wrong and need to change.

One of Vine’s key design principles got me thinking about the “invisible design” debate again:

Strive for simplicity. An interface should get out of the way. People should be able to focus on being creative, not on how to use the app. In many ways, interface design is like film editing: if you notice it, it wasn’t done well.

This idea has been a common refrain over the years, especially since Dieter Rams formalized his 10 principles of good design and said that “Good design is as little design as possible.” Except that somewhere along the line, we started to believe that “as little design as possible” means “getting out of the way”. It doesn’t.

Rams didn’t say that good design disappears completely. “As little design as possible” is not about making things invisible, it’s about “not burdening products with non-essentials”. It’s about making the right choices about what should be there, and what shouldn’t. There is nothing wrong with making the things that are in the product visible, sometimes very much so. Let’s not forget that one of Rams’s other principles is that “Good design is aesthetic”:

The aesthetic quality of a product is integral to its usefulness because products we use every day affect our person and our well-being.

I would add that making the right interface elements appropriately visible is essential for a visual hierarchy that effectively guides users through an interface.

Nevertheless, at some point the design community collectively arrived at this conclusion that good design is invisible — or even better, not even there. And I think that’s a dangerous line of thought. In the case of Vine, they used this principle well to ensure simplicity in the app. But there is still a very strong visual identity in the app.

We need to remember not to conflate what should be two different arguments. “How it works” should be invisible, but “How it looks” certainly doesn’t have to be. I think Dieter Rams would agree with that.

I’ve written about this topic before in So, is good design invisible, or not?

Arriving at a company as a new (or sometimes, the first) Product Manager can be daunting. Product Management is usually introduced in an organization once there is a such a high level of internal enthusiasm and chaos that the leaders aren’t sure how to handle it any more. And then everyone looks to the Product Manager — you — to “manage stuff”.

It’s easy to get overwhelmed by how much there is to do when you step into a stressful role like Product Management. So here are some recommendations on how to spend your first 3 months at a new company.

First 30 days: Understand the product, the market, and the company culture

The goal of the Product Manager is “to deliver measurable business results through product solutions that meet both market needs and company goals”. With that in mind, spend the first 30 days learning and understanding:

• The product. What does the company sell? What does the product do? How does it work? What is the value proposition? What problems does it solve for customers? What features does it have? What kind of bugs does it have? What are the main usability issues?
• The market. Who currently uses the product? What are they like? What are their characteristics? What do they like and not like about the product? Who is the target market? Are there personas for each different type of person in the target market? What are macro and micro market needs addressed by the product? Who are the competitors?
• The current product/market fit. Are you in a good market with a product that can satisfy the market? What are the gaps that you need to close between what the product does, and what the market needs, to ensure a better fit?
• The company culture. Talk to as many people as possible in the organization — from marketing to finance to design to engineering — to understand how things work. What do people like about the product development process? What do they hate? Do designers feel like they have enough time to do their work? Do developers have what they need to program effectively?
• Ensure the PM role is properly understood. For a Product Manager to be effective, the organization needs to understand that PMs should have autonomy over the products they manage. Executive buy-in is a prerequisite for success, so make sure that it’s well understood that even though everyone gets a voice, not everyone gets to decide. As Seth Godin once said, “Nothing is what happens when everyone has to agree.”

Next 30 days: Develop a strategic product plan

Based on what you learn in the first 30 days, start the product planning phase:

• Run a Product Discovery workshop to start identifying user needs, business needs, and technical needs, and to create a problem frame diagram.
• Develop personas and user journeys, and start brainstorming ideas for product development with the team.
• Work with the team to prioritise ideas and start building a roadmap for development. Consider methods like the KJ-technique or the Kano model as a way to formalize prioritization efforts.
• Identify success measures — define how you’ll know if what you’re doing is having the desired impact. The 3 A’s (Acquisition, Activation, Activity) are always a good start.
• Put the appropriate processes in place to ensure effective product development lifecycles. This means knowing what kind of requirements and specifications developers need to start working, how research and design fits into the process, where marketing becomes involved, how QA should work, etc. You can only do this once you understand the current culture, and what the strategic plan will be going forward.

All of the above goes into a document called the strategic product plan. Among other things, this plan includes statements about the product’s value proposition, who the market is (customer profiles), how you plan to achieve product/market fit (the business opportunity, pricing, distribution), what the priorities are, a first stab at the roadmap, and proposed success measures.

Next 30 days: Start executing on the strategic product plan

Now that the plan and the initial roadmap are in place, start the product execution phase:

• Start with a reasonably small requirement with clear and easily measurable success metrics. Work with the team to get it done right.
• Measure, and show the success of the process. Use this to build trust and continue to ship improvements (and even better products).
• Assess the situation, and use customer and business feedback to adjust priorities (and the roadmap) as needed. Flexibility is key.
• Keep going. Repeat any of the initial steps as needed.
• Have fun while you’re doing all of this.

The life of a Product Manager has an exhausting, exhilarating rhythm that is beyond the scope of this article. But spending your first 3 months systematically moving from product planning to product execution will not only give you a solid foundation from which to improve the product, but also ensure that you hit the ground running by shipping the right improvements as early as possible.

I posted an earlier version of this article as an answer on Quora.

In The Post-PSD Era: A problem of expectations Dan Mall continues a Photoshop discussion started by Brad Frost a few days ago. Dan’s conclusion is worth pondering:

As an industry, we sell websites like paintings. Instead, we should be selling beautiful and easy access to content, agnostic of device, screen size, or context. If you can get your client to believe in the sales process that you’ll do that for them, they won’t care what the site looks like.

I agree with Dan’s viewpoint on what we should sell to clients, but not that they won’t care what it looks like. They always care. A little earlier in the post Dan says this:

I don’t think we’re in a post-PSD era, but I do think we’re moving towards a post-“full-comp” era.

Now that I agree with completely. At Flow our deliverables to clients have increasingly moved away from a PSD for every page on the site, to a combination of clickable prototypes, style tiles, and PSDs for key pages. Developers and Product Managers love this because they can play around with the prototype to see how the site/app works, not just what it looks like. Other decision-makers love the style tiles in particular, because it allows them to guide what the site looks like without getting distracted by the intricacies of the interaction design (which requires a different type of discussion/feedback cycle).

In other words: we should sell clients on our design process, agree upfront on what deliverables will help them accomplish their goals, and make the appropriate amount of PSDs part of those deliverables as needed.

Julie Zhuo discusses some characteristics of bad designers in 7 Reasons to No-Hire a Product Designer (Part I). This point stood out for me:

Look for hints of random decision making. Good designers do not do things randomly, or for the hell of it, or just because it seemed cool.

This ties in well with Rebekah Cox’s definition of Design in her Web2.0 Expo Presentation:

Design is a set of decisions about a product. It’s not an interface or an aesthetic, it’s not a brand or a color. Design is the actual decisions.

The thing is, if you don’t follow a rigorous design process that identifies user needs, explores different solutions, iterates collaboratively, etc., you’re still making decisions about the product. You’re still designing. But your sins of omission will result in implicit, subconscious decisions that have a high likelihood of being wrong. This is why what Julie calls intentionality in her post is so important. Design decisions should always be deliberate and defendable, not random and accidental.

Peter Matthaei wrote down some thoughts on failure, startups, and product development in ALL THE USE CASES. He makes some good points, like this one:

Every great company started by being great at solving just a single problem. Quite often, a very humble one. But they solved that one problem incredibly well, picked up momentum, and with large doses of relentless ambition, good timing, vision and luck kept on going.

Dropbox is, of course, the poster child for this line of thinking. One of my favorite Quora answers is still Michael Wolfe’s response to Why is Dropbox more popular than other programs with similar functionality?:

“But,” you may ask, “so much more you could do! What about task management, calendaring, customized dashboards, virtual white boarding. More than just folders and files!”

No, shut up. People don’t use that crap. They just want a folder. A folder that syncs.

I would add that I think the problem with most startups is not necessarily that they’re trying to solve too many problems; it’s that they’re trying to provide solutions to problems that don’t exist. I love this quote from Pragmatic Marketing in their post Who Needs Product Management?:

It is vastly easier to identify market problems and solve them with technology than it is to find buyers for your existing technology.

My thesis continues to be that the single biggest cause of startup failure is focusing on finding buyers for cool technology, as opposed to identifying (and fully understanding) market problems first.

In his introduction to a very interesting user research case study on the MailChimp blog, Gregg Bernstein writes:

Here at MailChimp, we’re realists—as much as we love email and all the things you can do with it, we understand that building a campaign is a task, not a life event. You want to get in, get done, and get on with things. Duly noted.

The post goes on to explain how they managed to shave an average of 32 seconds off a core email campaign creation task at MailChimp. But it’s that opening sentence I’d like to dwell on for a bit.

I wish more companies understood this crucial point. As designers and product managers we obsess over every detail of our product, but it most likely makes up a minuscule part of our users’ days. Unless you work for Facebook or Twitter users don’t wake up wondering what new features you’ve released, how your conversion rate has changed over time, or what awards you’ve won. They care about getting a task done, and they care about nothing getting in their way — they care about getting on with their lives.

Yesterday The Onion published an article that is such a spot-on commentary on how we’re mostly ignoring this reality. From Internet Users Demand Less Interactivity:

Tired of being bombarded with constant requests to share content on social media, bestow ratings, leave comments, and generally “join in on the discussion,” the nation’s Internet users demanded substantially less interactivity this week.

Speaking with reporters, web users expressed a near unanimous desire to visit a website and simply look at it, for once, without having every aspect of the user interface tailored to a set of demographic information culled from their previous browsing history.

Exactly. We’re in an environment where too often products and functionality are shaped by who we are and what’s technically possible, not by what user needs call for. XKCD called us on it years ago, but we’re just not listening:

The solution to this problem is to get out into the world and understand how our products and services fit into the lives of our users. How we can help them accomplish their tasks more effectively. Mark Hurst summed this up well in his post What is a career in user experience really about?:

Good user research isn’t a matter of learning the steps of some trendy methods, as though one were just following a cookbook. Instead, good UX work requires a genuine interest in observing, listening to, and learning from other people: primarily the customers themselves, but also the organization that owns the product. That observation, and that listening, must stem from a genuine human interest in people.

We can all do with a shot of humility about our products. We might think what we’re making is a gift to humankind that deserves proper respect — and we absolutely should be proud of our work. But a bit of human empathy will show us that most users have only a passing fly-by relationship with our products. That’s ok though. Understanding how our products fit into people’s lives realistically will help us to improve that fit and (hopefully) become indispensable to them. That’s our job as User Experience Designers.