Macadamian Blog

Part 5: Winning Prototypes

This is the fifth in a series of posts on Prototypes by Mary Piontkowski and Martin Larochelle. Read the introductory post, Step 1, Step 2 and Step 3

Build a Specialized Team

No matter what kind of prototype you choose, youʼll need a very specialized team to actually bring it to life. Prototyping work, particularly in advance of a trade show or presentation to stakeholders, is fast paced, stressful, and requires specific skills. Not everyone has the stomach for it! The individuals on the team will make all the difference, and they should be:

Passionate
Build the team with experts passionate about innovation and who deeply believe in what you are trying to accomplish. If the project and learning feels like work, the team ramp-up will be slow and managing will be like pulling teeth.

Fast learners
When you innovate, team members wonʼt know everything before they start, but that doesn’t matter if they learn quickly.

Comfortable with Ambiguity and Change
People who can embrace ambiguity and frequent change of direction in the early going will help bring order to that ambiguity to drive things forward.

Specialists For technologies that are more established, find people who know them inside and out. Donʼt start learning Objective-C for the first time if your main technological unknown is a new set of social APIs.

Communicators
Product managers, designers and software developers need to be in constant communication.

Resourceful and Self-Motivated
Team members are either a +10 or a -5. In a prototype context there is rarely an in-between, and -5s will quickly drag your team down.

Further Reading
Winning Prototypes: How to Capture Hearts & Minds of Stakeholders
A whitepaper by Martin Larochelle, Mary Pionkowski, and Didier Thizy.

Part 4: Winning Prototypes

This is the fourth in a series of posts on Prototypes by Mary Piontkowski and Martin Larochelle. Read the introductory post, Step 1 and  Step 2.

Select the Right “Type” Of Prototype

You have a few options when developing a prototype. Will it be a paper prototype or functional code? A throwaway concept or a reusable design and code base? Depending on the strategy and the story, youʼll probably want to choose one of the following prototype “types”.

a. Rapid Prototyping/Demo
Purpose: To demonstrate the feasibility of product idea. This is typically a throwaway prototype often used to get support for a new idea, to validate a new technology, or to illustrate a new concept at a trade show.

Result: Confirmation that the product idea is viable and that it can work. In this case, you donʼt need to present a finalized product. Things can be faked and the code in your prototype might just be reference or sample code that could evolve later. Reusability is not the goal – the design should just be a rapid “best guess”. Basically, youʼre simply showing a design concept at this point.

Tips: To succeed here you need to really focus. Limit the work to one persona. That persona should be the most likely/intended audience of the product and should be specific, i.e. a physician, a data scientist, a CFO, etc. Try to also limit your prototype to one usage scenario – the key scenario that highlights your end-to-end value proposition. In practice, youʼll probably include several scenarios but the point is to keep them limited and clearly defined for the entire team.

b. User Research Prototype
Purpose: To validate the design concept with users so it can be iterated on quickly.

Result: An optimized design concept that is approved by all stakeholders. A user research prototype can vary in fidelity from a paper prototype to a Flash-based prototype. Often, you will do more than one round of prototyping and user testing. This will allow you to update the prototype before moving on to actual product development.

c. Production-Level “Prototype”
Our clients often ask us to “build a rapid prototype”, but not as a throwaway. They want to re-use the prototype design and code as the foundation of their new product. In fact, what they are really asking for is not a prototype at all, but the “first vertical slice” of the project. These types of projects need to be treated with a lot more attention – especially when it comes to design, architecture, re-use, and the inherent trade-offs between building something quickly but that is also appropriate for re-use in production.

Purpose: Validate the software design and serve as a communication tool between the project leaders and team

Result: Working, production quality code that contains all layers of the system and provides at least one usage scenario.

A re-usable prototype is the foundation of your app or product. Both the interaction design and technology choices are almost final. It is not “We are exploring a new direction for our product on Android tablets and getting feedback from customers” but rather “This is the design of the ERP client that we want to implement as a Native Android 4.0+ tablet application. It will communicate with the new version of our backend system for the Q4 release.”

Choosing the right kind of prototype is important, but it wonʼt mean anything if you can’t bring together the people to build it. That’s why you need to take some time to surround yourself with the right people.

Further Reading
Winning Prototypes: How to Capture Hearts & Minds of Stakeholders
A whitepaper by Martin Larochelle, Mary Pionkowski, and Didier Thizy.

