CASE STUDY
Redesigning a digital footprint search tool to enhance engagement
My role
Team
Timeline
2023 - 2024
Challenge
This digital footprint search app was originally developed without user research, resulting in a complex and unfocused design that led to low engagement. Users struggled to understand its purpose and how it could benefit them. Over several months, I led a redesign with support from my colleague, redesigned the product, simplifying it to focus on its core function: helping users trace people's online presence more effectively.
Impact
Streamlined the product's focus to prioritise the search functionality.
Reduced need for training
Improved navigation consistency across the app for a smoother user journey.
Reduced steps required to start a search
What is it?
A search tool for personally identifiable information, providing details like addresses, phone numbers, employers, IP addresses, and financial data. Users can search by name, phone number, social media account, address, or email to gather relevant information.
Who is it for?
UK Law Enforcement
Military
Government bodies, incl. counter-terrorism units and vetting teams
Private security agencies
Financial regulatory bodies
HOW IS IT DIFFERENT?
Unlike traditional OSINT tools, this product lets users select multiple data sources for a search, eliminating the need to manually check multiple platforms.
Solution
The redesign streamlined the interface by removing unnecessary features and prioritising core search functionality. For example, users now land on a clean, intuitive search page where they can quickly select data sources and search criteria, guided by clear instructions. This creates a more focused, efficient experience, helping users make decisions faster.
Toggle between the before and after version by dragging the icon in the centre
Why the redesign?
The redesign was driven by two main factors:
Competitor’s FRUSTRATING REDESIGN
Our biggest competitor redesigned their product, frustrating many users. This gave us a chance to win them over with better solution
The current version of the product had minimal engagement, despite a clear need from users for a product like this one
Delivering a UX redesign in a team without prior UX processes
The redesign took over a year, slowed by shifting priorities and a lack of UX processes or clarity on the UX role. Integrating UX was a cultural shift that took time, but it set the foundation for a clear product vision and a successful redesign.
PHASE 1
Remove uneeded features
Re-arrange page using existing features
PHASE 2
Update design system
Usability testing
Add new data source
PHASE 3
Redesign each page
Usability testing
Understanding the users
How do they work?
They simultaneously use multiple similar tools to compare results and verify their findings.
They continuously scan large amounts of data for their investigations.
Findings are documented with their own traceable methodologies, so evidence can be traced back to its source for legal validation.
Need to drill deeper into discovered information, such as identifying all individuals linked to an address.
Simplified user's work flow
User pain points
User research uncovered these key pain points:
DISCOURAGING FIRST STEP
Users don’t understand why they need to create a project before searching, causing many to abandon the process before they even begin.
OVERWHELMED BY COMPLEXITY
Users are confused by the multitude of features and just want to perform a search.
can't reuse search
Cumbersome process to reuse the search results, making it hard to refine and build on previous findings
Tracking past searches is inefficient, and rerunning them isn't possible.
CONFUSING NAVIGATION
Users struggle to navigate the footer, making it hard to find their way around.
Additionally, the redesign was done with some constraints…
Design system lacked refinement and consistency, with only black and blue as primary colours and overstylised key components that added visual clutter.
Emotionally invested stakeholders
Developers were reluctant to remove code they had invested time in, while former users, now stakeholders, and product owners wanted minimal changes, hindering necessary updates.
I was just starting my UX journey, and while my colleague was knowledgeable, they lacked hands-on experience. With no established UX culture, our approach lacked focus, and the team's efforts were often misaligned, which slowed down the process.
Taking this into account, the redesign had 1 goal and 4 objectives…
GOAL:
Redesign the product with a strong focus on search functionality, ensuring scalability for future features. Prioritise accessibility, simplicity, and flexibility while enabling users to reuse discovered data and document their search process. This will create a more engaging tool that meets user needs and remains competitive in the market.
Feature overload: users just want to search
The user flow of the product before the redesign was convoluted, had a high barrier entry and was offering more features than the users needed, the users were confused as to how they werre expected to use the product.
One of the objectives was to clean up the product of the all the features that the users confirmed they didn't need and simplify the user flow.
WHY WE DON'T NEED THESE FEATURES:
Mandatory project creation
High-entry barrier, causing drop-offs. Users don’t understand the purpose or benefit of creating a project, delaying access to search.
Profile builder
Users document findings using their own traceable methodologies, making this feature redundant.
Marking results
The system prompts users to classify results (‘Likely’ or ‘NFA’), but research confirmed users rely on their own methods to track relevant information.
Activity log
Originally designed for evidential tracking, but most users either didn't realise it existed or found it too complex to use, resulting in low adoption.
A simpler flow that meets users' needs
The updated design removes unnecessary steps and features, focusing on what users truly need: quick access to search and a simple way to edit and track their search.
Start with search
Users now land directly on the search page, just like other search tools. Open the app, start searching—no extra steps.
Fine-tune the search
Users can now refine their search criteria on the fly, making it easier to adjust and interact with results.
Challenges: navigating stakeholders demands
Some stakeholders wanted to keep features they believed would benefit users, despite no supporting evidence from user research. One example was the "mark results" functionality.
What user research said
Usability testing showed users were confused by the "mark results" UI, feeling prompted to take action when it was optional.
Most users also confirmed they wouldn't need this feature.
What stakeholders wanted
Some stakeholders, particularly former police investigators who had used the functionality in their cases, insisted on retaining the feature.
The compromise
The "mark results" feature was hidden behind an Edit button, maintaining access without disrupting the user flow.
Next step
With a simplified user flow in place, the remaining pages now need to be redesigned to support easier decision-making during search creation and ensure the results are more actionable.
Cleaner Search page, now the Landing page
By streamlining the user flow, I turned the search page, once hidden under multiple steps, into the landing page, giving users instant access to core functionality. The final design evolved through several redesign phases, outlined below.
1st redesign phase – Quick, not pretty, but usability testing-ready
To validate the approach for streamlining the application while still negotiating with developers and stakeholders, the first iteration was fast-tracked using existing page elements and removing unnecessary features.
The result? A simplified design, though still rough around the edges. This 'in-between' version was implemented quickly, allowing to jump into the first round of usability testing and gather valuable insights.
Quick revamping for usability testing before full redesign
Final version: user tested, refined, and built for clarity
The landing page is now more focused, clearly guiding users toward the expected action with a strong emphasis on search. My colleague created the layout design, while I contributed by simplifying the list of sources users can select from, ensuring it aligns with the simplified flow and style.
Updated design
While my colleague led the majority of the design work on this page, I worked closely with them to define the vision for a simplified layout that was coherent across the application.
My contribution
As I tested the search history, users confirmed that they needed to see the list of sources used for the search history. I added the sources to the Search history page but to make sure of the consistency of the design I designed that section of the page.
Next step
As the redesign rolls out and we test new versions, we're uncovering more about users and their needs. One key finding: while users didn’t want or understand the activity log, they still wanted a way to track their search history.
Search history replaces the activity Log
Usability testing revealed that users didn’t need the activity log but benefited from a simpler search history feature that let them view and re-run past searches as part of their investigative process. While the activity log tracked every action users took, the search history focused only on the search criteria and sources used.
Here a few iterations followed by the final version of the design.
Activity log before revamp
1st iteration - Validate content before finalising the design
For usability testing, I kept the table design minimal rather than polished, as there were no tables in the design system and my focus was on understanding what information users needed and what actions they wanted to perform.
User feedback: Users didn’t need the result count but wanted the option to re-run searches.
2nd iteration - Improved layout, but refinements needed for clarity and accessibility
After usability testing, I quickly landed on this design, but a few issues remained:
VISUAL INTEREST
Accessibility issues
Table headers are needed for clarity and accessibility, especially for screen reader users.
Cognitive load
Stating that results expire in 30 days adds unnecessary cognitive load—users should simply be informed when a result is about to expire.
Final version
Next step
During the redesign, a new key data source was quickly integrated, as it had the potential to differentiate the product in the market. However, as more was learned about the data structure, it became clear that the design would need to be completely updated to accommodate it.
Unique design, unique data source
The new data source provided detailed personal information, such as birthdates, phone numbers, emails, address history, employment records, income, loans, and IP addresses linked to individuals. Its standout feature was the ability to drill down into any data point to reveal people associated with it. Given its capabilities, a distinctive design was essential to help users easily recognise when they were exploring this data source.
Example of drilling flow
Quickly implemented design for usability testing, with limited view of data structure
The initial design was developed quickly to showcase the new data source to users and assess its potential. The design was influenced by limited understanding of the data structure, caused by challenges in communication with the data provider.
Original design
WHY THE CURRENT DESIGN ISN'T WORKING:
Too much eye movement for efficient scanning
User research shows that users prefer scanning data in a table format, allowing them to process large amounts of data in a single row and avoid excessive eye movement.
When a column is too long, key data falls out of view.
Each column contains an unpredictable amount of data. If one column is too long, the remaining columns shift out of view. Users may not realise they need to scroll or may have to scroll extensively to find key information
Use the scroll to see the data outside the viewport
Step 1 - Figure out the page layout
Based on the user feedback, adopting a table format seemed the most obvious choice, but with each category displaying varying data types and amounts, I needed to figure out how to organise the screen first. Then I experimented with arranging the tables in blocks across the page, using a large dataset as a realistic reference to shape the layout.
Below are a few iterations, followed by the final selected design.
1st iteration
To start, I attempted to arrange tables side by side, placing the smallest ones next to larger ones to maximise space.
Rejected: Too much wasted space and limited scalability
2nd iteration
In the second iteration, I added contextual data, such as the first time the data was collected and how often it was found, below the main data to provide more context.
Rejected: Cumbersome layout and hard to scan efficiently.
Adopted page layout
This page layout was adopted, allowing each category to span the full length of the page for better visibility. Only tables with data would be displayed, ensuring the overall design remain consistent regardless of the amount of data available. Each set of information is displayed in a single row, with the option to add more columns if needed.
Final page layout before refining the design of each element of the page
Step 2 - Refine the design of the tables
With the layout figured out, I focused on refining the remaining aspects of the page design. This included emphasising key information at the top, adding visual interest, and organising the data within the tables for better clarity.
Next, I'll show the iterations leading to the final adopted design for the tables.
1st iteration
I focused on arranging the content within each table and planned to refine the headers once the content was sorted. I aimed to allow more space for the main data, which could vary in length, while keeping the other columns consistent.
Refinements needed: Inconsistent column sizes impact readability, and the underlined hyperlinks create a cluttered look.
2nd iteration
In this iteration, I maintained consistent spacing between columns across all tables and moved some data from rows into a column to improve readability and keep row heights consistent. I also extended row lines across the screen to balance the design and maintain consistency across tables.
Refinements needed: Table headers need clearer styling.
Adopted table design
Adopted: Clearer column and table headers, simplified alignment and wording for readability.
Final page version
In the final version, accent colours were added to the page header, table headers were made more visually balanced, and the data, previously spread across multiple rows, is now integrated into the columns for better visual consistency.
Distinct design
A tailored design for a unique data source, enabling users to interact and drill into it without confusion about the source.
Accent colour introduced
An accent colour was added to help users quickly distinguish the data source, complementing the design system's limited blue and black palette.
Balanced design
The page format aligns with the rest of the product, with consistent navigation. One-third of the page shows contextual info, while the rest displays the results.
Distinct icons to quickly identify what data is on the page and add visual interest
Icons in the page header represent different data types, such as address, phone number, IP address, related person, etc.
Person
Mobile
Location
Landline
Ip address
Breadcrumb navigation for easy journey tracking
A breadcrumb feature was added at the top of the page to help users track their progress and easily navigate their journey throughout the search.
Basic breadcrumb structure
Drop down menu
The breadcrumb dropdown menu holds up to 10 values, replacing the oldest with the most recent if exceeded. Though an unlikely scenario, a design solution was needed to maintain the size limit.
Drop down shows when more than 3 items in the breadcrumb
Making the breadcrumb rules crystal clear to stakeholders using illustrations
I explained the breadcrumb rules to the developers, testers, and various stakeholders by using a set of scenarios that users could encounter, illustrating how the breadcrumb would function in each case. To support this, I created images for each page of the app to help visualise the scenarios and demonstrate how the breadcrumb would work.
Breadcrumb rule - Scenario 1 out of 8
I wrote and reviewed the user story and acceptance criteria for the breadcrumb with the developers. However, since the rules were a bit complex I used these illustrated scenarios to clarify details and confirm assumptions whenever needed.
Unfortunately, the project was cancelled shortly as the last piece of the updated design was implemented. But here is what I would have done given more time.
Make the design even more engaging
There's plenty of opportunity to make the design more engaging and dynamic—it still feels a bit too cold. While the focus was on streamlining for functionality, the original design system was quite limited, which left room for improvement.
More user testing!
I would have liked to conduct a full usability test on the entire product after delivering the final version. The latest usability test revealed that users needed more contextual information to fully understand the data provided.
Reduced need for training
Previously, the product required extensive training due to its complexity. With the redesign, users can now open the app and start using it immediately. The simplified interface and clearer navigation make it intuitive, allowing users to quickly grasp its functionality without prior instruction.
Quotes from users
"This is so much better!"
"New layout is so much easier to read and scan!"
"A real improvement from the clunky layout"
"Drilling into the data is a game changer"
Missing person found
Customer support informed the team that the product was used in a missing person case and played a crucial role in helping locate the individual.
Identifying key details in national security cases
It was also reported that the product was used to identify addresses and associates of a person of interest in a national security case.
What I'd change
At the beginning, my limited UX knowledge led me to rush the redesign under stakeholder pressure, skipping essential user research. As I gathered more evidence, the process became much faster and smoother, teaching me the value of starting with research.
What I learned
Plan for scalability
As we simplified the app, it became clear that building a strong design foundation was crucial—not only for the current iteration but also to support future changes and challenges.
Simplicity beats aesthetic
For serious work, efficiency trumps aesthetics. I thought the limited design system would be a hurdle, but once key components were adjusted, consistency was all that mattered.