A blog about interface and product design. Delivered daily.
PRODUCT DESIGN NEWS
If you’re a product designer this is one of the most important topics you have to deal with. Braden Kowitz of Google Ventures Design, in his recent post Why you should move that button 3px to the left:
“Designers notice the gap between functional and delightful, and that’s why we obsess over the little details. But there’s a very real tradeoff between perfecting the design details and building more functionality: getting the details right often means moving slower…So it’s not enough to say “it looks better this way”. Designers need to make a case for why the team should spend time on fit and finish.
I think that Braden is right here. The difference between people who do something because they can vs. those who focus on it professionally is the details. So, developers who create UI almost never have the attention to detail that a UI designer does. Similarly, a UI designer who writes code doesn’t have the attention to detail about coding practices that a developer does. It works both ways. In many ways the problem is that people can do someone else’s job, passably.
For product designers, who feel pain when obsessing over these small details, the challenge is clear. Convince others that the extra time is worth it, that taking time to polish the product will change the way people think about it, and that the other, secondary stuff we’re not getting to as a result just isn’t worth it. This has probably always been a problem and will probably always be a problem.
There is, however, an easy test for this. Ask people what products they love most, the ones the use the most. Almost invariably it will be products with an amazing fit and finish, products that someone took a lot of care to get the details right, where someone took the time to move the button 3px to the left.
I think our industry does feedback really poorly. I sure as hell do. My first impulse whenever I see a comp is to shit on it. Honestly. Even if it looks great. Especially if it looks great. We instinctively want to pick apart any deficiencies as soon as possible because that’s how product is created. We build things incrementally, chipping away the rough edges until we have a clean polished surface underneath it all.
I think that leads to a feeling that being emotional or cruel is actually helpful during design or code reviews. That the approach cuts away the fat even quicker, which is a great thing since we can get to that finished product quicker, right? Because that’s really all that matters anyway, after everything is said and done: if The Product is unimpeachable, everything was worth it. Sleeping under your desk. Yelling at your coworkers. Pushing to make that final iteration. It’s all for The Sake Of The Product.
Zach makes the point that there is more than one goal when giving feedback…it’s not just about improving the product at the expense of everything else. In many cases feedback should be given appropriately, with the goal of thoughtfully directing the designer in addition to building a great product. And everyone should be part of this process of getting feedback, from junior designers to the designer emeritus. Everyone needs an editor.
Further, I think the dynamic in which feedback happens is important. If it’s a dynamic in which a “design czar” provides feedback to a designer as a corrective device then it’s often a negative experience for both parties. However, if it’s a dynamic in which a designer seeks out feedback from design peers then it tends to be a lot healthier and a positive experience for both parties. When craftspeople push each other to do good work as a matter of pride then good things happen. For some reason the notion of being a Steve Jobs-like design czar has taken hold much more than it should have…what worked for Jobs probably doesn’t work for you and me.
“Looking back at the ideas espoused by the UX community, I find their relevance to my work winnowing by the year. Many of the practices seem forged in the fires of consultancy. Advocacy is a repeat theme in UX writing, but is borderline irrelevant when working for a product- and design-centric organization. Similarly, when you have internal stakeholders who understand the design process, you don’t need to worry about constantly building consensus. Deliverables like lengthy specs, comprehensive wireframes, and pixel-perfect PSDs are all artifacts from a time when risk-averse clients needed to enforce progress and limit variability. Inside of a product company, these efforts waste time, create politics, and mask responsibility.”
I tend to agree…although I don’t equate UX with deliverables necessarily. The reason why I now use the term “product design” is that it best captures the output of the design we do…as design titles have traditionally done. The items you make define what type of designer you are…and since so many people are now building products (vs. websites or even worse experiences) then that’s what we should call them (us). The age of product design is upon us.
Solid piece by Nick Bilton in the New York Times about the trend of flat UI: The Flattening of Design
1) I’m not convinced that flat UI is a good thing…in my experience it does make UIs seem simpler but often at the expense of visual priority and affordances. Many flat UIs suffer from a very real problem in which clickable elements are not obvious, and often look like non-clickable elements (because everything is flat)
2) Design as news still fascinates me. Three or four years ago you would never have seen an article about a UI design trend like this published in the New York Times. I love it.
3) I think that Heller is right when he says that flat UI is basically just a trend.
“Every so often there is a new fashion that comes about in design for any number of reasons, not the least of which is technology, and now there has been a reaction to mechanistic-looking design where you press a button and get a specific look,” Mr. Heller said. “In response, designers have started to turn to flatness.”
Interesting piece on how Facebook did UX testing for their new Home software. Some of the more interesting bits include:
- Did most of the testing on Facebook employees (non-design or development)
- Utilized diary testing to find out about long-term effects of content (initial reaction is often positive, wanted to see how people liked it over time)
- Testing priority was on first-time user experience
- Live stream testing that anybody can view in real-time
- Send out a weekly email to the team with highlights of testing
Cindy Alvarez makes a great point about how people talk about products…when talking about using something new we usually talk about what we’re replacing. She suggests these comments take one of several forms:
- Now that I use X, I’ve stopped using Y
- Using X means I no longer need to do Y
- X is much easier than Y
- I used to do Y, but I haven’t since I discovered X
This echoes my experience as well. People talk about competitors and replacements constantly, but companies selling products don’t very much. This makes sense in some cases, depending on your product positioning, as you don’t always want to take competitors head-on. (and in some cases the product your replacing isn’t in the same category as you) In other cases, however, I think replacement talk is under-utilized. Customer testimonials, for example, are a great place to talk about replacements, as it mirrors the talk of your customers anyway. When your customers talk about replacing your competitor with you, its a lot more powerful than you talk about that replacement, and its also answering a question that your customers already have.
In general, if you’re solving a real problem, then you are almost always going to be replacing whatever solution your customer already has.
My good friend and colleague Dan Ritzenthaler has written Wireframes: A good communication tool, a poor design tool, an article that captures his insights on a lot of the conversations we’ve had lately at HubSpot.
Dan is not dismissive of wireframes, but he doesn’t think they’re a good design tool. Instead, Dan says that wireframes are better characterized as a communication tool, a sentiment I agree with:
“A wireframe is good for gathering and consolidating the design thinking—the conversations and sketches—that has already occurred. Wireframes are good at opening up avenues of communication and spurring useful feedback. They can help you obtain someone’s approval, or move a project on to its next phase. Emails, contracts, and specifications also provide this kind of value. I like to call it “paperwork.”
Recently I had the honor to be interviewed by Des Traynor for the excellent Intercom blog. Des and I talked about the controversy around whether wireframes are dead (they are , about working and designing remotely, as well as the role of metrics in the future of design. Des is a great interviewer, asks piercing questions, and generally we had a lot of fun. You can also read the transcript of the interview if you would rather that than the audio.
MY TWEETSTweets by @bokardo
LATEST BLOG POSTS
Marketers and advertisers get a bad reputation because they continually break the fundamentals of design. This morning I was reading a post about how Facebook is calling out “local search” in its IOS app. As I was reading the article a Facebook Recommend widget pops up, blocking the very content I was attempting to read.
This is yet another case of interruptive marketing. Not only is this annoying, but I could not actually finish the article. I gave up, and instead of potentially linking to it because it is good content I’m now linking to it because it is annoying.
What do I mean about breaking the fundamentals? I mean that marketers and advertisers are ruining the very basic activities they’re trying to hitch a ride with. In this case, they’re trying to increase my “engagement” on their site by directing my attention to some recommended content. But they’re directing my attention much too early, before I’ve even had a chance to read the content I came to read. The activity I’m trying to do is to read the article. The activity the site should want me to complete is to read the article, for then I will be ready to do something else (like dig deeper on the site or read a related article). Instead, what they’ve done is discredit themselves and frustrated me. A horrible outcome for them.
So let’s state it plainly: the purpose of an article page is to read the article. It’s not to show an advertisement. It’s not to get a click. It’s not to create a lead. It’s not to read related or recommended items. It’s to read the damn article! Once that core activity is complete then we can think about doing something else, but not before.
I think this sort of thing happens because nobody really believes they’re building relationships with readers. They can’t see people reading and getting frustrated, so they start to focus too much on their immediate goals at the expense of their readers’. It’s too bad, if people just honored the very basic interaction they are asking people to have with their content, they might just build the relationship they’re looking for.
Or so said Seth Godin recently when he visited a Boston startup called Intelligently and gave a great hour long chat on startups, products, and marketing. I have been a fan of Seth’s for a decade or so, and this statement really resonated with me for several reasons.
First, it makes my work make sense. I do product design all day (interfaces, screens, flows, etc) but I also obsess over things like product positioning, communicating the value of your product, and how to sell your product online. These are sometimes called “marketing”, but to me all of those things are just part of the overall user experience…if the experience is the product then all of those interactions are crucial as well. I call this progression the Usage Lifecycle.
Second, it buckets similar problems together. The problem of knowing what product to build is something that both product designers and marketers need to understand intimately in order to do their jobs…the designers in order to design the product and the marketer in order to share the story. Both designers and marketers then need to continue to focus on that problem so they know how to proceed…is the product and its story resonating with people or not?
So watch the video to see the master in action. The section about marketing and product design being the same thing comes in at 60:56 and is a response to a question (asked by Tara Dimaggio of Wordstream) about aligning marketing and product design. Here is full transcript of that section.
“See-monkey marketing (ads in the comics that take a product that isn’t anything and try to get us to think it’s something) is over. I would have the people in the marketing department work physically in proximity with the other people and one day a week actually work on product design. And I would have the product design people spend one day a week making sales calls. The product and the marketing are the same thing. And any organization that is splitting them apart is making a huge mistake. Selling is selling…I’ll buy that. But marketing and product design are the same thing.”
The first, What “Disrupt” Really Means, by Andy Rachleff makes the point that its usually business models that are disruptive, not products. And contrary to Clayton Christensen’s definition of disruptive (low-cost, low-margin, low-quality) Rachleff suggests there is such a thing as “high-end” disruption, when a company like Uber offers a competing service that is more convenient, but more expensive than its taxi alternative.
The second, Stop Re-inventing Disruption, a response of sorts by Maxwell Wessel, argues that Rachleff’s idea of a high-end disruption doesn’t make sense. Disruption is a low-end, low-quality, low margin affair, and explains why incumbents get beat even though they are intelligent, well aware, and have capital to spend. The disruption happens because these companies consciously choose not to compete on the low-end because their business has evolved into a high-margin one.
Wessel also makes the distinction between disruption and innovation, which do seem to be used interchangeably sometimes. Innovation is simply making a better product, while disruption is a longer process…upending industries with low-end products that slowly eat away at the incumbents. He says that most of the examples of Rachleff’s are simply classic disruption done more quickly…as the pace of the world increases so does the pace of disruption.
Both authors make the point that some products are simply better, not necessarily disruptive. Wessel argues the iPhone was simply better than the phones it replaced…it wasn’t disruptive in the Clayton Christensen/Innovator’s Dilemma sense of the word. This is where the term “disruptive” becomes problematic…obviously the iPhone completely changed the game within the mobile industry. It’s disruptive in the normal sense of the word…
At any rate, I’m not sure that whether something is “disruptive” is much of an issue on the level of product design, but it is interesting to note that for some products to succeed they don’t necessarily have to be higher quality than the alternative. They might just be cheaper, or offer some functionality that the incumbents cannot (like Google Docs collaboration features). Even though they aren’t higher quality, they still find a foothold in the marketplace. As existing products add feature after feature over time, the opportunity for disruption increases.
Datapoint: In my professional career I’ve worked with companies of all sizes and every single one of them wants to be more like Apple. Hell, in all of my work I want to be more like Apple.
So…Horace Dediu asks…why doesn’t anybody copy Apple?
Dediu makes a very important distinction: the distinction between copying a product and copying the product development process. Obviously every company in every industry that Apple competes in is copying their products to some extent. All phones are now like the iPhone. All tablets are now like the iPad. All laptops are now like Macbooks. All product marketing is now like Apple’s product marketing. Etc.
But that’s only copying the end result. And that’s not the same as copying the product development process that produces such results. I think it is safe to assume that most companies hope it is sufficient to copy the end result and not the process. (their behaviors suggests as much)
But as Michael Dell, Steve Balmer, and whoever runs Nokia, Toshiba, Blackberry, Rokio, Palm, HTC, etc, have found out, simply copying someone else’s product is not a viable long-term strategy. Even if you can copy a product like an iPhone, you haven’t even come close to catching up. You’ve caught up to two years before Apple released the product when they were actually designing the device. In total you’re about three years late.
So if everyone wants to be more like Apple, why don’t they? Dediu offers several reasons:
- Apple is not to be imitated because it’s not worth copying. I.e. Apple is not a successful company.
- Apple is successful but Apple cannot be copied because its success is a magical process involving sorcery.
I don’t like either of these explanations and neither does Dediu. So he offers a third possibility…that Apple is simply better than they’re letting on. I think this is right…and it’s reasonable given that nobody ever seems to know exactly what goes on out there in Cupertino.
Compare Apple’s excellence to Lebron James. Imagine being an NBA rookie who has been hailed as a prodigy all your life and you’ve been showered with praise since the day you could dunk. Now imagine lining up against Lebron James, who just recently went on one of the most amazing scoring stretches ever. You just became second fiddle and will stay second fiddle as long as Lebron is in the league. There is no satisfying way to explain how good Lebron is. Is it natural skill? Is it hard work? Is it competition? Is it luck? Yes. The answer is yes. And the same goes for Apple…they excel at everything.
The difference is that you can’t just copy Lebron James. You can’t just throw down 30 plus points every night. So in basketball there is a very clear ceiling to your talent…it is impossible to the “product” of those better than you. In electronics, however, it seems possible to copy a product like the iPhone. So that’s what everyone does, hoping to replicate the phenomenal market success that Apple has had. But you know what? I bet if you looked a little more closely, nobody is really, truly, faithfully copying Apple at all…they’re copying some version of Apple that exists in their heads. That’s why nobody has built an ecosystem that is as good as Apple’s yet.
What people should copy, instead, is Apple’s unwavering commitment to product quality. Apple’s commitment to quality has been clear since 1997, when Jobs came back to lead the company. Jobs said it again and again. Tim Cook is now saying it. That’s the key to Apple’s success…that they take a completely different approach from all the other companies who put profits first. Jobs started with the idea that quality products will find buyers, and so put quality above all else. Later (years and years later) Jobs looks like a genius that everyone wants to emulate.
But here’s the thing. If you compete on quality, your product will necessarily be different from others. You’ll find your own way, your own path through the markets you compete in. To be better than Apple you must look away from Apple, and instead find your inspiration from your customers, the world, or someplace else. That’s why copying is so deadly…it kills your enthusiasm for invention and the thrill of making something new while distracting you from what’s important. Copying not only signals a lack of imagination, it’s the symptom of bigger problems.
For companies that don’t have the ability to compete on quality, they end up copying someone else who does.
We’ve been using Layervault at HubSpot for a week or so now. It’s a beautiful app, and has a lot of really nice UI touches. The first thing you notice when using the app is that it’s a good example of a flat UI…and the team has written about their thoughts on that.
And while I applaud the minimalist aesthetic and the push toward eliminating elements from the interface (something good designers continuously do) I believe they’ve gone one step too far…they’ve removed labels from their navigation bar. Here is what it looks like:
I have used this UI now for a week and I still have do a double-take each time I want to navigate. I’m not learning what the icons mean. The folder icon represents “projects”, which I can usually remember (but I think I remember it because it’s simply the first and default option). The second icon, a factory, is actually a link to the “Manage” screen, where you manage people and projects. This trips me up every time. (there isn’t hover text either…I find myself looking at the URL in the status bar to confirm where I’m going).
My guess is that in an attempt to be as minimal as possible the designers removed every single thing except what they deemed truly necessary. This should be applauded! (and in general the design is excellent…I’m simply mentioning this because I noticed it right now) However, I think labels should be kept around in almost all cases as they turn guesses into clear decisions. Nothing says “manage” like “manage”. In other words, in the battle of clarity between icons and labels, labels always win.