Corellium

Mobile virtualization for cybersecurity teams

Role: Staff Product Designer
Timeline: 2023–Present
Status: Acquired by Cellebrite
Industry: Cybersecurity

Overview

Corellium runs virtual iOS, Android, and IoT devices for security researchers, enterprises, and government agencies. In 2023, I joined as its sole product designer, working with 3 PMs and 2 product owners in my design process. I set the design foundations that each release runs on: design is the source of truth, with my user flows tightly linked to it.

Enterprise customers hold the software they buy to strict accessibility standards. I noticed accessibility gaps soon after joining. Once closing them became a priority, and with the CPO's backing, I led design for a three-month accessibility and visual overhaul of the platform, targeting WCAG 2.1 AA. It also brought the platform to mobile for the first time. The overhaul focused on the screens most used and most crucial to people's everyday workflows.

Acquisition

$200M

Acquired by Cellebrite during my tenure

Compliance

WCAG 2.1 AA

Accessibility work that unblocked enterprise sales

Usability

SUS 81

Top 10% of products, where 68 is average

The device page as redesigned: tools in a sidebar, the Console open in the middle, and the virtual iPhone with its hardware buttons — Fig. 01: The device page before and after the overhaul

The device page before the overhaul: gray toolbar icons, a gray SAVE & REBOOT button, letter-spaced capital labels in Settings, and an outline of the virtual phone — Fig. 01: The device page before and after the overhaul

The Audit

The head of front-end engineering and I audited the platform together, each from our own side. He took the code: ARIA labels, keyboard focus and navigation, and other code-level accessibility work. I took the design: contrast and text size, checked with Stark in Figma and another contrast checker. I found that almost every color besides black and white failed contrast. States were unclear, and color was used inconsistently, like the highlights in Projects.

Before

The old project details page: Default Project under a green highlight bar, with its CPU cores, networking, and permissions settings, and its stored device slots and core counts in small letter-spaced gray capitals — Fig. 02: A project's details before the overhaul: a green highlight bar, and small letter-spaced gray capitals

Fixing any of it needed an accurate base, and Figma held mostly screenshots of the live product. So I built every screen there as editable designs, on desktop and mobile, matched 1:1 to the live product for the first time, and every change started from there. He and I then aligned the design system between Figma and Storybook, so engineers can now build new screens from it without me.

The Overhaul

One meaning per color

In the new color system, each color means one thing and clears its pass mark: 4.5:1 for text, 3:1 for bars and icons that carry meaning.

Before

1.3:1

Progress bar, below 3:1

Dot or ring

Status as a faint mark and tiny capitals

Random

Highlight colors, with no meaning

Now

18.4:1

Progress bar

5.1:1

Status in words, on a badge

5.3:1+

Green, orange, and red, on white

Device details and status, easier to read

Settings moved from spaced-out capital labels to normal case, with the device's specs as a scannable list, one per row. Each device's state is now written out in a badge, with progress while a device is being created or another action is happening.

Before

The old About panel in device settings: spaced-out capital labels (DEVICE NAME, MODEL, CREATED ON, OS VERSION), and the device's specifications run together on one line — Fig. 03: Device settings before the overhaul

After

The new About panel: labels in normal case, and a Device Information list with one spec per row, from Model Name and OS Version to Processor, Board, and Platform — Fig. 04: Device settings after the overhaul

Before

The old Devices page: each project under a colored bar, with each device's state as a faint ring and small letter-spaced capitals, STORED, beside its model, version, and creation date — Fig. 05: The Devices page before the overhaul

After

The new Devices page, on desktop and on a phone: on desktop, each project's devices in a table with each device's state written out in a badge, such as On, Off, and Creating (75%); on the phone, each project as a card listing its devices with each one's state under its name — Fig. 06: The Devices page after the overhaul, on desktop and on a phone

Three Decisions

Keyboard control in the phone and console

