Design Research

Case Study

Austin Mobility Viewer 


Austin Transportation Data & Technology Services helps city staff tackle Austin’s mobility challenges. The Mobility Project Viewer is a public-facing dashboard that serves as a one-stop-shop to view all ongoing mobility-related projects citywide. I drove this product’s initial design research during my fellowship.

In 9 weeks, I achieved the following:

  • Identified the target users and the specific information they are looking for
  • Collaborated with users and ideated product requirements for future development
  • Provided suggested guidelines that center future research and design
  • Created an interview guide that serves as a template for future use

My Role

Design Researcher


Secondary Research
User Interviews
Affinity Mapping
Dot Voting


2 Product Managers
5 Public Information Officers
Several Software Developers

The Problem

How might we provide a visualization that enables everyone to capture Austin’s mobility projects at ease?

Research Questions

  • Who will use this mobility viewer?

    • What information do they need?

    • Why do they need that information? What are the questions they are trying to answer?

    • Which users should we prioritize and why?

  • What are the overlapping use cases?

  • What will be the key requirements and features?

  • What are some good case practices out there?

The Approach

Phase 1: Explore

Secondary Research

What I did:

  • Collected all current artifacts (mapping systems and dashboards) used by Austin Transportation
  • Conducted case studies of similar construction or mapping systems used by other countries and US cities
  • Benchmarked visualization from other industries like smart city and surveillance system

Why I did this:

  • To understand the context and problem space better
  • To look for good case practices in the current market


    Phase 2: Define

    Work Session with Public Information Officers (PIOs)

    What I did:

    • Invited 4 PIOs to an one-hour interactive work session
    • Set up multiple charts on Miro board for individual brainstorming and group collaboration.

     Why I did this:

    • To find out
      • who are PIOs’ key stakeholders
      • who are the target audiences (= potential users)
      • what does their workflow look like


    • The PIOs have very different priorities, but they all tend to have a stronger sense of accountability to city executives and elected officials.
    • Location is a factor that affects the importance of how they prioritize content.
    • Emergencies supersede everything.
    • The public and other advocacy groups were considered as important but not urgent, which indicates there’s a passive audience that consumes the information.

    1:1 Interviews with PIOs

    What I did:

    • Set up 1-hour individual interviews with 5 PIOs
    • Created an interview guide
    • Edited and pull quotes from AI-generated transcripts

    Why I did this:

    • To understand and empathize with PIOs’ workflows
    • To find out PIOs’ goals, needs, and pain points
    • To identify the public’s needs through PIOs’ perspectives

    Synthesis for PIO 1:1 Interviews

    What I did:

    • Put quotes and references from interviews into different categories
    • Conducted an Affinity Mapping session with 2 Product Managers
    • Summarized the insights with supporting quotes in a document

    Why I did this:

    • To identify overlapping use cases and needs
    • To generate insights for product development team
    • To identify action items and notes for future use


    • Information Extraction and Communication
      PIOs need to take extra steps in order to publish information. Their reliance on having to track down information creates bottlenecks which leads to inefficient or low productivity.
    • Other Reporting Systems
      There are a lot of sources of information that teams use to estimate project timelines. Navigating those sources of truth can create a disconnect between ideal timelines and reality.
    • Consistency of Information Sharing
      Information sharing happens in various forms and is inconsistent. Some teams provide a streamlined solution while others aren’t as predictable.
    • Internal Behavioral Change
      Buy-in and adoption from Managers would be necessary to support the efficacy of a public-facing platform.
    • Public Expectations
      Setting public expectations about how construction projects affect residents needs to answer questions about personal impacts. Outreach about those impacts can be overwhelming and redundant if departments don’t coordinate overlapping information.
    • Ease of Use
      Making a public-facing platform mobile-first and easy to communicate allows for more usability.

    Phase 3: Ideate

    Ideation Workshop with PIOs

    What we did:

    • A 2-hour ideation session with 8 participants (including Product Managers and developers)
    • Brainwriting and dot voting for each insight
    • Documented all the ideas in the Ideation Summary
    • Synthesized the ideas using the Impact/Feasibility Matrix

    Why we did this:

    • To generate ideas for the product
    • To prioritize product features and next steps


    • Internal Communication
      • Tools need to be incorporated into Project Managers’ workflow to not add burden to day-to-day tasks.
      • Establish weekly update that helps PMs to give status updates, with nudging emails until the action is complete.
    • Product Features
      • An activity feed that gives a summary review would help to record what’s happened in the project.
      • For comprehensive citywide data, rely on performant visuals/dashboards rather than cramming that info into a map.
      • Translation/accessible language is a must.
      • Dashboard/App might not be the end solution for everyone; being able to get information to radio/TV stations, SMS updates, resident-facing emails, CoA social media.
    • Community-Centered Design
      • PIO to lead outreach efforts, create and distribute surveys that will help us shape the public-facing side.
      • Create an easy way for residents to give feedback on the platform.
      • Invest in prototyping and iteration with resident input early on; work backward from the ideal solution.

    Generative Research Results

    Identified Target Users

    • Public Information Officers
    • Residents and business owners impacted by constructions
    • Advocates/ Advocacy groups
    • Media
    • Council offices/ Neighborhood associations
    • Regional partners

    Identified Information Users Need

    • Important dates, scope, locations, construction timelines
    • Design details
    • Project updates
    • Contact information of project team
    • Before (current situation) and After (proposed vision)
    • Construction impacts
    • Funding sources

    Suggested Guidelines

    • Buy-ins and behavioral change from internal stakeholders to support the viewer’s efficacy
    • User-centered research and design to meet public’s needs through consistent outreach
    • Involve PIOs at different stages of the prototyping and iteration process
    • Mobile-first and plain language design to increase accessibility
    • Include developers in ideation sessions and usability testing

    The Challenges

    1. Navigating Acronyms + Unfamiliar with the City of Austin

    How I Overcame It:

    • Asked many questions and attended as many meetings as possible in the first few weeks
    • Read news coverage and many related online resources to get familiar with the local context

    2. Being the Only Designer/Researcher on the Team (aka Team of 1)

    How I Overcame It:

    • Joined the developer’s daily sync to immerse into the team culture
    • Helped product managers with another product’s usability testing to lessen their burdens while getting to know other users and team members
    • Took every chance to present in large meetings and showed the value of user-centered design

    Lessons Learned

    1. Taking the time to fully understand the context

    The government space can be extremely convoluted and challenging. It took weeks to get to know the people, process, and culture. Instead of rushing to get to the solutions, I learned to take the time to fully understand the problem space. “A problem not fully understood is unsolvable; A problem that is fully understood is half-solved.”

    2. Meeting people where they are

    Not all problems need to be solved by a technological solution. By understanding the people, process, and culture, we are able to ask the right questions and solve the core problem more accurately. 

    3. Educate others how user-centered research can be done and its value

    Being the only designer/researcher on the team was quite intimidating at first, but I’m glad that my team was very supportive. Instead of thinking you are the odd ball that doesn’t fit in, take the chance to show others how user research can be done in simple ways, set up templates for them, and bring them in interviews or usability testing as observers. Most importantly, take every chance in team meetings to present your findings to show them the value of research.

    Other Recent Works