Building Moonpig's app shopping cart
Moonpig customers love our cards but struggle to find them on our apps.
The biggest challenge for an engaged user, is to come for something and not be able to find it. The story of how I designed an efficient, elegant and natural way to display Moonpig's card catalog.
Conducted user interviews, Lead workshops, card sorting sessions with customers. Designed the user journeys, designed the interface. Built prototypes using Protopie and Figma
Me, 1 product manager, 3 Android dev, 6 iOS dev, over two offices one in London and one in Manchester
Our apps are semi-driven by a completely separate back end, which is causing the commercial and merchandising teams a headache. They have to do their work twice. Once on the web, once on the app back-end. The level of effort needed to merchandise products on the apps is 10x higher than the web. So this is reflected on our customers. Less products available and less product updates. Some of our customer have been quite vocal about it (they are right to be).
Recently our back end teams have started migrating their old tech to micro-services which we can now start consuming. The search service is one of them; an end point which was built on top of the web back-end and serves you products upon request. The only way for us currently to access the full catalog and achieve product continuity between platforms.
As part of the project we used several data points guiding us and helping us frame our problem in a more effective way. First we used some of our web data to use as proxy. Second, our app GA data to highlights behavioural pain points and obvious patterns. Third we gathered qualitative feedback throughout user interviews as well as user testings later on.
Some insights we listed out
*key data points are purposely not displayed
As a cross functional team, it is key to generate ideas together. We are all from different backgrounds and bring different perspective to solving a given problem. So I usually lead few workshops to generate ideas, measure their viability and build up confidence in the initiative. Using methods like crazy 8 and silent voting we usually come out with a good picture of what initiatives we can consider and which one should be pickedup and developped.
With buy-in and common understanding throughout the team product and design will prioritise fast ways to reach the testing For the navigation project the task was well defined. We had to test for usability and cognitive load and access to result.
So I created the UI for three variants and prepared my scenarios for testing
Listing out the scope for each concept. I created scenarios around each areas we wanted to learn from. Then built clickbased prototypes which we tested with customers and compared to the current implemented pattern.
|Narrow focus||Broad focus|
|Card||It’s your mum’s 50th birthday. You want to get her a card. Where could you find that?||You want to get your friend a card to cheer him up, as he’s been unwell recently. Where could you find one?|
|Gift||Jack is your nephew and he’s 5 years old. He loves Star Wars and you want to get him a toy. Where would you go to find a suitable toy for him?||Your friend got a new job! You want to get something nice to celebrate. Where would you find it?|
We ran one in-house session with 5 participants and further online sessions using usertesting.com for refinement
|Prototype 1||Prototype 2||Prototype 3|
|User did not notice they could scroll the segment controls until they ran out of options||Users more likely to spot the category that would be most helpful to them.||Noticed more prominence to level 2 of nav tree|
|It seemed there were more options on that layout||Opening sections by default distracted from other available options.||More conveninent for quick drilling down/up in the tree|
|It seemed easier to switch between categories and see what they contain||Button styling overtook the accordion menu.||Preferred a single screen navigation|
|Users failed to realise the buttons they were looking at belonged to ‘for her’ and ‘Christmas’||Suggested for more visual navigation|
Proto 3 was simpler, more elegant and had the most noticeable user performance.
During that phase I created multiple working prototypes and motion video to discuss with engineers and find the best way to implement the pattern.
Depending on the tool I use I can generate fairly precise and granular animations, which makes dev work less risky
Live version available on iOS and Android
Increase in product visibility and productlist impressions Less abandoned journeys as the catalog is more structured and has more products Our AOV should get closer to the web AOV