Knowledge workers in large companies spend an average of 8 hours a week searching for information. Finding information on the web is simple, any employee can hop onto Google and perform a web search and have results within a few seconds.
However, trying to find specific information inside a complex enterprise system is more difficult. Enterprise's data is constantly growing, and it's not all in one place. The data is spread across dozens of repositories ranging from customer support software, to data storage, e-mails, work collaboration tools, and more.
Imagine trying to hunt down specific information without knowing which of your company's apps it's in. Was that sent to me over e-mail, Slack, or Dropbox?
It's common for employees to spend over an hour a day trying to hunt down the information they need. Those lost hours in productivity can add up to millions of dollars a year for large companies.
In order to tackle the problem, employees need a search solution that searches inside all of the company's apps simultaneously.
The term 'knowledge worker' refers in a broad sense to people who work with information on a daily basis, including engineers, physicians, pharmacists, lawyers, etc.
For our user persona, we wanted to narrow down the target user from "knowledge worker" to a more specific user with a specific career. We decided to first focus on in house recruiters, because the first pilot team interested in the product was an HR team.
As the sole designer on the team, I worked with a full-stack developer to implement my designs.
Both of us talked to customers and collected research. From the information gathered we then decided as a team on the priority of the features.
After establishing the feature priority, it was then my responsibility to create the initials sketches, wireframes, user flows, brainstorm about the appropriate interfaces, and to create the visual design of the product.
As there was only one engineer and one designer working on the project we chose to use the material design lite (MDL) framework for the initial testing and prototyping of the app. We chose MDL because it would greatly reduce development time and it was responsive on all devices.
The design process consisted of lots of sketches, wireframes, feedback and revisions to the wireframes, the prototype we created in MDL, input from users, and then a more refined interface design once we are able to move away from the MDL framework to either the full Material Design Framework or Bootstrap.
When a returning user logs into WhereDat, what do they see?
Logging into a blank search screen every time to search wasn't the best use of time. To make users connect with their information faster, we decided to create a dashboard.
The dashboard will display recent searches and file changes among any of the apps connected to WhereDat.
CHALLENGE: SEARCH RESULTS
How do we develop a consistent design language for search results that range from files, to e-mails, to chats, and coming from different sources like Gmail, Trello, Dropbox, etc?
We defined the search results as needing to show the app being searched inside, a profile picture (when available), a preview of the file, and a preview of the text content.
How can the user tell if they're clicking on the right file from just a few lines of text?
Once a search results is clicked on, the user is directed away from WhereDat to the search source. In order to prevent the user from jumping back and forth trying to find the right file, we needed a preview function to reveal more information about each search result.
First time user need to first 'connect' their apps to WhereDat's search engine. Once connected, they are able to search inside all of their apps simultaneously.
Returning users are directed to the dashboard where they can see recent searches and activity from the apps connected to WhereDat.
Before investing the full development time required to design all the features we created a prototype on Google's material design lite (MDL) framework in order to test our ideas with users. Although the visual design is very restricted with MDL, a great advantage is that it's fully responsive. A responsive app was important to users as they wanted to be able to search inside their apps both on their computer and on their iPhones.
Based on feedback received from our test users using the prototype, there are a number of challenges to consider for the next release, for example:
• how to search inside folders, or sub categories inside the search source
• how to more intuitively filter search results by app, file type, date, etc.
• how to sign in with multiple gmail or drive accounts, how to switch between them, or turn them on and off
• how to select, and open multiple search results