Part 3: How to Create Engaging Patient Software

This is the 3rd post in this series. Click here to see Part 1 and Part 2

Drive Patient Engagement
Once you have identified a specific set of primary patient users, it’s time to determine what will engage those patients and keep them returning. What information and features will they value most? How must that information be presented initially and over time? While this information will vary from patient group to patient group, our researchers have compiled a list of the most important guiding principles for driving long-term patient engagement.

1. Present the information that the *patient* cares about
A recent study by Sharp Rees-Stealy found that the four most frequently accessed areas of a portal by a patient differ completely from those accessed by a clinician. In the study, patients indicated they were most interested in booking appointments online, engaging in secure messaging with a provider’s office and viewing lab tests. Your patient research may or may not match those particular findings, but if your interface does not present a clear path to the information patients are most interested in, they can become frustrated and are less likely to interact regularly with the system.

2. Provide *immediate* value to the patient during the interaction
For illustrative purposes, let’s explore how a patient with Type 2 Diabetes might use patient software. If she needs to enter a blood glucose reading, she will not be content to simply enter the data. She will want to identify trends, see correlations with her activity levels or what she ate for lunch, and understand the implications. She may wonder “Should I call my doctor?”, “Is this a normal reading?”, “If not, what should I do?”.

Patients with a chronic illness may deal with a large number of providers and wish to keep track of all of their names, upcoming appointments and recent communications via the software. If your system can provide added value beyond simply housing information, you will be able to ensure satisfaction and uptake.

Kaiser Permanente’s My Health Manager is an example of a system whose features provide immediate value to target users. A table on Kaiser Permanente’s website FAQ, meant to show the portal’s growing user base, turns out to be a wonderful illustration of features that are resonating with users such as online prescription refill, appointment requests and access to health information resources:

3. Ensure that patients can *relate* to the information
In a very real sense, patients and clinicians speak a different language. A doctor can quickly recognize a high cholesterol number, but a patient may have no way to interpret whether a figure is high or low. When designing your interface, implement tools (such as color coding or a dashboard, perhaps) that will help patients interpret and understand the metrics they find in their online file. It’s not good enough to simply reflect data back to the patient — the patient needs to know what that data means and its implications.

4. Include *next steps* and patient goal tracking
While a physician might be content with simply knowing that a future appointment has been scheduled, a patient will want to know when that appointment will take place. Moreover, a patient with a chronic ailment may want to track his progress over time and the ways in which he’s contributing to his own healthcare via exercise of alternative treatments. If a user can see (via visual graphics) that he’s losing weight or lowering his blood pressure, he will be more likely to return frequently to the software..

5. Give patients other reasons to return
Many patients think the idea of patient software “sounds” great, but quickly abandon it after their initial interaction. It’s is worthless if patients aren’t entering data on a regular basis, or using it at all. Consult your persona and user research findings to hone in on areas that give users a reason to come back to the software again and again. These could include:

• An automatic trigger. If a patient has an upcoming appointment with a specialist, the system could send a message via e-mail or phone. Or, if the system knows a patient has Diabetes, it could send reminders to enter a glucose reading.

• Links to existing patient apps, programs and systems. Many patients already use some sort of monitoring device — be it a step counter, a glucose monitor, etc. If a patient is able to upload readings directly from a medical device or mobile phone, that will encourage use and add value by reducing the amount of data entry required.

• Real-time access to health info. If a patient has just finished an appointment but has forgotten the proper dosage for the new medication prescribed, that user will want to check the portal immediately upon returning home. If the data does not appear, the patient can become frustrated. Note that according to the U.S. Department of Health and Human Services, up to 80% of patients forget what their doctor said as soon as they leave the clinic, and nearly 50% of what patients remember is incorrect.

• Provide access to communities and forums. Patients often seek out other patients with a similar ailment for advice and comfort. If possible, consider ways to link your patient software to popular communities and forums such as http://www.patientslikeme.com/ or, at a minimum, recommend appropriate forums based on the patient data.

• Allow mobile access. A user who has just checked his blood pressure at a drugstore may want to immediately input that data instead of waiting until he gets home. Consult your patient personas and user research to determine whether a mobile version of your patient software would be of value and, if so, which components of the software would be most useful.

