A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
What do you people suggest? While developing a new product (v 1.0), should I concentrate more on features OR easy-of-use? What about a product with a small set of CORE features but an easy-to-use interface?
Sunday, September 19, 2004
Smaller feature set. Easier to use. Expand on features later, but make all that stuff "advanced" so you don't clutter the UI.
Put another way: Start with the smallest possible thing that will work.
Example: The Rename (feature filled, impossible to use) vs. Oscar's Renamer (less feature filled, but amazingly easy to use).
Monday, September 20, 2004
Something many have noticed... successful software often starts out simple, then as the userbase grows more sophisticated it aims for features at the price of new-user usability.
Your name makes me think of Python in this category. Which I think can become a major problem for Python.
Tayssir John Gabbour
Monday, September 20, 2004
In my experience, successful software has the following (in order of decreasing importance):
Good interface (includes flashiness and ease of use)
Users appear to care most about something being very easy to use and are easily wowed by flashy colors and graphics. Next is performance. Users are impatient and will move on to something else if response time is not good enough. Finally, features. A lot of apps are incredibly feature-rich but with an impossible UI; the users would have preferred less features and a better interface.
Note that I'm referring to general business applications, not "power-user" apps or programming tools. That's a totally different market and mindset.
Tuesday, September 21, 2004
Core features, then ease of use.
But most important is getting it out the door; many projects die before they're ever shipped because the developer tries to put too much in Version 1.0.
Wednesday, September 22, 2004
One thing to keep in mind is that ease-of-use comes in large part from a good conceptual model, and a user interface that fits with that model. So by properly picking the features, ease-of-use will often follow. Or to flip it around, the wrong set of features will never make a product easy to use.
Many business systems are designed around the individual tables, and give the traditional CRUD operations on each table. These are database operations are treated as "features." However, this doesn't match the users' concept of a business operation. For example, an airline reservation system that cannot rebook a passenger on a different flight or seat, but makes a clerk delete one booking and create an entirely new booking is never going to be easy to use. It just doesn't fit.
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz