User eXperience (UX) mock-ups are wisely used to drive the complex process of defining what a software product will do, from the perspective of its users: How it will look to them, how they will engage with it, and how they will use it to solve whatever problem / gap the product is intended to fill.
“Surely that’s ok, and data issues will all be sorted out when the UI is built and integrated with a backend / API?”
Well, often but not always.
Usually, an informal idea of the data available is used during UX activities. This can be a good and speedy starting point. It is also sometimes a lucky match for the data that’s actually going to be available.
But I’ve seen the following UX:data mismatches, sometimes discovered very late in the product build cycle:
- Need to CONVERT (data available, but needs conversion / mangling) : The data may need conversion into another form. This is usually achievable, but it’s good to surface this reality as early in the product build cycle as possible so that the conversion can be built.
- Need to UNITE (data available, but as fragments and needs uniting) : If multiple sources of data are being used, perhaps the UX requires them to be integrated to form a seamless experience.
As for data conversion, this is often possible but occasionally needs some ingenious process to be derived in order to do that. Occasionally, it is too computationally difficult to unite the data sources, or heavy computation (perhaps even Machine Learning) would be required. This is usually the case if a human could informally unite the data sources, but it is hard to define how to capture that fuzzy / imprecise ability in code.
Again, it’s better to discover what could potentially block product development as early as possible, and either plan to build it or change the UX.
- Need to RE-THINK (data partly or wholly not available / not achievable) : There really isn’t much you can do in this scenario, apart from attempting to source new data or going back and modifying the UX to match data realities.
The Role of Data Validation?
The simplest way to prevent the above, and the product delays it causes, is to annotate UX proposals with the data sources required and, preferably, with real examples of the data to be used.
This focusses the more visual / interactive UX activity to align occasionally with engineers who know the data sources in-depth — either existing or proposed — and to figure out whether the UX is going to be achievable, whether additional development work is required, or whether the UX needs re-thinking due to lack of data or ability to get it in the right form.
UX may largely be about proposals that feed into engineering and other areas, but the ability to realise those proposals as working software hinges on many factors, of which data availability is just one.
Some would claim that trying to unite an early activity (UX) with something that comes later (data sources) smells way too much like Big Design Up-Front (BDUF) and isn’t very “agile”, but I’d disagree. If our ability to make use of the UX proposal — to turn it into working software — revolves around the ability to get the data it surfaces, then validating the UX against data sources is simply ensuring the end goal is achievable. It doesn’t pin engineers down in terms of how they’ll achieve the data required, but simply raises awareness and validates what is required.
Zooming In, Zooming Out
For me, this UX and data alignment exercise is another example of something I’ve found to be useful in software development in general: We all get so focussed on our particular specialisation (zoomed in) that we forget occasionally to see how we’re doing in a broader context (zooming out), which includes multiple people, teams, disciplines and a wider context.
Regular, brief exercises summarising what the whole product will be when it is built, and how we’re doing in our efforts to get there, can head off many misalignment problems early. It also increases cross-team / cross-discipline awareness of the product as a whole, and our plans to build it… which is never a bad thing.
I see UX and data as two aspects of a whole product that need to work seamlessly together. So let’s validate that they do, from time to time.