Section 3: Design & Prototyping

9.3.1 The “Why”: A Picture Prevents a Thousand Errors

In the previous section, we established that a flaw in the requirements is the most expensive mistake in software development. The Design and Prototyping phase is your first, best, and cheapest opportunity to find those flaws. A written requirement, no matter how carefully crafted, is always open to interpretation. When a pharmacist writes, “The system should clearly display the patient’s allergies,” what does “clearly” mean? Does it mean a small icon? A red banner across the top of the screen? A pop-up that interrupts the workflow? Ten different people will have ten different mental images of what that requirement means.

The design phase eradicates this ambiguity. It translates the “what” from the requirements document into a tangible, visual “how.” By creating wireframes, mockups, and prototypes, the team creates a shared vision that everyone can see, react to, and critique. This is where your clinical expertise becomes a powerful design tool. You can look at a mockup of a CPOE screen and immediately see that placing the “override allergy” button right next to the “accept order” button is a catastrophic design flaw that will inevitably lead to errors. Finding this flaw on a static image and fixing it costs virtually nothing—it’s a matter of moving a box in a design program. Finding that same flaw after the system has been built and deployed could cost a patient their life.

This phase is the bridge between the abstract world of written specifications and the concrete reality of the final product. For the informatics pharmacist, this is the moment you move from being a translator of needs to a shaper of workflows. You are not just providing requirements; you are actively co-designing the tools that your colleagues will use to care for patients, ensuring they are not just functional, but intuitive, efficient, and, above all, safe.

9.2.2 The Language of Design: UI vs. UX

To provide effective feedback, you must first understand the two core disciplines that govern the design of any system: User Interface (UI) and User Experience (UX). These terms are often used interchangeably, but they are fundamentally different concepts. Mastering this distinction is crucial for articulating precise and actionable feedback.

User Interface (UI) Design: The Look and Feel

UI design is concerned with the aesthetics and presentation of the product. It’s the visual part of the system that the user interacts with. UI designers are responsible for creating a consistent, visually appealing, and clear interface. They make decisions about:

• Color Palette: Using colors effectively to create visual hierarchy, indicate status (e.g., red for errors, green for success), and ensure brand consistency.
• Typography: Choosing fonts, font sizes, and font weights that are legible and effectively communicate the importance of different pieces of information.
• Iconography: Designing or choosing icons that are universally understood and clearly represent an action or concept.
• Layout and Spacing: Arranging elements on the screen in a way that is balanced, uncluttered, and guides the user’s eye to the most important areas.
• Interactive Elements: The specific look and behavior of buttons, dropdown menus, sliders, and other controls.

In a pharmacy context, good UI design means: The “Discontinue” button looks distinctly different from the “Renew” button. Critical lab values are displayed in a bold, red font. The font on the MAR is large enough to be read easily by nurses in a dimly lit room.

User Experience (UX) Design: The Entire Journey

UX design is a much broader concept. It is concerned with the user’s entire journey as they interact with the system to accomplish a goal. It’s about how the system feels to use—is it logical, efficient, intuitive, and satisfying? A UX designer is less concerned with the color of a button and more concerned with where that button is placed in the overall workflow. Their goal is to make the system as effortless and error-proof as possible. They focus on:

• Information Architecture: Organizing and structuring content in a logical and predictable way, so users can easily find what they are looking for.
• Interaction Design: Defining how the user moves through the system. How many clicks does it take to accomplish a key task? How does the system provide feedback after an action?
• Usability: Ensuring the system is easy to learn and use, and that it helps users avoid errors.
• User Research: Understanding the user’s needs, goals, and mental models through techniques like interviews and observation (the very things we discussed in the requirements section).

In a pharmacy context, good UX design means: The five pieces of information a pharmacist needs to verify an order (drug, dose, patient, labs, allergies) are all present on a single screen, eliminating the need to click back and forth. The process for ordering a TPN walks the prescriber through a logical series of steps, preventing them from ordering an incompatible combination of electrolytes.

9.3.3 The Design Toolkit: From Blueprint to Interactive Model

Designers use a progression of tools to move from abstract ideas to a concrete, testable model. Understanding the purpose of each of these “artifacts” will allow you to provide the right kind of feedback at the right time.

Artifact 1: Wireframes (Low-Fidelity)

A wireframe is the basic blueprint of a screen. It is intentionally simple, using only boxes, lines, and placeholder text to represent the layout and structure of the interface. There are no colors, specific fonts, or images.

Purpose: The goal of a wireframe is to force everyone to focus on the core issues of layout, information hierarchy, and the placement of key elements, without getting distracted by aesthetics. This is the time to ask questions like:

• Are the most important elements (e.g., patient name, allergies) in the most prominent positions?
• Is the grouping of related information logical (e.g., are all the lab results in one section)?
• Is the flow from one step to the next intuitive?

Artifact 2: Mockups (High-Fidelity)

A mockup is a static, full-color, high-fidelity representation of what the final screen will look like. It includes the actual fonts, colors, icons, and branding. It is not clickable or interactive; it is essentially a picture of the final product.

Purpose: The goal of a mockup is to get feedback on the visual design (the UI). Now is the time to ask questions about aesthetics and clarity:

• Is the color used for warning text distinct enough from the color for normal text?
• Is the chosen font legible at the size it will be displayed on a typical clinical workstation?
• Is there enough white space on the screen, or does it feel cluttered and overwhelming?

Artifact 3: Prototypes (Interactive)

A prototype is a clickable, interactive mockup. While it is not connected to a live database and doesn’t have full functionality, it allows users to click on buttons, navigate between screens, and simulate the actual workflow of using the application. Modern design tools like Figma and Sketch make it relatively easy to create sophisticated prototypes.

