The brief

Streetscape.gl is a toolkit for visualizing autonomous and robotics data. It is built on top of React and Uber’s WebGL-powered visualization frameworks, and primarily used to analyse accidents involving autonomous vehicles.

The brief was simple – analyse the functionality of the tool, and suggest improvements based on researched data. I had one day to achieve all this, and present my findings, along with high-fidelity designs.

Project plan

Given the short time-frame, I began by planning how I would approach the project, including timeframes for each specific task. This amounted to a streamlined user-centred research and design process, outlined below -

1. Understanding the software (30min)

What does it do? How does it work? What information is available in the UI, and how does one interact with that information?
Deliverables: Heuristic mark up, notes, functionality categorisation.

2. Competitor research (30min)

Are there examples of other software achieving similar tasks? What can we learn from them? Are there mistakes I can identify and avoid in my own design?
Deliverable: Competitor analysis

3. User research (1hr)

What do I need to find out? Diagnosis of current state - opportunity to highlight areas for improvement. Who are the users? What are they trying to achieve? How are they interacting with the systems?
Deliverable: User interview & analysis

4. Idea generation (30min)

Quickly come up with multiple potential solutions; sketch ideas and explore where I can bring the most value to the product.
Deliverables: Hand-drawn wireframing, notes & analysis

5. Taking a concept further (1hr)

Mapping out one or two ideas more thoroughly to explore feasibility and potential for improvements.
Deliverable: Digital low-fi wireframes

6. High-fidelity wireframes (3hr)

Exploring the realistic application of these ideas to the product. Detailing UIs and Interactions, potential for prototyping. Explore specific aspects of the design in detail.
Deliverables: High-fi wireframes, annotations/feedback/analysis

Step 1: Understanding the software (30 min)

I was given access to a demo environment to explore. This allowed me to get to grips with the complexity of the UI, which (as you can see below), was intimidating at first glance.

At this point in the project, I only had a vague understanding of what the tool was, how it worked, and what it set out to achieve. As such, I felt the best way to start was with a heuristic mark-up, where I sketched the UI, highlighting each discrete element, and describing what I thought their purpose was. From this, I was able to group the functionality into what I considered appropriate semantic groups, which didn’t necessarily match up with how they were grouped in the UI.

Step 2: Competitor research (30 min)

In this case, rather than look at other autonomous analysis tools (which are few, and challenging to access), I chose instead to explore three indirect, but relevant, software groups – coding software, playback & video editing tools, and videogames (huh?!). For each of these, I found two or three examples, looked for functional similarities to Streetscape.gl, and highlighted aspects that I thought would be valuable additions.

The first group I explored was CODING SOFTWARE -

Next, I looked at VIDEO EDITING & PLAYBACK TOOLS -

And finally I looked at some VIDEOGAMES, specifically management games with complex, multi-window UIs -

Step 3: User research (1hr)

Due to the time-intensive nature of this project, I was only able to conduct a single interview with a user of the software. Before the interview, I identified the most important things I wanted to find out -

• Who are the typical users of this software?

• Why do they use the software? What data are they hoping to extract?

• In detail, how do they manipulate and interact with the software to achieve their goals?

• How do they rate the usability; both individual elements and overall layout?

I used this to guide my questions when performing the interview.

Here’s a brief summary of what I discovered -

Step 4: Idea generation (30min)

These results were enough for me to start sketching out some concepts. I spent half an hour coming up with four potential layouts, highlighting their key strengths and unique functionality for analysis.

Step 5: Taking a concept further (1hr)

Out of the above four ideas, there were two that stood out to me as being strong candidates (Concepts 1 & 3). I decided to progress these two ideas simultaneously, adding more detail, higher fidelity and analysing in more detail until I was confident in which one I should commit to. This process included the transition from pen and paper to digital wireframes.

This process helped me to clarify my thoughts with regards to the two options - Concept 1 was a more exciting overhaul of the UI, but felt like change for the sake of it. It also came with too many drawbacks, and given that the original UI was not performing terribly, it felt like a design overreach.

Concept 3 allowed the user much more agency in terms of customising their UI, without sacrificing the ability to view multiple information threads simultaneously. It also introduced strategic UI enhancements without completely overhauling the user experience, which better met the requirements gathered from the user interview.

Having settled on Concept 3, I continued to upgrade the fidelity of my designs, and started looking in detail at certain elements of the overall UI. I focused especially on the timeline, as my interviewee highlighted that as their most-used interactive element within the UI.

Step 6: High-fidelity wireframes (3hr)

From here, I rebuilt the entire UI based on the new concept. This was the most time-consuming step, as I was keen to ensure the final designs were complete, well-documented, and shippable. I built a rudimentary design system to support my UI work, ensuring consistency in approach. Overall, I was very happy with the outcome.