Application usability is the oldest form of technology usability discipline. In a lot of our usability pieces, and those of others, though, this is often only alluded to, with more emphasis on website and non-application service interfaces and mechanics. This is largely due to the big boom of SaaS and diverse-application web technologies in general.
With the complexity of modern web technologies, and the inherent cross-platform nature of this sort of technology, a lot of services and tools are migrating to this platform to get around hindrances to practicality brought on by physical copy and being local platform native. So, a lot of UX stuff is going to only allude to application usability, which is unfortunate.
Well, applications are not going to go away, or at least the discipline behind them and the presentation model inherent to them most certainly isn’t. An application is just a program. Terms like “app”, “application”, “binary” and “executable” are all the same thing, and that’s a mostly self-contained file with procedural instructions. SaaS that intends to be an interactive, multi-faceted tool is still going to usually work like an app, even if the actual execution and residence are elsewhere. The presentation and logic of the app concept just … work for this. So, if you follow this model, and are fulfilling the same purpose, then usability for app design still applies, SaaS or not!
#1 – Choose your Test Subjects Wisely
Ok, I’m not going to go on about demographics and cross sectioning here, because you know about all that stuff already, and it’s been hammered into the ground. I mean something a bit different by this, that’s very uniquely app testing.
Your design is going to follow, to some level, a navigation, layout and logic basis that is accepted by a wide range of existing designs. This is logical, because it makes it easier to pick up by users, and it makes the design faster to work out.
It also, though, means that you have a good factor for your test groups, that being regular users of competition, or users of applications of a different nature that have similar UI and UX conventions to what you’re using.
When you’re testing an application, the underlying purpose and mechanics of the tool are only a third of the overall stuff under scrutiny. Another big one is going to be this human interaction layer.
#2 – Variant Usage Rates
Variant usage rates means trying different things in possible order combinations at different frequencies. This tests different levels of skill or uncertainty within usable margins, and how stable the interface is at responding to this.
#3 – Error Handling
Error handling is a major thing with application design that other services deal with less (aside from the likes of PHP). Testing to be sure that all possible severe issues are handled, especially in a managed environment is crucial. Things like “unhandled exception” are not really acceptable beyond a one in a million shot.
Application usability is more rigorous in testing, but it’s less of a soft science like other services which are more about user journeys and other quasi-modern models for interaction. Not that there’s anything wrong with those, but this does mean that app usability is easier to work on!
