Why I’d Love to See Graded Interaction Design Problems

One reason I love bouldering is that it’s game-like. No matter how much experience a climber has, we’re all at a certain level with certain climbs (they’re actually called “problems”) that currently challenge us. It’s like playing a well-crafted video game: the levels you’ve finished are easy, the levels ahead of you are frustratingly hard, but the level you’re currently on is a good match of difficulty for your skill level; and you can feel the flow.

8wng7

I recently started learning a new programming language and I find it similarly game-like. Every new technique is a new challenge. Every new algorithm is a new challenge. The easy stuff is boring, the crazy theoretically stuff is frustrating, but the next chapter in my book is just right.

And like video games, in bouldering these problems are codified. So I can say, “I can do all the V0′s in this gym, and I’m working on the V1′s” and other climbers know something about my abilities.* Codified problems exist elsewhere too. Here’s some to help people improve their skills playing Go.

I’d love to see graded problems for interaction design. They would make it fun to solve problems, alone or socially, and communicate to each other our level of ability. “But Victor,” you might say, “interaction design problems don’t have a defined solution like a boulder.” Actually the boulders don’t either. People can solve the same problem different ways, but there are rules everyone must follow that give the game useful constraints. As long as you follow the rules and get to the top you’ve solved the problem. Some climbers are more elegant than others, and the same would be true in interaction design.

* The Moonboard is like graded problem-meets-Github, a single wall with over 800 bouldering problems contributed by various route setters.

Reader Reviews #6/7: “eye-opening….thoroughly researched”

Why We Fail is available in eBook form at O’Reilly and all the reviewers there gave me 5 stars! Yay!

Paul in Austin writes:

The case studies alone provide an very interesting read to anybody who has some interest in technology in general.

Each case study has been thoroughly researched with plenty of references. The author also provides video clips to help the reader visualize the user experience of the discussed products.

In addition to user interface developers or designers, product managers and architects will also benefit from the methods for avoiding future UX failures described in the second half of the book.

BOTTOM LINE Yes, I would recommend this to a friend

Ken in Hoboken writes:

Too many books focus on success but I feel the best way to learn is by studying failures.

Prior to reading “Why We Fail”, the only other book I read along the same lines was “Billion Dollar Lessons: What You Can Learn from the Most Inexcusable Business Failures of the Last 25 Years” by Carroll & Mui.

I am an engineer, not a designer, but I often consult on projects where no UX person is hired, forcing me to assume that role in some fashion. I found this book to provide great insights that I would not have otherwise considered.

For example, as an engineer, I focus on meeting the user requirements, but the case study on the failure of the Microsoft Zune music player (Chapter 5) demonstrates how much more powerful the user experience is over the feature set.

I found it an eye-opening revelation in Chapter 9 that Microsoft’s many expensive failures is due to its practice of sweeping mistakes under the rug and never sharing experiences with their product groups.

Chapter 7′s discussion on ethics is a valuable addition to the material.

I highly recommend this book.

BOTTOM LINE Yes, I would recommend this to a friend

Good Design Can Make the Elevator Pitch Futile

I had a five-minute conversation with an angel investor last week and described the product I’m working on. His response: “Similar things are being done by bigger companies with giant marketing budgets, so you’ll need a very clever marketing idea to succeed. What is it?”

There was an uncomfortable pause. On one hand, I haven’t thought up any great marketing ideas yet and wondered if that was a hole in my plan. On the other hand, I was pretty sure this investor and I had very different perspectives on product development, but I didn’t have the language to succinctly express that gap.

I did understand what he meant. A few years ago I managed a large online dating service. We radically updated the design and added great features, but it was the online marketing that kept the revenue coming in. Why? I believe that while the design was good, the product wasn’t positioned to differentiate it from the competition. By contrast, if you design a product that’s different and more exciting than the competition, like the Anki DRIVE, there will be a lot more free media exposure and word of mouth to complement paid marketing.

My downfall, I think, is that I was trying to tell this investor about the product rather than show him. If my new and improved positioning is a result of product design, I need to show the product. For example, if I verbally described the Anki DRIVE as, “a racing game that combines an iOS app with physical race cars” that’s sounds mildly exciting. Watching the video is so much better…

Agile Ain’t Wishy Washy

As I write this there’s a group of about 15 developers and designers standing near my desk in a heated but constructive argument about how to check the design is right before the code heads off to QA.

Occasionally the dichotomy of agile vs. waterfall is raised, and sometimes “agile” is used as a euphemism for “flexible” as in, “well, there was an update in design document X, and we’re agile, so you should be able to integrate that.”

If there’s one thing I’ve learned from doing agile it’s that agile ain’t wishy washy, i.e. it’s not really some sort of flexibility nirvana. Any software development process relies on firm lines drawn around what, when, and how the work gets done. Otherwise, shit don’t get done.

