Road Bot
- 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 automated vehicles, sensor integration, and a data processing algorithm.
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
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.
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.
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
Aligning With Engineering
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
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
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:
Raw Data From Robot
I’ve been collecting my lessons learned from designing interfaces and data visualizations like this.
Why “Engineering User Interfaces” Fail
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:
| Role | Description | My Typical Contributions and interactions |
|---|---|---|
| Technical Director | Oversee multiple teams of multiple disciplines | UX-related communications with the customer. Serve as team-wide UX consultant. |
| Task Lead | Oversee the team in which I fit in, typically Software | Deliver designs as planned, in sprint cycles. |
| Other Designer or Researcher | Collaborate on user research and design tasks | Prepare user research, perform synthesis, review and critique designs. |
| Developer | Typically front-end developer; tasked with building the UI | Deliver specifications. Negotiate features based on feasibility. |
| Algorithms Expert | Create the data processing algorithm | Consult their expertise to inform design. |
| Robot Expert | Implement controller for the robot | Consult their expertise to inform design. |
| Sensor Expert | Implement sensing ability of the robot | Consult 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.