Author: Victor

Learning JavaScript, Day 4

I recently decided to re-learn programming. Because I already know HTML and CSS the web is a fast prototyping environment for me, so JavaScript is the logical language for me to learn. Besides,

  1. JavaScript has stood the test of time and the community has improved it a lot
  2. It’s now on the backend too
  3. There’s a ton of new/cool learning resources
  4. jQuery

At first I tried learning from a traditional book, from CodeAcademy, and by reading online. But I was only spending 30 minutes a day on it, and nothing stuck. It’s like my guitar teacher told me when I was 14: “When you start, you need to practice at least an hour a day to train your brain to think this way, or it’s not going to work.”

Four days ago I bought the excellent Head First JavaScript Programming book and have been making my way through a chapter a day, obediantly doing all the exercises with a pencil in the book and in code on the computer.

It feels great. My brain is so happy to learn something new and useful. After day 2 I was able to bang out a simple prototype of an algorithm that was too painful to do in Excel. I wish I had done this sooner.

2014 is the Year I Learn JavaScript

I’m at the point in my project where I need to prototype some software ideas. Doing it on the web is cheaper, simpler, and faster than prototyping a mobile app. And everything I need to do can be done on the front-end, for now. So I’m probably looking at JavaScript or Ruby on Rails, though there are other options.

I went looking to hire a programmer or a small firm to help me. I even wrote a simple spec to make the task official. But it turns out my task is not complicated enough to engage someone else.[1] And yet it’s beyond my HTML/CSS skills.

When I was young I taught myself BASIC on my Sinclair 1000, optimizing code to fit in 1K of memory. I kept those skills fresh in high school and college and even did a bit of Pascal work in grad school.

But that was a long time ago. Since then I’ve been busy learning about networks, then design, then business, then being a husband and father. Just about every year I would wonder if I should re-learn programming, if only to prototype my interaction design ideas. This often took the form of, “Should this be the year I learn Flash?” The good news is I didn’t spend a lot of time developing deep Flash expertise.

Why is 2014 any different? A few reasons:

  1. There’s increasing discussion about the pros and cons of unicorns
  2. When trying to fill an interaction design position recently I interviewed two actual unicorns. They really exist!
  3. I love to learn, and I feel a little tapped out of new things to learn in UX. Not that I know it all, I certainly don’t, but there’s nothing so new it stimulates my brain like it used to.
  4. Programming is such an exciting field these days. Stuff like Github, node.js, Rails, and non-SQL databases make it possible to make new things in new ways.

So, it’s time to learn JavaScript. More on that choice in my next post.

[1] And all the developers I talk to want to differentiate based on services. I hear from a lot of people that want to brainstorm, to partner on ideas, to think about strategy and process, and to measure ROI. For once I’d love to hear someone say, “All we want to do is write solid code at a reasonable price.” return to text

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

Trends in Design for Financial Services, April 2014

I frequently design financial services, and having just rolled off a project took some time to reflect on trends I’ve noticed. Here’s the first three that came to mind:

  1. Active participation by the affluent: Sometimes financial services companies assume the affluent don’t want to interact with computer services themselves. In reality, the affluent don’t want to feel like they have second-class tools compared to their less-affluent friends who use sexy mass market services. I first saw this in 2008 doing international research for the private banking unit of a giant bank and again more recently with an insurance company.
  2. Breakdown of client vs. consultant views: It used to be common to pour all the design work into the client-facing screens and rush through the consultant-facing screens. With the spread of smartphones and tablets everyone expects top-notch design, and consultants will work on their tablets alongside the client.
  3. Breakdown of mobile vs. desktop: When mobile was new a lot of attention was paid to what it meant to design for mobile. Now people expect services to just work on whatever device they’re using.

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.

Published
Categorized as Agile

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.

My book, Why We Fail, is out!

This blog has been quiet for so long because I’ve been working on my first book, and it’s finally published. Why We Fail: Learning from Experience Design Failures is about websites and consumer electronics that were successfully launched and hailed as great designs, but failed unexpectedly when people used them, plus my attempt to explain why that happened and what people who make them can do to avoid failing.

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.

Published
Categorized as Writing

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.

Published
Categorized as Design

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.