• Contents [Top]
  • Why in This Portfolio
  • Concept Overview
  • User Journey
  • Mapping the Information Flow
  • Aligning with Engineering
  • Humanizing the Interface
  • Turning Data to Insight
  • Why “Engineering User Interfaces” Fail
  • About the Project
  • Next Steps
Project

Road Bot

A fictional but representative design process based on my experience designing interfaces for automated, mobile sensors.

Contributions
  • End-to-End Design
  • Generative Research
  • Synthesis
  • Interaction Design
  • Prototyping
  • Software Testing
  • Evaluative Research
  • Data Visualization

Why in This Portfolio

On the job, I often encountered the task of designing a user interface to allow an operator to leverage specialized hardware, a data processing algorithm, or sometimes both.

This project is a fictional project based on combining several actual projects.

This page will not include interaction or visual design. For that, check out Folio Forge instead.

Concept Overview

Who is it for?

It’s for the operations team of Oldham City, who repair robots as one of their many tasks.

The interface I design helps them leverage automated robots equipped with sensors that detect potholes and the ability to navigate a city.

What value does it add?

Allow operations to set up and monitor robots.

The repair crew can gain confidence that the robot will do what they intended. In addition, the repair crew can trust that if potential damage or obstacles arise, the system will alert them to respond appropriately.

Allow crews to analyze and report on resulting pothole data.

This will help them plan and prioritize the allocation of resources.

Keep the interface as simple as possible.

This will help with operator training and their “perpetual rustiness” that results because pothole repair isn’t their primary job function. They would like to spend minimal attention and time on pothole repair.

Additionally, the more people who can use the system to control the robots, the better. People are spread thin.

Maximize the utility of the underlying hardware and algorithms.

This is because Oldham City pays a lot. This also requires me to more deeply understand its capabilities and limitations.

User Journey

The Iterative Process of a Road Repair Crew
  1. Plan & Configure

    Goal: Prepare robots to accomplish their tasks as planned, and succeed in their environment.

    Tasks

    • Create and compare routes.
    • Set up if-then action triggers.
    • Dial in other sensor configurations.

    The Value Added by Road Bot

    The repair crew can plan more quickly, collaboratively, and confidently than otherwise.

  2. Assess Road Conditions

    Goal: Bring back accurate data about the environment.

    Tasks

    • Monitor the location and statuses of robot fleet.
    • Open detailed info about individual robots and sensors.
  3. Triage, Report & Fix

    Goal: Decide where to send the street repair crew first.

    Tasks

    • Find pothole hotspots.
    • Create a remediation plan.
    • Report findings to repair team.
    • Plan for the next deployment of robots.

    The Value Added by Road Bot

    The repair crew can find and prioritize hotspots quickly and accurately. Moreover, they know that the data they gathered is reliable enough to help them focus valuable resources on the next repair effort.

Mapping the Information Flow

The following served as a diagram to track the flow of information throughout the user journey:

Road Bot Data Journey Map

I make a map that shows what information is used at which stage. This level of detail surfaced two more intermediary stages in the user journey: the things done to transition in and out of data collection.
I make a map that shows what information is used at which stage. This level of detail surfaced two more intermediary stages in the user journey: the things done to transition in and out of data collection.

Aligning with Engineering

Maximizing the Value of the Underlying Technology

Leveraging my developer background, I sought to understand the underlying technology at the granularity of an engineer while considering it from the user’s perspective.

Engineering teams typically already have a document such as an Interface Control Document  defining how subsystems of hardware or autonomy interact with each other and which configuration options are exposed to the user interface.

As I look through the document, I create a table (as shown below) of all the parameters. Doing so allows me to ramp up and align to their activities while also focusing my efforts. My goal is to maximize the utility of this technology.

The following table is a mere sample of the parameters I might come across, as there may be dozens of options like these:

For an actual example with a of parameters, see the design process for Folio Forge.

Humanizing the Interface

