Noise Between Stations

Month: April 2014

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