Purpose: This is the most important artifact for getting clinical feedback on the user experience (UX). By walking through a realistic clinical scenario using the prototype, you can uncover major workflow and usability flaws before a single line of code is written. This is your chance to “test drive” the application’s design.

9.3.4 The Pharmacist’s Role: Champion of Clinical Usability

Your role in the design phase is to be the relentless champion for the end-user and the unwavering guardian of patient safety. You bring the clinical context that designers lack. To do this effectively, you can use a set of established principles known as Usability Heuristics.

A Pharmacist’s Guide to Nielsen’s 10 Usability Heuristics

Jakob Nielsen’s 10 general principles for interaction design are a foundational element of UX design. They are not specific rules, but rather rules of thumb or guidelines. By internalizing these heuristics and translating them into your pharmacy practice, you can provide feedback that is grounded in established design theory, making it far more powerful and effective.

Masterclass Table: Clinical Application of Usability Heuristics

Heuristic & Icon	Principle	Good Pharmacy Example	Bad Pharmacy Example
1. Visibility of System Status	The system should always keep users informed about what is going on, through appropriate feedback within a reasonable time.	After submitting a complex TPN order, a message appears: “Order sent to pharmacy. Awaiting verification.” The user knows the system received the order and what the next step is.	A pharmacist clicks “Verify.” The screen freezes for 10 seconds with no loading icon or message, then refreshes. The pharmacist doesn’t know if the order was verified or if the system crashed.
2. Match Between System and the Real World	The system should speak the user’s language, with words, phrases, and concepts familiar to the user, rather than system-oriented terms.	A button to stop a medication is labeled “Discontinue,” a term every clinician understands.	The button is labeled “Terminate Process 501A.” This uses developer jargon and is meaningless to a clinician.
3. User Control and Freedom	Users often choose system functions by mistake and will need a clearly marked “emergency exit” to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.	A pharmacist accidentally discontinues the wrong medication. There is a clear “Undo” button that immediately reverses the action and restores the order.	After accidentally discontinuing a med, the only way to fix it is to re-enter the entire prescription from scratch. There is no easy exit from the mistake.
4. Consistency and Standards	Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.	The “Save” button is always a green circle with a checkmark, and it always appears in the bottom right corner of every screen in the application.	On some screens, the save button is a green circle. On others, it’s a blue button labeled “Accept.” On another, it’s an icon of a floppy disk. The user has to re-learn the interface on every screen.
5. Error Prevention	Even better than good error messages is a careful design which prevents a problem from occurring in the first place.	In the CPOE system, the route selection for vincristine is a dropdown menu that does not include “Intrathecal” as an option, making it impossible to order this potentially fatal route.	The route field is a free-text box, allowing a tired resident to accidentally type “intrathecal,” which could lead to a catastrophic error if not caught by the pharmacist.
6. Recognition Rather Than Recall	Minimize the user’s memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another.	When adjusting a warfarin dose, the patient’s most recent INR results are displayed directly on the ordering screen.	The pharmacist has to memorize the INR from the lab results screen, then navigate to the ordering screen to enter the new dose, hoping they remember the value correctly.
7. Flexibility and Efficiency of Use	Accelerators—unseen by the novice user—may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users.	A new pharmacist can use the mouse to click through the menus to find a medication, while an experienced power-user can type “.LIP20” as a keyboard shortcut to instantly bring up Lipitor 20mg.	The system forces every user, novice or expert, to go through the exact same 5-click process to order a medication. There are no shortcuts for common tasks.
8. Aesthetic and Minimalist Design	Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.	The medication verification screen shows only the critical information needed to make a safe decision. Secondary information (e.g., billing details) is available but hidden behind a tab.	The screen is cluttered with 50 different data fields, including the patient’s home address and insurance information, making it difficult for the pharmacist to find the patient’s weight and renal function.
9. Help Users Recognize, Diagnose, and Recover from Errors	Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.	Error Message: “Max Dose Exceeded. The ordered dose of 200mg exceeds the recommended maximum daily dose of 150mg for this medication. Please review the dose.”	Error Message: “Error #508B: Parameter out of range.” This is meaningless to the user and provides no guidance on how to fix the problem.
10. Help and Documentation	Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation.	A small question mark icon next to the AUC/MIC calculator opens a pop-up window that explains the pharmacokinetic formulas being used and links to the hospital’s official vancomycin dosing policy.	The system has complex functionality with no embedded help. To understand how to use a feature, the pharmacist has to leave the application and search for a 300-page user manual on the intranet.

9.3.5 Conclusion: The Pharmacist as the Conscience of the Design

The design and prototyping phase is arguably the most creative and collaborative stage of the entire SDLC. It is a period of intense translation, where the dry, textual world of requirements is transformed into a vibrant, visual, and interactive solution. As an informatics pharmacist, your role here transcends that of a simple subject matter expert. You become the conscience of the design, the advocate for the user, and the guardian of the patient.

Your deep, almost subconscious, understanding of medication use processes allows you to see what others cannot. You see the potential for error in a poorly placed button. You feel the cognitive burden of a cluttered screen. You anticipate the frustration of a workflow that requires one too many clicks. By mastering the language of design—of UI and UX, of wireframes and prototypes, of usability heuristics—you gain the ability to articulate these insights in a way that technical teams can understand and act upon. This is a profound responsibility. The decisions made in this phase, often with little more than drawings and interactive mockups, will directly impact the safety and efficiency of patient care for years. By actively shaping these early blueprints, you ensure that the final product is not just a technological achievement, but a genuine tool for better, safer medicine.