(n.b. most screens that appear are still from exploratory design phases)
A 40-second summary if you're in a hurry
My roles: UX research & design, UI Design
The team: 16-person Agile(ish) team
The client: A cooperative of german pharmacies
Favorite part: Seeing the MVP in live usage
Client research showed that when patients run into basic problems while taking meds (regarding dosage, side effects, precautions, etc.), they avoid referring to the enclosed leaflet. They find the leaflet confusing, and often they don't even have it anymore. Instead, they turn to or call their pharmacist, which takes valuable time from them, and this leads to frustration in both parties.
Our project created a solution that helps users get quick answers and manage their meds, and at the same time increases efficiency of pharmacies and their pharmacists.
User and stakeholder interviews helped confirm the client findings, define user needs, and lay the technological and design foundations: a video content-driven app with an in-pharmacy QR code system. After a first design diamond resulting in two personas and a full functionality map, the next step was defining, designing, and building a viable and functioning MVP. This was then released to users as a beta along with an in-pharmacy paper feedback form. If interested, you can explore it as a prototype recreated in Figma.
A collective of German pharmacies reached out to Bulldog Technology with a tough problem: patients regularly turn to their pharmacist with every minor question, instead of referring to the leaflet enclosed in the packaging. Spontaneous feedback pharmacies have collected from patients said that they find the leaflet confusing, hard to get, and it's the first thing that they throw out anyways.
Our client was interested to find room for improvement on both the patients' and the pharmacies' side: a way to have more satisfied (and reassured) patients, while improving the efficiency of the pharmacies and the pharmacists as well.
Discovery & research
Since we were handed a completely open playing field, as the first step I outlined research questions along which our startup team could conduct interviews with pharmacists (stakeholders) and patients (users).
During the eight, one-hour stakeholder interviews we were not just focusing on their experience or ideas regarding the interactions with patients, but also the larger regulatory picture in their highly regulated pharmaceutical sector.
Users – about two dozens – for the quick user interviews were selected from volunteer patients that had at least one ongoing treatment at the time. In their case, we were interested in the actual difficulties they encounter, and their thought processes and feeling related to these situations.
Some interesting insights
"Leaflets always confuse me... they hide the important parts between rare side effects and long lists of stuff I don't even care about" - Patient feedback. Similar ones kept coming up with other interviewees as well.
"Often, I feel like a robot, I could just record my answers and play it over the phone to the [guy] or send them an email with it" – Quote from a pharmacist.
Defining our solution-space
Based on the interviews, the pain-points uncovered in them, and other findings, I insisted on defining user needs and other requirements that could delimit our solution-space, before working out the fundamentals of the product.
Our requirements ended up falling into three categories:
explicit user needs, e.g. "I need help in knowing what information is really relevant in the leaflet, and what is not"
hidden user 'needs', such as "people look for a human they trust as the source of medical information"
outside factors such as regulations, technology, infrastructure (e.g. nothing can be added to medication packagings, but stickers or writing are permitted)
Deciding on the fundamentals
With all the information collected, our team decided on the core features of the product:
Users absolutely require a human or a 'face' as the source of medical information, and the most viable way to ensure this is by explanatory video content as the major feature – let's not forget, video content back in 2015 was not as trivial as today.
Linking the database, the meds, and the user's smartphone has to be a simple method with low-cost implementation (this ended up being QR code stickers)
Multiple user problems might require features that only a standalone app can deliver
After some discussion, the project managers here decided to split the project into two parts: Design and development of the app remained our project, and content creation from the leaflets as a separate one that required industry-specific knowledge. Biweekly alignment meetings made collaboration effective with two-way feedback on the specific requirements (e.g. the specifics of tokenized database items, video length and format, information categories, etc).
If you're interested, you can watch one of the sample explanatory videos that were recorded here.
Persona creation and user journey
Empathizing is a crucial part in every project, and even more so in such a sensitive segment. Due to external constraints, I proceeded with only a rudimentary persona and journey creation – but even this helped our team a lot in future steps.
The two personas were Mrs. Jones, a family mother in her mid 30's living with her husband, two kids, and his father-in-law; and Mr. Andrews, a widower in his early retirement years, living alone.
You can meet Mrs. Jones and her journey in this video, although the video itself was created a while later as a pitch support.
Side note: most screens that appear in the video are still from exploratory design phases.
Looking back, I should have been more determined on conducting proper persona and journey workshops – our team was more eager than experienced at the time. We got away with it, sure, but a few questions we encountered later (i.e. low digital affinity) could have been taken into account head on.
Also, today, continuing without a stakeholder persona of a pharmacist would be out of the question for me.
Building on the research results, user needs, and the personas, I conducted three workshop sessions together with the developers in order to draft and then finalize the skeleton of the app: the functionality map.
Throughout the subsequent phases, this functionality map served as a blueprint for interaction design, back-end and front-end feature developments, and database requirements.
This was also the phase were a second client validation went through, with super positive returns, and also some valuable advices which were integrated (such as help for situation assessment in case of an emergency).
Since it's a divergent, exploratory phase in the beginning anyways, I started drawing out papes & pen wireframes already parallel to the functionality mapping phase.
The overall design principle was to have a high accessibility layout, accommodating any minor impairments our users might have: bad eyesight, difficulty of precise motor movements, etc. I set the primary touch target dimensions to 1/4ᵗʰ of the screen width (in both directions), which corresponded to around 72px equivalent even with the smallest screen sizes of the time. This grid then served as the basis of the layouts.
The final grid structure was also inspired by Microsoft's flat Metro design language, which receives less credit usually than it should based on its good usability, modularity, and overall aesthetic appeal.
Minimum Viable Product
Our next goal, in the spirit of agile development and design thinking, was to create a working MVP as quickly as possible, so we can get it out to real life users and collect meaningful feedback.
The first step to this was to trim down the functionality map to a core that
still serves the base user need of simplifying the medication leaflet, while keeping all relevant information available;
enables maintaining patient-pharmacy relation, as it is a business need as well as a base to establish trust;
and makes onboarding the easiest possible.
In the process, features that require a standalone app were trimmed, which enabled a switch to a web app implementation for the MVP. This change eliminates a quite significant entry barrier and makes onboarding much simpler as the user doesn't have to install anything.
Concurrently, I also switched the focus of wireframing to follow the outlines of our MVP, by simplifying existing plans where possible.
After the MVP wireframes were consolidated and also validated by the front-end development team, we created a lo-fidelity prototype. The goal was to be able to run a few rounds of in-house testing with predetermined tasks, with two goals in mind:
What do users find missing from the MVP version?
Is the layout easy to understand and manipulate?
The test successfully uncovered some problems with information display and with discoverability. I addressed the former problems by reorganizing and rewriting/adding some textual elements, and taking the decision to draw a specialized icon set. The discoverability issues were ported to the subsequent UI design phase, where it was possible to emphasize affordances and adding more visual clues.
Brand identity & UI design
The two primary colors of the QRVisio branding were inspired by pharmacy and hospital environments where these hues have a proven calming effect. For the UI, I had to extend the palette with a few shades of complementary secondary colors, and some monochrome tertiary colors.
Since the sector in question is special, the design required a specialized icon set that can represent even highly unique meanings such as allergies. This was not something that was readily available, and the in-house test also revealed problems with stock icons. To ensure message clarity and to maintain visual consistency, I decided to start drawing an individual icon set for the app based on the database info that the content project team provided.
The screens for the MVP were finalized by merging the flat Metro-design inspired wireframes and the above components. The overall goal was high accessibility (text elements supported by icons) and large touch targets, and also retaining the brand values of calmness, clearness, and dependability.
The MVP testing was done in three pilot pharmacies, with a wide range of meds that was selected by the client based on criteria they deemed important. All patients buying those drugs received packaging with the QR code affixed, and received the explanatory leaflet, and feedback was collected by two methods.
Several "regular", returning customers recommended by the pharmacists made themselves available for over-the-phone, 10-15-minute discussions on their experience and thoughts about the app and the content. My aim here was to uncover any usability issues (touch target size, understandability), and get their overall impression of the visual feeling of the app.
All other customers were asked and encouraged by the pharmacists to fill out a quick, 10-question survey. While the questionnaire did serve basic usability feedback purposes, it mainly provided valuable satisfaction feedback to product managers.
If you'd like, give the prototype a go :) It's naturally just a mockup of the live MVP web-app, but can still give you an idea of what the users were testing. I recommend switching it to full screen first or opening it in a new tab .
While we did succeed in gathering results in the first testing, I wasn't able to use them for any design improvements, as the project was shelved as you can see just below. These mainly showed that navigation has to be redesigned, and an implementation of a (probably hamburger) menu is almost a must as the more complex product is designed. Native navigation does work, but not well enough. Some icons and text were also difficult to see or read.
On the usability side, users found the core product as valuable, but it did still leave some of them with questions – this could be traced back to very individual levels of information people need. One initial idea we had was to maybe implement some kind of interactive medication leaflet as a "fallback" core functionality, set in between the videos/info panels, and the downloadable full-version leaflet.
Why is there no app today?
We were several weeks into the field test, and we were already getting quite valuable feedback and many motivating results, when Bulldog Technology management announced that despite their many efforts (which actually included us starting to rebrand the app to e-Mediq following some investor concern), the financial side of the project is not sustainable. Thus, the project ended up in a drawer and remains there to this day.
Looking back, there are two major things – aside from a multitude of other learnings – this project and my work in it rewarded me with.
First, this was the first quasi-agile project I have been involved. Concurrent product development in (tangible) product design was familiar to me, but this was where I had the chance to adapt to a methodology that today is an industry best-practice. Later in 2017 when Vodafone Hungary started its Agile Transformation, I was on familiar grounds and my managers could rely on my help in adapting our teams to the new work methods.
Second, this was the first time where I had the chance to completely oversee all aspects of field research and empathize with our users and stakeholders, Getting results handed to you is one thing, getting them yourself is another. Sure, I made plenty mistakes in the process as a developing designer, but since this project I fully value the fact that nothing replaces real-life, first-hand knowledge of your target users, your client's situation, and your internal users/stakeholders.
What Would I Do Differently Today?
A lot has changed in the years since this project, regarding design trends, best practices and such, so naturally the first and last phases of product idea and UI design would be different. Video content creation and animation would be much easier, and we would surely rely much more on emotional design and smaller animations making understanding easier.
As mentioned, a more thorough persona design (including creating a stakeholder persona of a pharmacist) and journey mapping would be two things I would definitely do today. Also, I'd definitely consider a separate accessibility mode for users with impaired vision. This would enable satisfying the special needs of a large group of target users, without compromising the sleekness of the default UI that appeals to the general user groups without such impairments.
Let's talk about the future!
I'm currently looking to join an awesome design team permanently – one that values creative work, iterative design processes, and puts user needs at the same level as business requirements. If you think we would be a good fit, use this form to reach out and we can continue from there with your choice of covid-compatible zoom or a back-to-normal coffee.