Updated on by Daniel Twigg
Creating great experiences for your customers has always been the goal of SaaS product managers and designers. Therefore, why should it be any different for their data? Having a firm understanding of how your users navigate your website or app is key to designing a great experience.
So, which approach should development teams take when designing data flows inside your app? 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 the common usage of a system looks like. This can be broken down into 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. Then you’ll achieve your aim of improving engagement, usability and sentiment.
There are several methods you can use to begin creating user journeys, including:
- 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. As a result, you’ll get a first-hand look at what is working and what isn’t.
- User Interviews – chatting with users provides an opportunity to ask them directly about what they like/dislike about the product. At this point, you can also set them minor tasks to complete. This is so you can watch how they navigate the application to complete the task.
- Analytics – Google Analytics gives you enough data points to be able to see what pages and screens are being used. As well as those that are not. By combining this with established goals and funnels and you should be armed with enough data to see what is working and what isn’t.
Ultimately investigation is key. Then taking these findings and using them to create a more engaging, user-friendly experience should always be the end goal.
What are Data Journeys?
Similarly to a user journey goal, a data journey should be aimed to give you a better understanding of how, and what, data flows through your app. This could be from either user-triggered actions (running an integration for example) or from operational background processes.
Therefore examining internal and external data movements you can iterate your data designs with the goals in mind being:
- Firstly, remove unnecessary hops data has to pass through from process trigger to completion. This means 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.
- Next, 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 DPOs across the world, where only relevant and necessary data to perform your core operations is collected and processed.
- Finally, remove data redundancy and save 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 on to then evaluate the fields being transported. Listing out the data points is the first step to data minimisation, with each field forcing you to ask if:
- Are they fully optimised?
- Are they actually useful to users?
- Are they necessary for 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. As you’ll be able to see how each API method is connected to another. As well as its function and accessible fields, therefore you’ll be able 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.
