Four years after launching Papier, 10% of UK weddings were using our printed invitations. With revenue growing 2x year-on-year, there was clearly an appetite for the Papier Wedding. However, there were other trends emerging...
While there was still a place for printed invitations, our customers were beginning to send save the dates and gather guest RSVPs online. The benefits were obvious: speed, cost and administrational efficiency. But too often the tools being used were underwhelming: plain emails, ugly ad-ridden templates, complex website builders – none of which really matched a customer's wedding theme.
There was an opportunity to step into this gap. We would provide a way for wedding organizers to communicate with and collect info from their guests.
I led a cross-functional team on this project, bringing together commercial, customer service, creative design, and my own product design teams to deliver Papier’s first software product.
With the help of our customer service team I conducted a series of in-depth interviews. We learned more about how our customers organize their weddings and uncovered some key Jobs to be Done. These would provide a north star for the project, and we would refer back to them often. The Jobs to be Done approach places value on the emotional context around customer behaviour, which helps us understand what drives decisions.
Wedding planning takes months. It was important to consider the points at which a guest list manager/digital communication tool would provide value during this process. I created a user journey map, laying out major wedding planning events and decisions. This map highlighted key moments in the Papier printed stationery customer journey too, such as sending printed invitations and thank you notes. This helped the team contextualize the Jobs we were solving for, and later proved useful to our marketing team when it came to communicating the value proposition to our existing users at various stages in the customer lifecycle.
I believe the most valuable insights come from people who are actually using your product. So, armed with just enough research, it was important that we produce something we could ship to users and learn from quickly.
We knew that each wedding was unique, and that we would encounter myriad edge cases in the future. To begin with though, there were a few universally important moments we tried to focus on: onboarding, 'message' creation, and the guest experience.
The tool we were building was only valuable once a user had created a guest list, so adding guests was a vital part of onboarding. Our research also told us that wedding organizers often had their own spreadsheets already, so we made the option of uploading a spreadsheet of guests a priority. We flagged either guest list building process as potential pain points.
Users would be able to create web pages that they could share with guests via email or a sharable link. We discovered that while this system provided a flexible solution to user Jobs to be Done, it presented a naming challenge. The same page creation process could result in a save the date message, a request for mailing address, or a detailed multi-question RSVP form. Technically all of these were web pages, but users didn't want to make a one-size-fits-all microsite - they wanted to send e-invites, or to print a link to a place their guests can RSVP online. We settled on 'Messages', and resolved to educate users within the tool through presenting them with step-by-step choices as part of the process. We would revisit this after collecting more feedback.
Organizers would be able to share their messages in two ways: email, and a sharable link. The link in each email sent was specifically tied to that guest, but a 'public' link would be accessed by anybody. As a result we built a guest identification system - once clicking the link, a guest would have to type their own name in, which would allow them to submit RSVP replies.
Looking back, the assumption that users would choose the sharable link over the email delivery option was incorrect, and we spent too much time designing and building this user flow.
There were two sides to this project, and two distinct user groups: the wedding organizers and the guests.
For the organizers my team and I stuck to the Papier UI design system, with some friendly illustrations to warm up the initial onboarding steps and empty states. We made space for hints and tips as a future addition - we knew each wedding is different and organizers would want to use the tool in unique ways, so articles and how-to's could provide a helping hand.
The guests would have a more colorful experience, one chosen by the organizer and based on Papier's physical stationery designs. As part of this project I designed an internal tool and a template system with which our Creative team could create ‘messages’ that matched our paper range.
Papier's Digital Wedding Tools launched right around the time Covid-19 hit. Wedding events across the globe were cancelled indefinitely and revenue from the wedding category vanished.
The goal of this first version was to learn from our customers and iteratively build on what we had launched, both in terms of features and design. Unfortunately world events meant a shift in Papier's strategy away from weddings and towards stationery. Our team changed focus and we were unable to improve much beyond our first release.
However, Papier now has a strong, unique initial digital offering to learn from and build on, ready for when wedding events return.