Transitioning from raw parameters to user-centered software interface

    Below are the topics on which I typically meet with the engineering teams. I fill out the “Robot Configuration Options” table above to serve as a shared map between me and engineering.

    Tradeoffs

    A configurator should always be aware of the tradeoffs since they often need to optimize and maximize the use of limited resources. Ideally, the interface can surface the relationship of intertwined concerns.

    Valid Input

    Establishing these with the engineering team can inform how the UI should enforce hard limits and prevent infeasible configurations.

    To discover these, we talk mainly to engineers or SMEs with a technical understanding.

    Default Values

    After working with users and engineers, we may arrive at a set of default values we expect will produce the optimum result with the least effort while most likely aligning with configurators’ goals.

    In some situations, there should not be a default value set. For example, if we want the configurator to slow down slightly to consider a specific value carefully. All this will depend on user research to know what users need the most.

    Advanced Parameters

    The Advanced column helps determines the interface’s information hierarchy—whether we put the parameter upfront or tuck it away—which helps streamline the configuration and provides the right amount of decision-making to which we subject our users.

Turning Data to Insight

Aligning with the Underlying Technology

I try to obtain sample data as soon as possible in the project to have realistic data values for mockups and visualizations.

With the ongoing example, it might be something like this:

FieldDescriptionExample Values
GPS CoordinatesWhereabouts40.4383441, -79.9421857
GPS Error RadiusAccuracy of GPS5m
HeadingWhat direction it’s facing270 degrees north
TimestampTime and date2021–06–24T03:11:08.459Z
Bumpy ScoreHow bumpy was this part of the road?1–100
Battery LevelCurrent battery level12.4 volts
SpeedCurrent speed1mph
ImageCamera image captured360-degree photo

I’ve been collecting my lessons learned from designing interfaces and data visualizations like this.

Why “Engineering User Interfaces” Fail

Reflection & Broader Design Implications

I see my role as someone who can transform the “Engineering UIs” that engineering-focused teams are prone to make into something more usable and powerful:

An “Engineering Interface” …A Humane Interface …
Lists out input fields as one long form.Assumes that the user will use some components far more often than others (Pareto Principle).
Leverages smart defaults, templates, and other aids.
All outputs have the same level of hierarchy on the screen.
User attention diluted across too many signals.
Imposes information hierarchy, starting with most salient, then progressively discloses detail.
Carefully manages user attention, as not to dilute it.

Technical capabilities can be specified precisely in technical terms but say nothing of their importance, alignment with user’s goals and priorities, or how users might want to set them or use them.

And when the parameters for capabilities are thrown onto a screen indiscriminately, they comprise what I’ll call the “Engineering UI”. Engineers deliver these with the best intentions, yet unfortunately, they are hard to use, hard to train, and users dread them.

About the Project

Project Length

The projects have lasted from four months to two years.

Team

Here are some other roles I typically collaborated with:

RoleDescriptionMy Typical Contributions and interactions
Technical DirectorOversee multiple teams of multiple disciplinesUX-related communications with the customer. Serve as team-wide UX consultant.
Task LeadOversee the team in which I fit in, typically SoftwareDeliver designs as planned, in sprint cycles.
Other Designer or ResearcherCollaborate on user research and design tasksPrepare user research, perform synthesis, review and critique designs.
DeveloperTypically front-end developer; tasked with building the UIDeliver specifications. Negotiate features based on feasibility.
Algorithms ExpertCreate the data processing algorithmConsult their expertise to inform design.
Robot ExpertImplement controller for the robotConsult their expertise to inform design.
Sensor ExpertImplement sensing ability of the robotConsult their expertise to inform design.

Next Steps

After gathering the above information about parameters, I would typically organize them and create mockups for the interface.

Check out Folio Forge for examples of interaction or visual design. It’s an app I designed, built, and launched.

You can also see a growing list of lessons learned from designing interfaces like this.


Jay Liu
Written by Jay Liu, experience designer.
https://jayliu.design
© 2022, Jay Liu