Data Journeys: Treating Data Like Your Users

Updated on 10th February 2021 by Daniel Twigg

Creating great experiences for your customers has always been the goal of SaaS product managers and designers, so why should it be any different for their data?

Having a firm understanding of how your users navigate your website or application is key to designing a great experience for them as they use your service.

But what approach should development teams take when designing data flows inside your application or in integrations with third-party SaaS applications?

What Are User Journeys?

User journeys are a method of mapping out a system’s users usage of your application or website. The goal is to understand what common usage of a system looks like, breaking down common navigation patterns in order to see what is working and what isn’t.

With that in mind you can develop improvements to UI and functionality to enhance the overall user experience, with the aim of improving engagement, usability and sentiment.

There are several methods you can use to begin creating user journeys, including:

1. Visitor Recording toolkit – Software like Hotjar allows you to record user sessions of your website or application. This lets you watch and analyse what your users are doing from session to session, so you get a first-hand look at what is working and what isn’t.
2. User Interviews – sitting down (physically or via video call) with your users gives you an opportunity to ask them directly about what they like and dislike about your product. You can even set them minor tasks to complete so you can watch how they navigate the application to complete the task.
3. Analytics – even Google Analytics gives you enough data points to be able to see what pages and screens are being used, or, in some cases not. Combining this with well set out goals and funnels and you should be armed with enough data to see what is working and what isn’t.

Investigation is key, but taking what you have discovered and using it to create a more engaging, user friendly experience should always be the end goal.

So What is a Data Journey?

Much like the goal of a user journey, a data journey should be aimed to give you a better understanding of how, and what, data flows through your application. This could be from either user triggered actions (running an integration for example) or from operational background processes. 

By examining internal and external data movements you can iterate your data designs with the goals in mind being:

1. Remove unnecessary hops data has to pass through from process trigger to completion – mapping out where data is being requested from with the aim of minimising the number of API calls or processes required to run an operation. 
2. Limit the amount of data being moved or manipulated to only what’s necessary – in a post-GDPR world we all need to be minded as to what data we are dealing with. Data minimisation becomes a key mantra of DPO’s across the world, where only relevant and necessary data to perform your core operations is collected and processed. 
3. Removing data redundancy – saving database space

Mapping Your Data 

The first step to fully understanding your data movements is by whiteboarding your system. Starting with broad strokes, you’ll want to see how recordsets interact with each other, as well as listing where in the application they are accessible to users. 

Drawing out common flows of data allows you to focus in to then evaluate the fields being transported. Listing out the data points is the first step to data minimisation, with each field forcing yourself to ask if:

• Are they full optimised? 
• Are they actually useful to users?
• Are they necessary to regular operation? 
• Do they slow down processes?

How can I Map my Data?

Aside from reworking your architecture (eek!) a solid starting point would be looking at how your application interacts with external sources. 

This is where a visual integration toolkit becomes a huge benefit.

Being able to see how each API method is connected to another, combined with its function and accessible fields allows you to take stock and look for how to make improvements.

Any iterations you make are performed outside of your core architecture, so you can avoid lengthy deployment schedules.