Can I do user research without users?

What are some common excuses for skipping user research? "I don't have access to users." "The project has tight deadlines." Even under these circumstances, some quick yet effective user research is still possible.

I sat there scratching my head wondering what to do. I just got assigned to design a new product - a dashboard for monitoring factory operations, that would be used by people called "process engineers". I had no idea what process engineering was and, to make the matter worse, I couldn't get access to any process engineers to talk to. How do I create user-centered designs when I don't understand my users? 

After all in-person user research efforts came to a dead end, I turned to the all mighty internet for my rescue. As it turned out, there was a wealth of information about process engineering readily available with a click of a button!

  • YouTube
    • There were many "Day in the life of ..." videos featuring process engineering.
    • Some companies post promotional videos featuring the work of process engineers.
  • Wikipedia
    • I started with the "process engineer" entry and that led to all kinds of interesting and relevant links.
  • Competitor case studies
    • Some of our competitors' websites had neatly organized case studies that went into details of process engineer's work.
  • Job postings
    • Process engineer job qualifications and responsibilities helped shed light on their work.
  • University programs
    • Some universities offered process engineering programs. Their websites contained useful program overviews, curriculum, alumni interviews, etc.
  • Textbooks
    • A brief scan at the table of content and intros gave a good idea of what process engineers do.

Reading and watching these online materials helped me gain a good understanding of what process engineering is and how process engineers goes about doing their work. You may wonder, is online research inferior to in-person user research? I think they each have pros and cons and it's a toss up as to which one is better.  In-person user research gives you more in-depth knowledge about a small number of users, whereas internet research provides a wider representation of users from different background and industries. If you do not have access to users or are short on time, I recommend giving internet research a try. 

I condensed the information I learned into a journey map, that walked through a process engineer's typical day. I shared the map with the product manager and engineers, and referred to it often through my design iterations.

They say necessity is the mother of invention. This resource-poor project ended up teaching me a brand new way of doing user research. Lack of users? Shortage on time? These are not excuses for not understanding your users. The worldwide web and a little creativity are all you need to take advantage of a wealth materials already available and help keep your designs user-centered even in the tightest projects.

Half Design is Asking Questions

Half of design is about figuring out the right question to ask. Each design iteration is inspired by a new question. Where we start off may be very different from where we end up.

My assignment: Design a data management tool used for industrial data visualization. 


Iteration 1

How might we design a tool where users can access data related to all their assets?
— Initial question


A tree-structure directory that represents all assets the a user has. By traversing up and down the tree, the user can locate any asset they have. Then they can click on that asset and see all the data related to it. This is the design sketch I came up with:



After showing the design to some users, we quickly realized the problem: most of the data is not useful for a user's task at hand. Ans since a typical user has tens of thousands of assets, it takes a long time to find the specific piece of data the user actually needs.


Iteration 2

How might we design a tool where users can quickly locate the relevant asset data they need?
— Revised Question


Let's try to infer what the user wants from the context. If they are looking at Asset X, do they most likely want data about Asset X? Bingo! Based on this idea, I simplified the asset directory to displaying only the current asset by default. If the user wants more assets, they have the option to add them into the directory. I sketched out a new design:



I tested the new design with some users, and they were able to locate data a lot faster. An improvement from the last iteration! However, during testing, I learned that there were other types of data the user need for charting. These data are not related to specific assets and therefore cannot be found using the asset directory. In legacy tools, a user would go to a different part of the app to locate such data. It would be nice to have all the data in one place.


Iteration 3

How might we design a place where people can find all they need to plot charts?

— Re-revised question


Maybe that's not too hard. We already give users the option to add additional assets to the directory. Can we use the same interaction pattern for adding more types of things to the directory? Yes, we surely can. So here comes a new design:



Iteration 3 received the best results in usability testing. We ended up adopting iteration 3 as the final design. Here is the high-fidelity prototype. Credit to the wonderful Wade Fong for visual design.

User Journey and Workflow, Designer's Secret Weapon

User experience feeling like an incohesive patchwork is a common problem for large complex software products. Journey maps and workflow diagrams help bring the product big picture into focus and facilitate teams' effort towards a united user experience 

Here is how I used journey map/workflow exercises to foster a cohesive user experience for two GE products.

The two products share some common traits:

  1. Both were at a early stage of the product life cycle, with limited prior work to reference. Much was still unknown about the product and what the overall user experience would be.
  2. Both required complex domain-specific workflows that the product teams had to learn about. The workflows usually involved multiple personas and many steps to complete.
  3. Due to large product scope, both applications adopted organizational structures where multiple product managers and dev teams worked on different pieces of the product. This created silos and teams had no clear idea about how their piece would fit into the overall user workflow. 

As the designer working on these products, I needed to change the status quo. My job is to craft one cohesive user experience that defies the boundaries of product team territory. Users should not have to juggle between different experiences just because they happen to be built by two different teams. Therefore, a designer's job, by definition, is to break down silos. For products that are built by large teams, design is in a strategic position to help shape the overall product and bring teams together.

How do I bring teams together under one cohesive user experience? By creating journey maps and workflow diagrams. Here is how I did that for these two products:




Developers' go-to place for managing all aspects of development activities when using the Predix platform.


For this complex project, my colleagues Edward Romero, Michael Moreau and I created an detailed journey map that captured the people and steps involved in making applications on Predix. We conducted many user interviews and subject matter expert interviews, and also walked through the process ourselves. In the end, we identified x personas and y steps involved from signing up on Predix to eventually deploying a successful app. This journey map helped the product management team refine the feature road map, and also helped the design team define the app's information architecture.

A section of the journey map



Data scientists' one-stop shop for creating and deploying data analytics for industrial machinery.


Shortly after joining the product, I noticed that one issue was constantly getting in the way of the teams' communication - a lack of clarify on how a user should move from one step to the next (each of the workbench steps was managed and developed by a separate team). I decided to start a conversation around this issue, by designing an end-to-end user workflow.

The resulting workflow diagram illustrated my proposed steps and personas involved from the initial data cleaning to the ultimate analytic deployment. I posted the diagram on the wall and walked it through with other designers, product managers and software architects. I updated the workflow based on people's feedback. These conversations sparked by the workflow diagrams helped flesh out teams' understanding of a cohesive user experience and converged differing opinions towards one concrete design.


A section of the workflow diagram.


Whenever I catch myself losing sight of the larger picture of the application I design, I go create a quick and easy user journey or workflow to bring the overall user experience back into focus. They are also great conversation starters that bring diverging ideas on a large team into alignment. Journeys and workflows rock!