Yes, agile is better at responding to change. But it is effective, somewhat counterintuitively, because it responds to change with a high degree of rigidity. For example, if the stories aren’t written in a way that makes it clear to developers how to code a feature and how to test it, it doesn’t get accepted into a sprint. Once stories are accepted into a sprint nothing else can start until the next sprint. And so on. When I first encountered all this rigidity I thought the developers were acting like self-involved prima donnas. Actually, they’re just enforcing the rules that make the process work.

Agile responds to change, not wishy washiness.

Startup Legal Straight Dope

A benefit of being a speaker at Failcon was getting an invitation to a talk hosted by Anit Guha of Orrick Legal. Here’s some of his wisdom that I noted down:

  • When choosing a name use the uspto site and a 3rd party search service
  • Avoid incorporating in California; use Delaware C Corp. Not only because of the company-friendly laws in DE, but because everyone incorporates there so everyone is familiar with the legal aspects involved.
  • Founder vesting: vesting important if someone leaves. Typical is four years with a one year cliff, maybe some acceleration too. Can backdate the start of vesting if significant work was done before company was formed.
  • Worker classification: consultants vs employees; employees involve more overhead. But you must follow legal definition, state and federal laws when bringing someone on (you can’t avoid the employee overhead if the person is actually working as an employee).
  • Invention assignment – very important that everyone signs and agrees that ideas and inventions belong to the company; it’s pretty broad, it’s negotiated individually
  • Use offer letters for everyone
  • Use release agreements for involuntary terminated employees. They can refuse to sign; you need to pay them to make it enforceable.
  • Investor “finders” must be a registered broker dealer, otherwise you can’t pay them for that service.
  • Rule 701 disclosure obligations, options valued over 5 mil in 12 month period should be disclosed.
  • Only raise from accredited investors.
  • Taxes at acquisition can lead to a liability if you’re not careful.

RealNetworks and The Trap of Binary Thinking

While I was researching my book Why We Fail: Learning from Experience Design Failures I spent some time reading about people’s experience with RealNetworks, particularly the RealPlayer, and wondering if they were worthy of inclusion in the book, particularly the don’t be evil chapter. At that point there was no smoking gun, no hard evidence that Real intentionally did the wrong thing.

But this week a story was published which confirmed my suspicions. It’s called The Graph That Changed Me. Here’s an excerpt:

One day my manager showed me a horrible graph. It was pretty simple: the graph was steady, then it dropped straight down, then after a short period, the line shot straight back up and stayed level again:

Artist’s rendering of why you probably don’t like RealPlayer much
“That’s what happens when we do the right thing”, he said while pointing at the drop, “and that’s how much money we lose. We tried it just to see how bad it was for our bottom line. And this is what the data tells us.”

“Wow,” I said, taken aback. My employer clearly had two options: “do the right thing” or “be profitable”. That was the position they had maneuvered themselves into through a series of bad management decisions.

That “series of bad management decisions” may involve a slippery slope of subtle temptations and minor rationalizations, not one big bad decision to be evil. But having been there I know it’s all too easy to fall into the trap of binary thinking. You can hear it in that story:

two options: “do the right thing” or “be profitable”.

Design thinking is abductive, inventing new options to find new and better solutions to problems. In the universe of all possible businesses, were there more options than just “do the right thing” or “be profitable”? Of course. We just need to be willing to try harder, apply our creativity, and make “do the right thing and be profitable” two constraints of the design problem.

“We are going to make one computer for each quadrant”

Love this Steve Jobs story:

…Jobs turned around Apple and did it pretty quickly. He did two primary things as far as I can tell. First, he got his people into the top jobs and got rid of the executives who had been calling the shots before he showed up. And second, he brought focus to the product line, and thus everything else.

There’s this great scene in the book where Jobs draws a classic four quadrant chart, consumer and pro on one axis, desktop and laptop on the other. And he says “we are going to make one computer for each quadrant and we are going to kill all of the other product lines”.

Are Amazon’s Drones Crazy or Awesome?

Rosenfeld Media asked me my opinion of Amazon’s idea to use drones to deliver packages. Here’s a short excerpt from the interview:

Say what you will about Jeff Bezos, the man knows how to touch off a media storm. Which is precisely what ensued after Bezos told 60 Minutes that Amazon is testing the use of drones to deliver goods. Immediately, everyone was discussing the prospect of ordering a box of tissues from Amazon and having a drone arrive at your doorstep in half an hour. We’ve asked some Rosenfeld Media experts to join the fray on this audacious idea.

It’s a longshot that this will ever happen.  But let’s imagine for a moment that Amazon pulls this off.  A terrible road to go down, or awesome?

Victor Lombardi: The danger is in trying to answer this question using reason rather than experimentation. And that’s because drone package delivery is so new we have no idea if it’s awesome or not. To find out, we need to test it. The reason we fail to get these things right is because we fail to treat them as experiments. We fall in love with ideas, with visionaries, with progress for the sake of progress. And that leads to failure.