6. Address specific user fears/concerns
Your user research activities may uncover specific patient concerns or reasons why patients have not used patient software in the past. Some common concerns include:

• Privacy/Security: “Who will be accessing my data and what information will they see?”

• Payment: “Will I need to pay some sort of subscription fee?”

• Technology: “I’m not good with computers — what happens if I make a mistake or need help?”

• Accessibility: “I’m not well enough to access the system regularly.” Or “I don’t have access to a computer.”

• Patient/Doctor Relationship: Some patients may be concerned a portal will hinder communication with their physician. For example, if I spend time inputting information, will my doctor rely on this data rather than a face-to-face meeting or telephone conversation?

7. Make the software “first-use-friendly”
It is particularly important to design the interface in a way that first-time users can access what they need quickly and easily. Patients, in particular, can be easily turned off by a bad first impression and may not return.

To ensure an interface is usable for both first-time and repeat visitors, consider engaging experts to perform interaction design and usability testing— particularly for the primary, high frequency or critical tasks. Usability experts can test an existing design and provide recommendations on how the UI can be improved.

Our white paper, 9 Usability Mistakes Your Team is Probably Making (and How to Fix Them) offers insight in to the most common usability errors in the Healthcare industry. Even if your solution addresses the needs of its key patient groups and actively engages them, it can still fail if it is ignored by clinicians. Our next recommendation examines the ways in which you need to encourage patient software buy-in from clinicians.

Part 3: Winning Prototypes

This is the third in a series of posts on Prototypes by Mary Piontkowski and Martin Larochelle. Read the introductory post and Step 1 here.

Weave The Story

It is possible to create a stunning prototype that will win hearts and minds – and, most importantly, budget and approval – in a short timeframe. Weaving the story is one of the steps you’ll need to do this successfully. Here’s how:

Identify key use cases that can best demonstrate the business strategy and the differentiated product offering. Remember to consider the important factors to the audience, how this affects the story you tell, and how the prototype fits in.

The story could be fleshed out using a customer experience map, a series of personas, user stories, usage scenarios, or whatever medium your team is comfortable with that fully encompasses the details of the experience. This is your illustration of the vision and overall experience for the product.

From there, select which use cases are necessary to build and which can wait. Often just one use case, implemented exceptionally well, is more powerful than a multitude of features half-done.

Design and development teams need to work very closely together to create this product definition. Ideally, someone with a user experience design background is in a role to clearly document these details to help keep everyone on track and help the product manager gain consensus with other stakeholders.

Further Reading
Winning Prototypes: How to Capture Hearts & Minds of Stakeholders
A whitepaper by Martin Larochelle, Mary Pionkowski, and Didier Thizy.

Part 2: Winning Prototypes

This is the second in a series of posts on Prototypes by Mary Piontkowski and Martin Larochelle. Read the introductory post.

Get Clear on Strategy

At its core, strategy is about prioritization. You need to choose and spend time on the key priorities that are going to make the end product AND the prototype a success – nothing else.

Most prototype projects donʼt start out this way. Managers often assemble a long wish list outlining their need for lots of features, an impressive visual design, fast development, re-usable code, etc. But to ensure a successful prototype, you need to:

1. Develop a very specific strategy
2. Make sure everyone on the team – developers, designers, managers – understands the strategy
3. Ensure that little or no time is spent on anything but the key priorities to bring the prototype to life.

It's critical to make sure the strategy for the product offering is clearly articulated and understood by all stakeholders. Usually, the prototype strategy, which also needs to be clearly defined, is targeting a different audience than the product strategy. For example, a product may be intended for consumers, but the prototype might be created for executives in your organization with an end-goal to secure budget, or to key clients to gather early-stage reactions and feedback.

So how do you actually determine the prototype strategy and key priorities? Start by tying things back to your business goals. Are you trying to make a business case to integrate WebRTC technology into your products to result in more seamless, cross-platform customer service? Are you trying to showcase the Metro design of your new Windows 8 migration to get customer feedback?

Tie the features and use cases in the prototype back to business goals. You should be able to summarize it in one sentence or one slide. We donʼt mean this as a general philosophical idea. We mean it literally. Nail this one slide and you empower everyone on the team to make the right decisions independently, and quickly.

Further Reading

Winning Prototypes: How to Capture Hearts & Minds of Stakeholders
A whitepaper by Martin Larochelle, Mary Pionkowski, and Didier Thizy.