MEDS is a startup that went live about 5 years ago. Over the years, they have grown from nothing to generating 600 million SEK in revenue last year. The platform they built in the beginning has now become too small for their needs, and the user experience were also outdated. The design was a mix of many different styles. They needed a complete overhaul where everything from technology to user experience and design would be reviewed.
Web: www.meds.se
iOS:https://apps.apple.com/se/app/meds-apotek/id1464666359
My role: UX Lead, UI Lead. Product Owner for the user journey and UI for web and app. Customer analysis, customer journey mapping, conducting customer interviews. Creating hypotheses for testing. Developing design systems, clickable prototypes for testing, designing templates. Conducting A/B testing and creating business cases for any third-party systems that can assist customers in their purchase process.
The pharmacy industry was deregulated in Sweden in 2009, creating the opportunity for private actors to begin providing prescription medicines. Apotea was the first to do so and is the largest player in prescription drugs and self-care. After them, several other actors have emerged, such as Kronans Apotek, Apoteket Hjärtat, Apohem, Apoteksgruppen, Doz Apotek (formerly Lloyds Apotek), and MEDS Apotek. MEDS vision is to differentiate themselves from these other players by being a little more edgy and quirky in their communication and feeling, breaking the norm that a pharmacy must be sterile with green colors. "You should not have to feel sick to shop at a pharmacy."
Although it has been a while since the deregulation of pharmacies, there has not been much progress in terms of how to pick up prescriptions. Here, MEDS is a challenger and wants to develop and simplify how customers pick up their medication.
MEDS largest customer group are women in their 30s and 40s, a financially strong target group who have advanced in their careers, have a good salary, have a family, and are the ones who purchase self-care products for the whole family and collect prescription drugs for themselves and their children. They may also collect prescriptions for elderly relatives with authorisation.
MEDS started their e-commerce business 5 years ago and has been tracking data since day one. Two years ago, they decided to make a refinement of their website and app, primarily due to outdated technology that was not scalable enough to keep up with MEDS' growth.
Golden opportunity with lots of data and customers to create hypotheses from. We defined the most important KPIs such as conversion, AOV, items per order, and more. We built funnels from the most visited landing pages to measure where we were losing customers. We mapped how often customers returned to site and many other data points. All to ensure that we focused on the right things when launching a new site.
We defined insights about MEDS absolute best customer, the one who purchases prescription drugs and self-care products (with the highest order value). However, we faced a challenge with prescription drugs since there are several government regulations that prevent us from using tools like heatmaps, customer recordings, surveys, or other tools we typically use to see how UX works in reality. It was difficult to create and test hypotheses effectively.
Together with MEDS pharmacists, we created several clickable prototypes that we then placed in the hands of a focus group to test the entire prescription flow. This revealed very interesting insights. Without these tests, we would have built entirely wrong solutions, costing us a lot of time and money.
From another perspective, we held workshops with all stakeholders within the organisation, including customer service, IT, procurement, marketing, and even the warehouse to identify pain points they experienced in their daily work with the site and app that they wanted to improve. A lot of information about functionality and other aspects emerged that needed to be taken into account.
We created business cases for the larger and more costly items we deemed necessary. This was to determine whether we could recoup the costs of developing them or whether we needed to scale them back and break them up into smaller steps.
Now that we had a good understanding of the scope for the MVP and had locked it in with stakeholders, user stories were started to be written. Everyone involved was involved in gathering all the necessary information, from top-level down to how they would be developed with levels of acceptance criteria: Must have/ Nice to have/ Save for future. This was done to ensure that everything was documented in a structured way and that nothing was forgotten.
The existing website and app had an outdated and inconsistent design, which had been built by several different agencies involved in the start of MEDS. This had resulted in a cluttered and unclear interface. A new design system needed to be developed to streamline the design consistently for both the website and app. A "Single source of truth" was necessary to simplify for customers, create more trust, simplify the process of creating new modules, and to build the CSS more efficiently and scalable.
.png)
Simultaneously with the design phase, the back-end development was ongoing, and as soon as the design was completed, the front-end was developed in close collaboration between the designers and developers to ensure functionality, UI, and UX. This collaboration also enabled prioritization and compromises on features that could consume a lot of time and were not essential for the initial release, which could then be added to the backlog for future releases.
Testing was done as the sprints were completed. QA was responsible for most of the testing, but with design and front-end involved for UX and UI to quickly solve any issues that arose.
The MVP was launched according to plan, in the middle of summer during the vacation season, which may not have been optimal. However, considering the lower customer demand during that time, it was better as it is the low season for e-commerce. Some critical bugs appeared, but with dedicated developers and others, they were resolved fairly quickly.
With the new website and app, we established good metrics for our KPIs so that we could build funnels and gain clearer insights into how customers were using the site compared to before. We found things to optimize both high and low on the site, from our search function not performing as it should to simple bugs that disrupted the purchasing process. We conducted A/B tests based on hypotheses from the data, sent out surveys to our customers, and had frequent check-ins with customer service to keep our ear to the ground on how the new site was being received. Once the most critical business bugs were resolved, we began looking at the backlog to see which parts should be prioritized for sprints and how to move forward.
The new website performed better than the old one after the critical bugs were fixed. However, in hindsight, the way we did it may not have been the most optimal. Working in a waterfall process where everything was replaced at the same time (all back-end, all front-end, most third-party tools, etc.) and released simultaneously. We probably should have worked more in an agile methodology and iterated forward in smaller parts.