Is it better to build a powerful, flexible product with lots of capability? Or is it better to build a simple product which can be used to its fullest potential by most of your users? This is a tough decision. I have not seen it said any better than this.
According to Are your users stuck in “P” mode? we have to keep asking ourselves:
- Are we focusing too much on the tool rather than the thing our users are trying to do with the tool
- Is the product just too damn hard to use even if a user does know what they want to do with it?
- Do we encourage/support a user community that emphasizes mastery of the thing the tool is for?
- Do we train our users to become better at the thing they use the tool for, in a way that helps make the need for all those other features seem obvious?
It is a great read. I definitely recommend it. The scope question is a difficult one.
1. There are rarely any clear profile of the user for software. As Matt mentioned in WordCamp2006, “Software has no single killer feature. There are hudreds or thousands of them and each user has his own set of 10 or 20″
2. Even if you start with a version of the software that is like the picture on the right above, over a period of time you tend to have a large circle (feature list) with several smaller overlapping purple circles. Each purple circle represents the needs of a single class of user.
3. We know that products get more complex before they get simple. Take Microsoft Word for example. After adding features over 5+ versions, the product team did something very different in the latest version. The simply made the access to features better. Someone mentioned in one of the Professional Developer Conference that this was because there were users asking for features that already existed in the product.
4. I think there are a spectrum of users from a casual user to a professional/expert. Their needs vary. There is enough overlap across these users/needs to make a product that looks like the figure on the left with a twist. Instead of one little purple circle, there will be many.
For example, our product InfoMinder’s use varies. About 80% of the users use about 20% of its capabilities. But there are a few, probably less than 5% that use most of the features.
What is your experience, working with products and/or building them?
I haven’t read it yet but it sounds just like many of my experiences.
Comment by Cliff — August 22, 2006 @ 6:44 am
Cliff,
Thank for the comments. Would you like to share your experience here? Or blog about it somewhere and point us to your blog?
Comment by dorai — August 23, 2006 @ 10:49 pm
[...] Regarding the topic stuck in “P” mode, I forgot I posted a comment on another blog here. Yes, it is an interesting article worht reading. In my experience I’ve worked on several different applications where the “tool” was prioritized over the user. Take my prior job for instance. I recall many meetings with developers instructing customer service support with sentences that begin with “alls yuh haff tuh do is…” …I hate that sentence! It’s the prefix of an incoherent explanation that defines a complicated program model that falls nowhere in the ballpark of the typical user model. User models tend to be simple. Many of us developers tend to add complexity to these simple models to justify the misdirection of our development practices. A simple user model could be something like, “I need to print customer addresses for shipping labels.” A typical misdirected developer extrapolation would begin with the muddy details of existing (bad) code that prevents access to access to the address for customers outside of the context of an opened order. Rather than focusing on the need of the user focus is placed on adding features to (read poking holes in) the “tool” to support printing shipping addresses. Complication is added through the introduction of a feature that allows an order to be quasi-opened or pretend-opened. The feature complicates other order processing done in the warehouse as people wanting to close orders get locked out due to the pretend-opened order on the other workstation on the other side of the warehouse where a missing shipping label needed to be reprinted. That creates the need for another made up “feature” that allows users to close orders that are opened elsewhere. Now you have “close” and “force-close” options in order processing and a need to explain the difference. The sentence structure you choose will no doubt start with, “alls yuh haff tuh do is…” [...]
Pingback by Alls yuh haff to do « Can’t see nothing but the source code — November 14, 2006 @ 7:34 am