Read the the full interview at Rosenfeld Media.

The Skinny on Life Insurance

As I work on Nickel I realize that normal people don’t understand life insurance. It’s so important to protect our families from financial problems and yet frustratingly difficult to understand.

So I tried setting down in as few words as possible the process of getting basic coverage. Here’s my first draft:

Life insurance pays your family a large sum of money when you die (or pays you when your spouse dies). These days most of us have some sort of debt (for example, a mortgage) and expenses (children’s college tuition) that our family could have trouble paying without our salary. Life insurance solves this problem.

It works like other insurance: you get a policy, you pay for it every year, and when something bad happens the insurance company pays up.

How to buy life insurance:

1. Figure out how much life insurance you need so your family doesn’t have to pay it all off without you. Add these together:
* How much you owe on your mortgage
* How much you owe on any other debts you have

Then figure out how much more insurance you would like. Add these together:
* The cost of big expenses now or in the future, like college tuition
* Extra money to help your spouse. Remember, she/he will be grieving after you die and not necessarily ready to start hunting for a better job.

Add all of the above. That’s the “coverage” you need, the amount of the policy. For some people $100,000 is enough, others need $1 million or more.

2. Ask friends and family for a life insurance agent or financial planner they trust. Buy the insurance through them. Do not pay them. They are paid a commission by the life insurance company, so you are essentially getting free advice. Also, ask him or her to explain how to deduct the cost of the insurance on your taxes.

3. Sign up for a simple “Term Insurance” policy (start simple; you can always get more coverage later). You’ll fill out some forms, answer questions about your health, and maybe have to get a physical. Answer all questions honestly. And pay your bill every year.

When reliability doesn’t tarnish the brand/experience

In another case of it’s the experience not the design, Consumer Reports found that BMW and Harley Davidson motorcycles were three times more likely have have serious mechanical problems versus a Japanese brand, but their owners were more likely to buy that brand again.

On the other side of the coin though, when asked whether they would buy their bikes again, 75% of Harley-Davidson owners said “definitely yes” while 74% of BMW and 72% of Honda owners made a similar remark. Meanwhile, only 63% and 60% of Yamaha and Kawasaki owners, respectively, said the same about their motorcycles.

We don’t know if this surprising correlation is due to brand loyalty or a different overall experience of the product that goes beyond reliability, but it’s an interesting data point.

Uncertainty, Argh!

I just heard a talk at Lean Startup Machine NYC by Jonathan Fields, author of the book Uncertainty: Turning Fear and Doubt into Fuel for Brilliance. It was only about 20 minutes but had maybe the highest useful content density of any talk I’ve ever heard. Here’s a few notes:

A startup at the beginning is filled with uncertainty about your product, market, everything. We experience uncertainty as pain. Usually we react by changing speed: we slow to a crawl because we’re paralyzed by imperfect information, or we rush to the end to make the pain stop.

As you conduct experiments, data replaces uncertainty; the process eases us down the uncertainty curve.

So, don’t freak out. Get data, Focus conversations on the data.

Other excellent advice:

  • We are not made to concentrate for more than 90 minutes. Our brain is wired to take breaks, that’s why ideas come to us in the shower. So, do 90 minutes of work, then 20-30 minutes of something unrelated. This reminds me of the Pomodoro Technique which helped me crank out several book chapters.
  • We can manipulate intelligence by priming the brain, either positively or negatively. You could say to a group of men, “Men do 50% worse on this test you’re about to take” and they will! So, create positive priming, e.g. start meetings with 60 seconds of a story about something cool that happened today.
  • Meditation and exercise are the two best innovation techniques anyone can practice, but ironically people in startups give them up first to do more work. Instead when we’re working hard we should double down on meditation and exercise. Spending quality time away from work improves the work, helping us do better work in less time.

Ray Dalio: High Performance by Avoiding Failure

John Cassidy penned a powerful piece for the current issue of the New Yorker titled, Mastering the Machine: How Ray Dalio built the world’s richest and strangest hedge fund. Part of Dalio’s success in creating massive financial returns while controlling risk stems from his financial wisdom, but the success of his 1000-person organization that runs their three funds has been attributed to how he’s created a culture of “truth and transparency” which helps them (among other things) avoid and learn from failure.

My summary of the key characteristics as described in the article:

  • Discussing issues by citing evidence and experience rather than mere educated guesses
  • Expressing opinions in a transparent way, and giving forthright feedback to anyone else in the organization
  • Removing the emotional reaction to mistakes so people understand clearly why they happened and can logically discuss how to avoid them next time

And one quote from Dalio:

What we’re trying to have is a place where there are no ego barriers, no emotional reactions to mistakes…. If we could eliminate all those reactions, we’d learn so much faster.