A virtual phone and its console have to receive every keystroke, Tab included. Keyboard users move through a page with Tab, so they could get stuck inside either one. Two shortcuts give them a way back out.

Phone escape: CtrlOptionTab
Console escape: CtrlTab

The head of front-end engineering proposed the shortcut, and at first it moved focus out of the phone right away. But an app on the device might use the same combo, so I proposed asking before leaving: the phone dims and offers to focus the previous element, focus the next, or send the shortcut to the device. That costs keyboard users one more step on the way out, but the combo still reaches any app that uses it.

The whole device page: the top navigation, the device's header, tools down the left, the console in the middle, and the virtual iPhone on the right. After Ctrl + Option + Tab, the iPhone dims and three buttons appear over it: Focus previous element, Focus next element, and Send shortcut to device — Fig. 07: The phone escape: after Ctrl + Option + Tab, the phone dims and asks before leaving

Three tabs on a phone

WCAG 2.1 AA requires every page to work at a phone's width, so the platform had to work on phones for the first time, and every part of it had to work there. My hardest call was to fit every tool without hiding or dumbing anything down. On desktop, the device page shows its tools, workspace, and device side by side. A typical mobile nav would have made them feel like separate pages, but each part changes the others. So I made them three tabs, using a component our design system already had. Tabs keep the three feeling like one page, each a tap away.

Mobile Tools tab: the device's name and status, its controls, and the list of tools — Fig. 08: The device page on a phone, as three tabs: Tools, Workspace, and Device

Mobile Workspace tab: the Console, with Download log and Pop out console buttons — Fig. 08: The device page on a phone, as three tabs: Tools, Workspace, and Device

Auto shutdown for devices left running

Virtual devices use up device hours for as long as they run. Before the overhaul, nothing in a device's status showed that, so people left devices running and then asked support about their hours. The new status badges show when a device is using hours and which states do, and auto shutdown completes that protection: a device left on can no longer quietly run up hours. It was another hard call, which I worked through with one PM.

I pushed for auto shutdown per device: each device shows its time left next to its status and turns off when the time runs out. People who need more time can suspend auto shutdown, and organizations can turn the feature on or off. We ruled out email warnings, which can get lost in an inbox, and one setting for a whole project or environment, which would break people's focus. Since auto shutdown shipped, those support questions have stopped.

Before

The old top of the page: small capital-letter navigation and a device-hours notice in the header, and below it the device's name and details, with no time remaining shown — Fig. 09: The top of the device page before the overhaul

After

The new top of the page: the device's name, and beside its On status an '8 hours remaining' chip whose tooltip explains the auto shutdown, with a Learn more link — Fig. 10: The top of the device page with auto shutdown on

Insights

The overhaul reached production in three months, within my first six, alongside an accessibility conformance report (a VPAT) that helped streamline customers' accessibility reviews and unblocked enterprise sales. The platform scored 81 in its first System Usability Scale (SUS) survey after launch, and I've reviewed each release's design for accessibility ever since.

I presented designs directly to the CPO, who sponsored the work from day one. The head of front-end engineering led the build, and we solved the mobile constraints together. One of the 3 PMs did the accessibility report with us.

Fixing accessibility gaps after the fact took an overhaul, so the lesson I carry into every system now is to make every component accessible from the start. That means a design system, components, and layouts flexible enough to adapt to nearly any device. It means contrast, focus, and labels built into that system, so every screen starts accessible. And it means accessibility checks that run with the tests, so regressions get caught before users notice.

The device page as redesigned, on desktop and on a phone: on desktop, tools in a sidebar, the Console open in the middle, and the virtual iPhone with its hardware buttons on the right; on the phone, its Device tab, with the virtual iPhone above the Tools, Workspace, and Device tabs — Fig. 11: The device page as redesigned, on desktop and on a phone

Let's ship something great.

Looking for feedback on your product or how to take an idea from 0 → 1?

Reach out