Disclaimer: Shared with permission from The Jackson Laboratory

The tool, the problem, and what was at stake

What is Cloud Images Tool(CIMG)?

CIMG (Cloud Images Tool) lets JAX scientists run image-analysis workflows, from classic processing to ML/AI models, directly in the browser. It’s how research teams turn large microscopy and slide images into results they can use.

Why it needed a redesign?

Scientists across five user groups relied on CIMG, but the interface made simple steps slow: images were hard to find, one wrong move meant starting over, and new users needed an expert beside them. The redesign had to cut that workload and make the tool flexible enough to grow with the teams.

Before and after: what changed for the people using it

How I turned a complex tool into a clear redesign?

I was new to biotech, so I built the process around learning fast: understand the tool, hear every user group, agree priorities, then design and test in short loops.

Step 1 · Framing the problem before talking to users

I aligned with my UX manager and senior UX mentor on what success meant and what we were working within:

• The problem statement

• Quick overview and functioning of the tool

• Budget limitations

• Scope of the project

• Sprint planning of the project

• Timeline: 04/10/2023 - 07/27/2023

• Key Stakeholders

As the only designer on a domain I didn’t know, I needed the constraints clear before I could ask users the right questions.

Step 2 · Learning the tool, then hearing from the people who use it

I studied CIMG’s documentation and walked through it with its developer. In parallel, discovery sessions with stakeholders set the project requirements. Then I interviewed the people who use the tool every day, asking how their group works, what they process, and where the tool slows them down.

What I heard: five user groups, each fluent only in its own corner of the tool.

Step 3 · Merging five ways of working into one shared flow

Each team knew only its own use case, so no one could describe the tool end to end. With the Project Manager and developer, I mapped every team’s workflow and merged them into one navigation path. That gave everyone a shared picture to design from, because a redesign built around one team would have broken another.

• Three journeys every team shares, and the redesign had to protect

Step 4 · Turning conflicting needs into agreed priorities

Across 6 user interviews, needs started to collide: what one team called essential, another called noise.

What we chose not to build, and why:

• Multiple images at once: left out so one image stays clear and easy to work on.

• Multiple algorithms at once: left out because it added cognitive load and slowed processing, the tool’s core job.

From 6 interviews to 4 themes that became the requirements

In short: scientists needed a tool that felt like JAX’s own, was easy to move around in, showed what was happening, and added the few features that would save them the most time.

Step 5 · Competitor Analysis - Borrowing from the tools scientists already trust

With the requirements approved, I studied Fiji and OMERO, open-source imaging tools researchers already use. I borrowed patterns they’d recognise (region selection, zoom, filters, file management) so the redesign wouldn’t add a new learning curve.

Step 6 · Three rounds of A/B testing to a layout that could grow

The approved layout: projects, image files, algorithms and the view panel, always in reach

After three rounds of A/B testing with users, I settled on a layout where the four things scientists use constantly never hide behind a menu.

Step 7 · High-fidelity designs, checked against where users looked and clicked

In moderated remote sessions, users took control of my screen with their cameras on, so I could watch where their eyes went and what they clicked first. Each feature in the high-fidelity design sits where users looked for it.

Finding an image: recent work and projects up front

Editing and running an algorithm from one panel

• Before testing, I reviewed the designs with the design team against Nielsen’s usability heuristics, which caught three issues early:

Step 8 · Testing with the people who’d use it every day

Overall, the redesign cut users’ workload by about 55%.

• I tested a clickable prototype with 3 current users, one new to the team and two experienced, so I’d hear from both ends.

• Each scenario mirrored their real work, from finding an image to downloading a result. I collected feedback after each task and a SUS score at the end.

• What they struggled with went straight back into the design: download moved next to the image, error messages became clear and visible, and the colour tool was removed.

• Later, a wider group of users trialled the prototype and answered a short survey comparing it with how they worked before.

How these were measured: task times and outcomes before vs. after in moderated usability testing, plus a post-use survey and feedback from a wider group who trialled the prototype. The redesign was then approved for funding.

Where it went next

• I presented the final responsive prototype to the scientific research teams and Computational Sciences leadership.

• I documented the full project and submitted it for budget approval. The redesign was approved for funding.

What I carry into every project

• Agreeing requirements early made every later design decision easier to defend.

• Keeping stakeholders close kept the team on board and decisions moving.

• Testing early, in wireframes, is far cheaper than finding problems in development.