Great software is a function of how “able” it is across a range of areas, from usable, to scalable to supportable and even sellable. I think a lot of these areas get missed by product managers and developers. Having been on the vendor and customer side of software, I’m developing these categories into a rubric to determine what I’ll buy, from whom, and then perhaps what I’ll have to build instead.
Here’s a list I’m currently working on; and will expand each area and refine this list over time… The list is only as good as the feedback I get on it, so please let me know your thoughts.
- Accessible – How clean is your DOM (document object model) – does your product render well in screen readers, have patterns for color-blind users, and tag elements effectively?
- Actionable – Are the error messages you give to users things they can actually do anything with? See Understandable below also.
- Available – As in HIGHLY. You used to call this multiple 9’s, but now the standard is closer to 100%, with a client that is smart enough to advise you. Although we all seem to forgive if you’re hosted on Amazon (because half of the internet goes down when AWS is down).
- Auditable – Is every change a user makes logged? So you can immediately audit any record or data changes? Is activity tracked by user, or according to some generic user account?
- Billable – Does your software create billing headaches for your company? Is the absence of a License Key or similar something that causes the sales department to sell whatever they want, in whatever configuration they want? Simplify your billing, or suffer the consequences.
- Demonstrable – How easy is it to set up a demo environment? Is there clean sample data? Does each sales person have a nice script? Can they reset the progress at the end of it? Can they show a client-specific experience.
- Deprecatable – If you want to deprecate a part of your environment, do you have the ability to know exactly who (or what) is using the part that you want to deprecate? Can you have a controlled process for retiring something? Or do you turn it off and see what breaks?
- Diagnosable – Can you figure out reasonably quickly what’s going wrong?
- Installable – If you are pursuing an HA strategy, how quickly can you light up another data center or node? And if you have a client who refuses to use the cloud, can you make a version that they can install (putting aside the business decision around whether or not you should be pursuing a mixed model anyway). It’s also a question of setting up a development environment. See replicable below.
- Internationalizable – I totally don’t know if this is a word, but you get the idea. What’s the effort on supporting your next language, and then the next 20, and next 50. Can you go right-to-left. Any easy unicode test is to use uʍop-ǝpısdn text in all of your test scripts.
- Maintainable – Another broad category, and may say more about the culture of your organization; do you encourage people to go in and clean up (refactor) old code, to keep it maintainable, or is everything just layered on top of each other.
- Migratable – Lets say you wanted to migrate all of your users from one installation to another (e.g. changing data centers). Can you migrate your data easily? Can you move it between environments (Prod -> Test -> Dev, etc.)
- Localizable – See Internationalizable above, but this is actually harder, because it means if you have any dates or numbers, you have to make sure you are treating them as dates and numbers in your code, and not just text strings.
- Loggable – Related to diagnosable, and maybe traceable or even auditable, but what and how much do you log? There’s two levels of this: user-activity (in auditable, above), and code logging, so you know what’s happening, where and when. And when something happens, you can look back in the logs and see what went wrong. You should think about getting fancy by using some advanced logging platform that can learn things (e.g. sumologic)
- Recallable (aka Revokable) – Can you pull it back from an app store deployment, or force an upgrade/downgrade? What control do you have if you find a bug and need to push a different version? Or are you beholden to supporting multiple versions? We’ve gotten lazy as an industry because we used to just update the web site, but now we’re back to client-server with our mobile apps.
- Replicable – As part of your High Availability strategy, or otherwise, can you replicate your environment somewhere else? See also Migratable
- Sellable – Can you sell this product in a way that makes sense to people? How about each and every feature? Some of course are hidden features, but is what you are building even explainable?
- Scalable – This is an ongoing challenge. How you build your MVP (minimum viable product) is different than how you build a version for 10,000 users which is different than for 1,000,000 users, but you should testing and scheduling the implementation of your next version and architecting the one afterwards.
- Shareable – Are you comfortable showing everything to a wide audience? How did you choose your artwork
- Skin-able – Can you easily change the skin or theme to your software? Or even allow yourself to be white-labeled and sold as part of another system.
- Style-able – Like skinnable, but more fidelity over the fonts and layout of your system.
- Supportable – This is a very broad subject, but imagine you have somebody taking a phone call to help a user with your system. Can they see the user’s state? Can they log in as the user (of course without their password). Can they see the users screen? Can they diagnose login issues or anything else? Let’s say the user is behind a firewall and you can’t access their machine at all, what can you tell about what’s happening. How can you reset things? A whole series of administrative tools or views may have to be built, or you can think about this as you are building your application and dare I say try to make things supportable too.
- Testable – Another broad subject, but is your testing automated or manual? What do you have to do to make it more easily tested? Do you even know how to use some of the testing frameworks out there, and what your code needs to look like to make it easily tested. How is your unicode support tested. An easy option is to use upside-down text (see above).
- Translatable – See internationalizable above. The simplest thing here is if all of your text strings are in a single file so you can easily ship them off to get translated.
- Understandable – Is what you are explaining to users something that is appropriate for them? Is the feedback useful, actionable, meaningful, and otherwise something helps their experience?
- Usability – The holy grail of application development. It almost sums it all up. Is the UI clean and easy to understand? Can you find things? Is there monotony in getting anything done? How much usability testing have you actually done, by the way?
I’ll work on expanding and refining each of the above (with their own articles) until I come up with a concise list, but I wanted to at least get some initial thoughts out…
Pingback: Is the feedback you give to users understandable? ← David Pinkus