“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.

The post Justifying fit and finish appeared first on Bokardo.

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.

The post Two goals of giving feedback appeared first on Bokardo.

“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.

The post Product design replacing UX? appeared first on Bokardo.

Several thoughts:

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.”

The post To flat or not to flat? appeared first on Bokardo.

• 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

The post How Facebook did UX testing for Home appeared first on Bokardo.

• 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.

The post Your product is replacing something…what is it? appeared first on Bokardo.

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.

The post Breaking the fundamentals appeared first on Bokardo.

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.”

The post Wireframes are dead. Long live wireframes. appeared first on Bokardo.

The post My thoughts on wireframing, remote working, and the role of metrics in design appeared first on Bokardo.

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 post Marketing and product design are the same thing. appeared first on Bokardo.

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.

The post Weekend reading: Disruption vs. Innovation appeared first on Bokardo.

So instead of “hey wouldn’t it be cool if…?” it’s more like “hey, did you know that…?”. It’s a small change of words, yes, but the first question is rooted in theory and second is rooted in reality. Base your product decisions on existing behavior. That doesn’t make for easier or less challenging problems, either. Existing problems often exist because environmental variable got them that way, so even when you know the problem getting to a solution might still be a huge task.

Maciej introduces something called the “C-P-S” method. That is, the customer has a problem and you have a potential solution. Write the problem and solution down, along with the primary hypothesis to test, and build a fast MVP. The feedback from your MVP will determine your next steps…if people don’t like it you have to dig in to find out why. It’s a loose, spreadsheet-based framework but seems useful if you’re a startup person trying out a bunch of ideas.

The post Which problems to build product from? appeared first on Bokardo.

“‘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.”

Of all the things I’ve learned about design process in the past few years, this might be the most valuable as it helps keep a very tight focus on the things that matter.

The post Always be capturing: a valuable tip for effective meetings appeared first on Bokardo.

1. Find the quickest path to experience.
2. Doing is the best kind of thinking.
3. Use materials that move at the speed of thought to maximize your rate of learning.

These are really good rules…in general you should try to iterate as fast as possible while testing relevant hypotheses. In most cases this means very low fidelity. In hardware this is coat hangers and clay, in software this is sketches and post-its.

The post 3 Rules of Rapid Prototyping appeared first on Bokardo.

Williams says:

“Truth be told, we didn’t really care about Check-Ins either. It was just the action verb we put on the orange button that performed our app’s primary function. What we really wanted was for people to see the world through the eyes of their friends.

…It turns out there was another app that shared a similar vision called Burbn. They were building yet another check-in type service loaded with every feature but the kitchen sink. But early user feedback, coupled with a desire to avoid the check-in battle shitshow already in progress, led them to drop everything to focus on one simple feature: Photos…

They made their own rules. They called it Instagram.

That whole “see the world through the eyes of their friends” thing? Turns out Instagram did a pretty good job of this.

I’ve heard stories like this before…and they don’t usually end well. When you find yourself reacting to the market instead of driving forward with your vision of what can be, you lose not just momentum but clarity in your product design. Instead of “I can imagine something better” the routine becomes “we have to do what they do, just better”. This kills designer happiness quickly, and leads to a less-than-inspired product.

Advice like this, from someone like Williams, is priceless for anybody who wants to build visionary products.

The post How VC money can change your product appeared first on Bokardo.