In the Agile world we have all heard about how we build in quality up front with each feature developed, how we prioritise fewer features to greater quality rather than building on shaky foundations, the definition of done and a whole host of other mantras by which to ensure we build the right software.

What I want to talk about here is what defines a good user experience and how the concept of quality feeds right into this.  By user, I am referring to any human interaction with a software product, although a lot of the principles apply to clients of APIs (see Developer Experience (DX, link to Ismail’s blog)).

First, let’s define what a good user experience is.  It is divided into two categories:

• How easy it is for the user to accomplish their desired outcome
• How well the application responds and informs the user of the result of their actions

The example we will use is that in stock and options trading where a Market Maker builds an application that allows a Trader to trade futures, stocks and derivates such as options.  This is a good example because not only do Traders need to be able to navigate the application easily to quickly enter orders, but they must also have up to the second prices so they can make decisions based on fresh data regardless on the level of activity in the markets.  Indeed, delayed prices make the application unusable and the Trader will probably leave that Market Maker and go to another one.

The user and their desired outcome

I won’t spend much time on this aspect as it has been covered in literature elsewhere many times before.  Suffice to say that it is primarily driven through good Human Computer Interaction principles applied to the UI, the way the information is laid out specific to the user’s locale and way of working, clarity of information displayed and ease of knowing what to do next to name but a few.  In our case study, the Market Maker builds and makes available an application that needs to make it easy for a Trader to model their trade, preview their order, submit the order, receive confirmation and monitor their positions as prices change

How well the application responds

This aspect is one that has as much, if not greater, importance to a user’s experience.  What we are talking about here is how well the user can achieve their desired outcome while the system experiences a high level of stress, unexpected failures in sub-systems etc.  As a fantastic example, think about the classic market open problem faced by all stock exchanges around the world. For nearly all types of trades, particularly intraday trading and scalping, traders expect a sub second response to their actions regardless of how many orders are going through their application and the exchanges at any one time.  It could be a relatively quite period like a bank holiday when a trader is engaged in out of hours trading with very low volume at one extreme, all the way up to a catastrophic event that results in needing to liquidate positions immediately (think the 2008-2009 market crash).  Traders pay a market maker commissions for each trade so the Market Maker makes money no matter what the outcome of the trade.  The more trades the Market Maker can get through, the more money they make.

Putting it all together

What we have discussed so far is nothing new, however, the key aspect when developing software is having the entire development team and management understand what it takes to develop a feature.  Just because a feature is demonstrable via a UI does not mean it is done.  Far from it, this is just the tip of the iceberg.  The majority of the work remains to make sure that the feature remains as usable with one user as it does with a million (or whatever the SLA is) and functions as expected in the wake of unexpected failures – i.e. is responsive and resilient – as well as other aspects such as security, availability etc.  To achieve this, there are many software engineering principles and architectural techniques (a great one is the Reactive Manifesto) and it is the responsibility of every Product Development team to ensure that when Feature X is Done, that it means it:

• Allows the user to achieve a desired outcome in an intuitive manner
• Remains responsive to the user even in the event of a failure in one or more subsystems
• Communicates to the user if an action cannot result in the desired outcome in a clear manner
• Has had other recommended practices applied, e.g. implementing good security procedures to ensure that sensitive data is not compromised

Most of the work for a Product Development team is in the second category of how an application responds under different scenarios. Get this right and additional features will be able to leverage that investment, create a much better product for users and bring in more revenue even when there is a huge surge in activity.  When an application remains responsive and informative, users achieve what they want resulting in higher customer satisfaction, and the company makes more money.  A win-win!