Ultrasound Project X

Project performed while I was a Senior Staff Engineer at Siemens Healthineers

THIS WORK IS COVERED BY NDA.
I HAVE BLURRED ALL ARTIFACTS AND USED VAGUE LANGUAGE TO TALK ABOUT THE DETAILS.
I’VE ALSO ALTERED SOME WORDS TO FURTHER CONCEAL THE WORK.

When a patient receives a traditional cardiac ultrasound exam in a clinic, a report is created. That report is used to communicate to physicians for diagnosis. Ultrasound is about taking pictures and making a report for the doctor. We have a report on our system, but it needed an update to be more functional. This was a large project with dozens of features.

Reports are both digital and printed. They are generated by taking pictures and performing measurements. It’s then made available to sonographers and physicians who will prepare the report in a coherent manner to tell a story about the heart functions. Measurements and data auto generate from multiple sources to create the report output.

Role

• UX design and research

• Managed stakeholder feedback

• Strategy

• Project manager

• Usability studies

Team

• Clinical stakeholders

• Developer Engineers

• Ultrasound Engineers

• Product Management

• System Architects

• Risk

Challenges:

• The project was put on hold multiple times.

• Stakeholders were revolving.

• The only two people keeping the project alive were myself and the product manager.

• Contract designers with a lack of ultrasound knowledge and different processes.

• Project was not well defined from the beginning so too many expensive resources were used up front leaving the project abandoned.

• The design system was unclear.

Learnings:

• Ask bigger questions up front.

• Define scenarios up front, don’t focus on features first. Original designs had features that were not required.

• Engineering started too soon.

• Get teams all on the same page sooner than later.

• Define your design system sooner than later with engineering, don’t assume any design system can be interchangeable.

• David Roth (the Product Manager) is super smart.

Process

Understand where we are

When I was placed on this project there was a robust team of roughly 30 people working on this product and a half-coded prototype. They had been working for about a year and a half. It took me some time to understand what problem we were trying to solve. I had to navigate all the work that had already been done. There were contractors brought in to design it, but some were being phased out. The coded prototype looked like they just took the ultrasound software and placed it on to a laptop machine. I knew this would not be acceptable.

Learn what problem needs to be solved

I had to understand who the target market was, who the intended user is, and what the strategy was for this product, the differences between small and large clinics, and how this gets used in different countries? There was little documentation on these. The past designers focused mostly on screens and UIs. I had discussions with stakeholders to get a clearer picture.

Process

Define all scenarios

This is difficult because there are a vast number of scenarios. This took me months because it had not been fleshed out or expressed anywhere. There are a lot of gotcha scenarios in these reporting scenarios because it’s used by multiple users with a large number of states and some carry varying levels of risk. It interfaces with the ultrasound machine, other reporting systems, PACS servers and DICOM servers.

Help to flesh out white papers and gather requirements

Our process within ultrasound is to work with a white paper. Many other orgs will call it a project or creative brief. This is a document that everyone works from so we are all clear on what we will be building. There were dozens of white papers that needed to be created. I needed to get that straight because the engineering team will often just start building without proper definition. The requirements were not well organized. They were ultrasound requirements, not reporting requirements and therefore couldn’t be used.

Benchmark against competitors

Audited the major competitors to observe and understand market expectations

Build off the original designs that other designers had created

There was some good work to be salvaged from the previous designers. I took that and blew it out to the scenarios that had been missed and put together workflows from the screens. The screens didn’t show all of the states and end-to-end flows. This created gaps that I had to fix and address. There were dozens of screens and features that needed to be brought together and fleshed out. Below is just one part.

Get internal clinical feedback and iterate

I had a couple of clinical partners and the product manager that I would share my designs with to gather feedback to iterate. We did this several times until we landed on solutions we thought met the need.

Get external clinical feedback

I created prototypes in Figma that allowed for the participants to get a high-level feel for the product and features. This provided further feedback that allowed me to continue to iterate. I created the question protocol and a report and shared the data with the feature team.

Iterate, iterate, iterate

Break down designs to atomic controls

The original designs were screens. This can create challenges in documentation for engineers because there are behaviors and rules within each control. That often gets lost in the screen documentation. I had dozens of controls, their states and their rules with requirements and hook them to Azure Dev Ops tickets because engineers focus is in Azure Dev Ops.

Get the new engineering team up-to-speed

The original engineering team was removed and replaced. I had to ramp up the new engineering team remotely as they were located in Slovakia. We had weekly meetings where we went through prototypes. I shared documentation and Azure Dev Ops tickets.

Get the organization to buy in to the work

Despite the fact that dozens of people had worked on this, and there was a half-coded prototype, the organization was not sold on this idea. We traveled to Slovakia where we met with multiple stakeholders to help them understand the business case.

Which design system?

Ultrasound has it’s own design system and is built on legacy software. It is not traditional HTML5, or a CSS type of design system. It’s more complex in nature and is embedded into everything. We wanted to use the Siemens Healthineers design system which is more modern in both code and look and feel. Additionally, it would allow us to be faster in the long-run. However there were fears and risks of integrating this design system into some of the legacy behavior. So the decision sits.

Other priorities got in the way and the project is on hold

My deliverables:

• Design documentation

• Figma prototypes

• User Journeys

• Information architecture

• Definition delivery

• Question protocols and feedback moderation

• Final designs in Figma

• Atomic controls for every piece of UI

• Hybrid design system