I’m going to say one more thing on this and then leave it.

First of all, I just had to replace another bulb on a similar lamp. Vinnie, you were wondering if the effort required in changing the bulb would ever factor into purchase: yes. I didn buy these lamps, but I’ll absolutely never buy this model myself. Especially with the experience I have now, I don want to have to fuss around in the dark with having to disassemble a lamp module. As far as I am concerned, the ease of a twist-free bulb is an absolute requirement.

That aside, I stand by the point of my original post. When designing software in any way, you should consider the use by the end-user — at least to the point of not irritating that end-user.

Tyson, it is a good point about the 20%. And not only does each user require a different 20%, but no one actually knows in advance exactly which 20% anyone user will use. That would be some pretty amazing foresight.

Jamie, it is not always the best product that wins the race. Fashion, marketing, irrational decision-making, hype, luck, perception, corruption…
And what is winning the race with lightbulbs? A better design vs harder to change? Or easier to change vs less pretty? Those fluorescent tubes are often hard to change and are very popular…

What a discussion.

About this light bulb changing… the lightbulb that does exactly what it should and is easy to change will win the race. It’s just like cars that used to manual ignition (with a crank). As designs evolve we introduce levels of abstraction over our product versions. The crank becomes an ignition button, the dirty engine gets colour coded (ever seen a BMW engine?), etc. In software, we can evolve quicker by speaking to users and giving them what they. We can, with the right processes, tools, and skills, change software easily. That’s why I like to explore the solution space – but then again not everyone is the most brilliant software engineer in Holland… Sorry, couldn’t resist.

Good discussion. Keep them coming Ben, engaging the community and getting people thinking – I love it.

Jamie.

I enjoyed the essay, and agree with much of your summary. I think that the examples you use don’t really support your thesis, however.

It sounds like a real hassle to change the bulbs on that lighting. But so what? I doubt that very many people will include that factor in purchasing lighting. All else being exactly equal, they might prefer the easier to change bulbs (if they even remember that factor), but if changing that effects the appearance, cost, or lighting abilities of the device, forget it. Those other factors are so much more important that I doubt many people even consider the ease of changing bulbs when purchasing a light.

And as a dedicated crackberry user, I have to agree with Vinnie’s comment on email. You may not like it, but it very much fulfills user requirements for a lot of other people. When it doesn’t work well, the failure is not because mobile email is a fundamentally flawed concept, it’s because this has been bolted on to a lot of devices that don’t support it very well. When it’s done well (Blackberry, Treo, iPhone, etc.) it’s because the device was designed to include it. It’s not a coincidence that the most popular phones are all built around this. Not including email on a phone at this point would be a perfect example of what your post objects to: failing to address user needs.

And, regarding the 80/20 rule, I highly recommend that you read Joel Spolsky’s essay about this from a few years ago: http://www.joelonsoftware.com/articles/fog0000000020.html
(Quick summary: most users only use 20% or less of the functionality, but each user uses a different 20%. Anytime you drop a feature from a word processor you force people who need that feature to look elsewhere.) Again, that extra functionality you’re objecting to is there to solve the problem you’re describing.

-Tyson

Fair enough…

Lightbulb: The ladder and the ‘in the dark’ would apply to any light.
How about a different example. Is a car badly designed because it takes a few minutes, and a lever+jack, to change a flat tire? How about in the snow, in the dark, whilst on the side of a very busy highway?
I am happy to disagree that the ease of changing a lightbulb is high on the list of priorities when changing a light.

Mail: Happy to disagree on the usefulness of this. Not every product has to be designed with every single person in mind. As an end-user you don’t approve of mobile mail, but others end users do.

Firewall: Happy to disagree again as I don’t know enough about what purpose/segment the product was designed for originally. It does appear that the purchasers definitely did not consider the end-users properly.

Windows: With the firewall you were complaining that about ignoring possible end-user segments. And now about MS Office that they are accommodating all possible end-user segments. In office, there are a lot of features that MANY people don’t need, but I am not sure that there is anything that nobody needs. It has an amazingly broad appeal to both power users and basic users. I feel the 80-20 or 95-5 is required and does not make it bloated. MS Office is a lot more popular with end-users than MS Works is for example, a very similar product without the high-end capabilities.

I think Vista would illustrate the point a lot better. It was bulkier, slower and more complex than the end-users they targeted were prepared to accept. I think Microsoft did miss the target market on this through an incomplete understanding of what people wanted.

Another interesting point is that designing a product to do exactly what end-users want is not necessarily the best strategy, as often the end-users themselves don’t really know what they want, or why they want it.
Apple would be a great example of seemingly knowing what end-users want better than they do themselves.

