Mapping a Better User Experience in Medical Product Design
When designers and developers are building a software application, they commonly use a wireframe — a schematic that shows how elements are arranged on a page or screen — to guide the process. These wireframes are typically basic page elements that incorporate placeholder text and images to represent layout.
But while wireframes show how each screen of the app should be laid out, they don’t capture the interactions among them. So we’ve taken wireframing several steps further. MindFlow’s user interface design team develops what we call an architectural wireframe blueprint (AWB). It borrows elements from aspects of a flowchart to fully document how the app works as users progress from one screen to the next. The architectural wireframe blueprint is more than a mockup of the app’s visual design; it’s a road map for the full user experience.
We believe this holistic planning approach is essential for producing effective medical products. Apps designed for use in a medical setting, such as the digital user interface on a mobile testing system, have to be simple and intuitive. And while users like nurses and lab assistants are trained in healthcare, they may not be technologically savvy. A clear and easy user interface can be a make-or-break element for medical devices.
The interface is often a touch screen that is physically part of the medical equipment itself, so the components have to work seamlessly together. When Biofire Diagnostics came to us for help integrating a more powerful digital display into their FilmArray Torch system, they were redesigning the equipment with a digital touchscreen in place of a keyboard. The system also included a barcode scanner and multiple instruments, so we quickly recognized how critical it was to create the right connections among people, software, and equipment. Our AWB documentation helped make those connections.
Better Than Just Wireframes: Architectural Wireframe Blueprints
An architectural wireframe blueprint serves as the overview of an application with all the screens specifying how each UI screen is interconnected with other screens. It represents — in an easily understood, visual way — the application’s functionality and workflow.
We developed the AWB as a way to combine separate planning documents related to user experience: wireframes, which are primitive screen layout mockups, and flow charts showing how a user moves through the app to complete various tasks. When we work with clients, we’ll often print out the AWB at a large scale to tack on the conference room wall, so all the stakeholders can see the UI at a glance.
The AWB also facilitates collaborative relationships between our team and our clients. It has become an integral document in our development process that captures the client’s input on what the app should do and how it should perform. Mapping the UI in an systematic fashion lets us confirm that we have interpreted the needs correctly and points to aspects that need clarification. The AWB almost always sparks questions among product managers and marketers and reveals other things they need to work out internally. It surfaces additional specs and requirements at a point in the design/development process when they can still be easily incorporated in the project scope.
Our clients tell us the AWB significantly benefits our collaborative process — because it helps even non-t2ch-savvy stakeholders visualize and understand the experience of using the touchscreen or software. It elevates discussion around the product and identifies issues they didn’t previously know they needed to address.
As the project moves forward, the blueprint remains a touchpoint for designers, engineers and stakeholders. UI designers and developers use it as a guide for how the clinician will use the application; they can envision the steps in the workflow or testing process and understand how each step leads to the next. The blueprint also functions as a benchmark for testing the software. It becomes part of the toolkit we hand over to the app developers, along with a library of visual assets and basic specs.
Our Software Architecture Blueprint Saves Time & Facilitates Regulatory Approval
Completed early in the cycle of designing a medical device interface, the architectural wireframe blueprint can safeguard against project costs or timelines spiraling out of control. Because it diagrams the full user experience, it raises potential problems before you invest in development time. The AWB helps our clients scope their software development, which minimizes risk.
Most important, thoroughly mapping out the user experience helps ensure that the product attains regulatory approval. Medical device manufacturers often focus on getting the physical design of the device itself just right — and overlook the UI. But the software is an essential part of the product’s safety and efficacy. If it is not fully baked when you take the product into summative testing, it may not pass — and then you have to redevelop the software.
Designing the user experience and UI for a medical device isn’t like designing one for a mobile game or consumer app; requirements are much more stringent, and product teams need to allow ample time for planning and development. Designers and developers who come from traditional tech companies are used to working in an agile way, building the app as they go along. In medical technology, the development process requires a more methodical approach such as the waterfall method. We can show you how our architectural wireframe blueprint ensures that the process yields a better outcome.
