Search Architecture - I'm Strategic, People Curious, and I get Things Done

Goal

To create a robust global search and advanced query tool in a highly customizable app that houses an immense data set of complex data relationships.

My Role

UX Strategist & Design Lead

Problem

This app houses a quagmire of data. May objects of different types had the same user-facing names, so context and data relationships had to be expressed in the search. Most end0users I spoke to were presently unable to search or run reports independently at all. Most had IT teams set up a query to create wordlists or reports. But even basic changes to these could take days if not weeks to get implemented by their IT teams. Meaning, users who needed to find something that was a one-off, were out of luck.

Solution

A smart and user friendly search that empowered users to type in global search terms and set up simple queries by user friendly field names. Users knew they needed record numbers, names, types, people, and were more able naturally search for these in terms they understood and the system design and search logic became “smart” enough to respond to them in-context.

From Problem to Solution Step-by-step

Starting Line

I started with the knowledge that users could not get their data. This had mostly this had been framed to me as a problem managing tasks during the records processing workflow workers at municipal government agencies were a part of.

Just before I took charge of the UX strategy for this team, a previous UI design group had released a redesigned dashboard (shown in the right).

It featured a more visually appealing interface than what users had interacted with prior. It featured a drop-down menu for selecting queries (created mostly by the end-users' IT teams) and a simplified(ish) query builder.

However, despite these changes, the new dashboard failed to gain widespread adoption. Our data revealed that over 90% of users chose to disable the feature and revert back the older (much uglier) version.

Step 1:

Used User Research to Understand the Pain

I didn’t start research with any idea that I would be building a global search tool. I had been told a dashboard had been implemented to solve tasking problem. So I came into the research with intention of discovering why the dashboard had failed.

First, I conducted interviews with records processing administrators and staff from various cities and departments.

There were two themes I heard from these folks repeatedly:

1. Our simplified query tool was easy to understand how to use, but still it was useless because the records staff weren’t database experts and the didn’t have knowledge of the names of data tables or understand the data structures their IT teams had set up for their records data.

2. The new dashboard was prettier because it used larger cards and more white space, vibrant color accents, and prettier layouts. But they did not display all the necessary data elements users needed to perform their tasks or organize it in a way that was as effective to serve scanning and quick decision making like the old, saturated and “ugly” UI tables did.

Step 2:

Proceeded in the Wrong Direction (Briefly)

I have to admit something about how I first tried to use these new insights: I had my head too low.

After finding the likely big deficiencies in the dashboard solution, I stared out to correct them by trying update the dashboard to fix them.

I tried to make the query more natural by mapping database names better to what the business users understood, I enhanced the cards to include more data in neater columns.

Still, as I was testing it with users, it became apparent the UI was understandable enough, but I still wasn't getting that "oh this is cool" verbalization you get from users when you have really solved a problem.

I was still hearing a lot of reservation from participants. Many said they would likely still be unable to get the list of exactly what they wanted and would not be able to find the "one-off" things they often needed outside of their lists. Most predicted that they would still need a lot of their IT department's help to get setup and use this feature.

Step 3

Turned Around

I appealed to the Product Management and Design teams.

I had to convince them it was a good idea to toss a few weeks of work out the window.

We were trying to fix a tool but we hadn't considered enough whether it was the right tool to fix.

To me the problem was becoming more clear.

Records keepers could not find the information they needed, the documents they wanted, or make their own lists that help with work. And a Dashboard full of complex queries each organization has to set up statically for each new need, was just never going to be the right solution.

I wanted to go back and think about how we should help users find anything they wanted, any time they needed it, without having to send a ticket to IT. After all, they were the experts in the business meaning of all this data, and what need to do with it. They should have been able to control it for themselves.

The images below are a few highlights from the case I made for this redirection, but if you're a lover of a slide decc, you can see the whole presentation by clicking right here.

Step 4

Drew with Developers

This was a matter of our internal design and tech teams needing to create a tool that could help take what users knew about their own documents, records, communications and actions and creating a tool that would translate what the system did with it all back to them in their own language.

Knowing how the tech team understood where all this data was going, and how they would tie it all together, really helped me get a better idea of what was under this hood.

In the end we started with the data tables that were not completely customizable by the customer and built basic UI queries around these. These were clues to help us help the user facet the search results into views that offered enough context to help the system and the search tool further refine results using the user’s business organization’s data formatting.