Cheers,
-Vinnie

On the lightbulb: say that again when you’re standing on a ladder, in the dark, trying to undo two overhead screws at an angle.

Mail: we’ll have to agree to disagree.

The firewall: again, I consider this an example of ignoring an end user category. You can disagree on who did the ignoring.

MS Office: re-read what I said. I’m not complaining about the part that works but about the part that nobody needs (I’m sure you’ve heard of the 80-20 rule, which I think is more like a 95-5 rule in practice). How do you consider it designing for the end-user if you’re building something that is not needed?

Of course, people like Google burn millions because they are searching the solution space for, they don’t know what! They are looking for the next Black Swan. But, I agree, for what we do, business systems, etc, it is possible to know roughly what you are looking for. That made me laugh with the Chrysler project – they used an explorative methodology, XP, to “search” for a solution to… replacce the existing payroll system! Naughty. When you and I did that job a few years ago, we didn’t explore too much because we knew what we were building.

Highsmith’s exploration factor might help with this chat Ben.

All the best, Jim.

“To take this discussion a step further we can consider Jim Highsmith’s exploration factors. Highsmith plots requirements against newness of technology. Bleeding edge technology and erratic requirements have a very high exploration factor. Well known requirements and technology have a low exploration factor. If you have a low exploration factor you can afford to do some up-front requirements analysis and then some up-front design. This will help your product stabalise and allow more reliable performance tests.” Taken from http://www.jamiedobson.co.uk/?q=node/25

I agree with the central point that taking into account end users is often of critical importance in product design (not always, other motivations can be stronger, profit for example), but I think you have missed the point on several of your examples.

The lightbulb: If it required a few minutes, and a screwdriver, to turn the light on and off, I would agree with you, as that is what a light is essentially designed to do (give light, turn on and off). However I disagree that the trade-off between a good looking and stylish light, and taking a few minutes to change a bulb once a year is not worth it. The changing of the bulb is not the primary user requirement. That’s like complaining that a laptop is badly designed as it takes a few minutes, and a screwdriver, to replace a stick of RAM.

Mobile Mail: It may be not be for you, but I think Blackberry etc, and the many millions of crackberry addicts around the world might just disagree with you. I think they did consider the end user and make a good product which is very widely used and becoming a standard. They got quite a jump on other companies who clearly did not consider it feasible enough, which they are clearly regretting, and still playing catch up now. Even Jamie has an iPhone which I am sure he uses for email.

The firewall: I am not sure about this one, as clearly we do not have info from the article, but perhaps the firewall was designed well for what it was written to do. Maybe some clients only want a simple firewall that is either on/off. In which case the error was not with the design, it was with the purchasers at KLM who bought an inappropriate product that was unfit for task.

The data loading application: the way you described it sounds as though the error is due to bad communication between users and developers. If the complaint was that it took too long because they had to keep swapping screens, the solution was correct. However if the complaint was that it took too long as they had to process so many, and they were nearly all the same, as well as having to switch screens, then the developer missed the point.

MS Office: The world’s best and clearly dominant office suite of software, described by you as working perfectly for nearly everybody, is somehow not designed for the end-user?

Cheers,
-Vinnie

With regards to the “clear view”, I admit I took a bit of a shortcut there. But I don’t agree that you can live entireley in the moment either. The explorative process is indeed a valuable one for finding an optimal solution to the problem of the day, but it suffers the weakness of all local search methodologies: start with the wrong initial configuration and even the best local search algorithm will not help you do better than a very localized optimum that is still a far cry from the global optimum.

Some of the best improvements possible to local search algorithms are those that either limit the size of the configuration set, find an initial configuration that is likely to be the starting point of a walk to a global optimum, or both. That implies that taking a broader view a priori and eliminating blatantly wrong options early on is a very valuable tactic.

One of the thoughts that I am mulling over is that it is a question of scale. At the start of a project (what RUP refers to as the inception phase) it is a necessity to consider the feasibility of the project as a whole (specifically by asking if the project idea is realistic and truly of value, which would have severly impacted the project that resulted in that bloody lamp). But it seems to me each new twist and turn in a project (be it inception, an iteration, a new design idea or a refactoring opportunity) can and should be a chance for such a moment and welcomed as one. Any moment a new notion enters the project, I think, is not just a chance for someone to explore possibilities but to embark upon guided exploration.

I have a feeling that there is something like a V-model analogy lurking in the shadows here, but I can’t put my finger on it yet.