What do YOU think is important in a product? At BMC, we spend a lot of time thinking about how to make the best possible products, and that includes measuring how well we are doing and I want to make sure we consider more than just the things that are the easiest to measure such as defects - a product clearly needs attributes other than "Not full of bugs" to be a quality one!
I personally think that if you are an END USER, the following 6 attributes are what makes a quality product, ordered from the critical to the merely very important:
- It fulfils its purpose: clearly the most important; if the product does not help you do your work, it doesn’t fulfil its purpose and it doesn’t matter how polished, slick or fast it is. This is where I think it all starts.
- The UI is intuitive. It should be fairly obvious what will happen when you click a button or a link, and where you should go from there. It should be “cheap” to experiment with unknown links or functions - "undo" is an important to encourage risk-free experimenting.
- It does not do the wrong thing. Bugs, defects, crashes, hangs: clearly bad.
- It is responsive. If the UI doesn’t react fast or give constant feedback, you get frustrated with it.
- It is easy to get unstuck. Good, accessible and searchable documentation, training and a thriving, responsive community are key.
- It looks polished. The product has a “pleasant” look and feel, with consistent and polished UIs. If you use multiple products in a workflow, there should be no jarring differences in how they look or feel.
If conversely you are the guy that ADMINISTERS the product, some very different quality criteria apply:
- Fast and reliable install and upgrades. Being able to benefit from the latest features as well as defect fixes must not be a chore.
- Enterprise ready. It’s no good if the product doesn’t fit with your corporate authentication structure, doesn’t integrate with standard systems and protocols, or doesn’t support your global, distributed enterprise setup.
- Easy to troubleshoot. If something goes wrong, it needs to be easy to find out what it is and get it fixed. If you have to look at log files, they should be easy to sift through – but looking at log files really should be an exception rather than the rule.
- Easy to configure. Setting up the product so it meets your users’ particular needs should not require a degree in troubleshooting 8 variants of XML. It should not give you unnecessary choices either; just make the product work really well with well-chosen defaults.
- No security issues. You really don’t want to know what the guys over in Information Security does to people that introduce products that put the business at risk.
- Easy on resources. Products that need morethan their fair share of scarce compute resources are expensive to run anddeploy; I need them to be lightweight.
Do you agree? What do you think is missing? What metrics do you think are appropriate for measuring whether the products you use are quality or not?
I’d love to hear your thoughts - please comment below.