Contact Us

Use the form on the right to contact us.

You can edit the text in this area, and change where the contact form on the right submits to, by entering edit mode using the modes on the bottom right. 


123 Street Avenue, City Town, 99999

(123) 555-6789


You can set your address, phone number, email and site description in the settings tab.
Link to read me page with more information.

Web App

Helping knowledge workers quickly find the information they need so they can be more productive.



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. 

Still in development

the Users

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 Accountants, because the first pilot company interested in the product was an accounting firm.

My Role

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 limit ourselves to the material design lite (MDL) framework for the initial testing and prototyping of the app. We chose MDL because it was would greatly reduce development time and it was responsive on all devices. 

The tradeoff for the shorter development time was poorer visual design as the MDL framework is very restrictive. 


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.


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. 

design adjustments

An issue that came up while testing the prototype was the difficulty of searching inside a folder that is inside an app. For instance, sometimes the user would remember the name of the folder inside dropbox where their file was, but not the exact name. The prototype didn't support being able to search that deep so I created a more multi-level search for users to see more of their data.