Twitter Updates

    follow me on Twitter

    March 2014

    Sun Mon Tue Wed Thu Fri Sat
    2 3 4 5 6 7 8
    9 10 11 12 13 14 15
    16 17 18 19 20 21 22
    23 24 25 26 27 28 29
    30 31          

    « The Blog: User Centered Design Tool? | Main | Making Design Patterns Work in Practice »

    January 21, 2010


    The roof example is brilliant. The hole-drill example is also good (all the good design books use this example, but I still love it), but both example needs good balancing. Will I reject a window for a roof? I don't think so. There are set of minimum features what I need. After the minimum it is also a question of balancing what is more important.

    Just some addition for the drill-hole example: standards. If there is a standard solution for something you need to explain carefully why do you give something different. If I need a drill no one try to sell me a laser, black hole, whatever. Drill is a standard and as a user I may need it. And people are slow and traditional and most of them are don't like new stuff - even the non-conservatives needs some stable point. So balancing again is important.

    Kodak... I disagree. Maybe in the US it has the top market share, but it is not because the weak easyshare feature. Kodak has a name because of films for analog cameras. I do not know why they can sell any of its digital cameras - it can be a question of marketing, name, brand, resellers, whatever, but I am pretty sure the easyshare function is pretty unused. However easyshare function has a good name, but I tried to use that some years ago and when if I clicked the button nothing happened. However I can't imagine a good workflow for that, because I do not have email addresses in my camera - if it needs to synchronize with my mobile phone for my address book it is better to take a picture with my phone...

    On a slightly less serious note, I have yet to go into a hardware store and ask for a pack of quarter-inch holes. And I'd walk right past the hole-supportive workflow solutions counter to go and pick up my drill. I don't go to the hardware store for holes, I go there for tools which I then use as I see fit.

    Also, I own a Kodak EasyShare camera. I have never used the EasyShare workflow and never will. EasyShare played no part in my purchase decision-making process. My 80-year old mother also refuses to fit into the EasyShare workflow model, despite owning an EasyShare camera and docking station / printer, which sits gathering dust.

    We both like the fact that the cameras have easily removed SD cards, allowing us to do pretty much what we like with our photos without having to conform to somebody else's carefully designed (and restrictive) workflow.

    The trouble is, you have millions of customers with millions of different workflows. You can't possibly understand and cater for them all. By all means provide a set of tools thet supports a certain set of common workflows, but don't expect that you can cover anything but a small portion of your customers' needs with those workflows.

    You also can't expect that if you design a set of tools for a given workflow, those tools are all going to be provided fully baked and working well together. Frequently, an unforeseen problem or insufficient development time leads to one portion of a workflow being half-baked or broken. Result? The customer can't use the workflow you decided that they needed.

    So you still need to provide a wide set of tools, even if you can't fit those tools into a convenient workflow box. The best source of information about what those tools should be is the customer. Despite what I'm reading here, which appears dangerously close to "we know best", customers have a much better idea of what they need (not just want) than any software developer. True, some articulate their needs better than others, but the users are the experts on using the product, not the developers.

    As for bloat, users certainly don't like that, but they absolutely loathe it when the bloat appears to be a result of developers adding stuff they haven't asked for, or even seen anybody else asking for. Recent AutoCAD history is replete with examples of this, and I bet they're based on carefully designed workflows that most users won't follow.

    Thanks for these articles Lynn and John. I agree completely that understanding user goals and identifying workflows are critical for creating useful and usable software features.

    My favorite example of bad design and product bloat caused by long feature lists is MS Word somewhere around the Office '97 release. Being a Word power user since Word 2.0 I came to dread each new release, knowing that the features important to my work would be buried under more and more features that I would never use, some of which were just downright puzzling. Microsoft, realizing the problems users were having because of the feature bloat, added insult to injury by implementing the infamous disappearing menu items as a solution.(

    My favorite puzzler was the feature that allowed you to make your text look like marching ants! Where did this come from? My theory was that this came out of long lists of customer requests resulting from someone asking users what they would like added to the product, with marching ants being the equivalent of "kitchen sink".

    A couple of years later I happened to be giving a talk at an event along with the director of one of Microsoft's HCI Research Labs and she confirmed my suspicions. The product features were driven by requirements lists gathered during marketing-led focus groups. She lamented that the HCI researchers were ignored when they suggested a user-centered approach to researching user's needs or warned against implementing features like Clippy. Since the development teams had no contact with how their customers really used the product, there was no way to prioritize such lists so the safe thing to do is just throw it all in, right?

    The most dangerous thing we can do when conducting user research is ask users what they want, when we really need to understand what they need. And that is something the user generally doesn't consciously know or can't articulate. It's our job to discover user needs based on our research, understand their goals, and design the workflow necessary to realize them.

    The comments to this entry are closed.

    RSS Feed

    • Subscribe