How we improved our email share function
(If Frosty the Snowman had a disco…)
The FROST Team (Fundraising Operating System Two :p) build the giving pages for Comic Relief. As with most applications, we have share functionality built in to allow users to share their pages with their friends to get sponsored and raise more money for charity. We had a hunch that our email share feature was sub-optimal, and we found some data to show that it was only being used by a small percentage of our users.
Our principles for our product are “Simple, Proven and Safe & Secure”. We aim not to work on hunches and opinions, but instead prove our hypotheses through user research and data. So rather than argue about why the email share functionality wasn’t working, we did some user research to find out why users didn’t like it. Without going into too much detail, here are some of the things that came out:
- Whilst Facebook is the preferred method of sharing, Email is a close second.
- Our email share journey was unclear and long-winded – most people preferred to copy the URL from the page and create their own email
- The template email that we built was not personal enough
So we understood the problem, we then needed to find the solution. This process can be tough and unpleasant; if not managed well it can involve a lot of people debating ideas for weeks, and often coming down to the HiPPO (Highest Paid Person’s Opinion). As I said before, we try to get away from this endless debate about opinions, and instead work on a more proven approach that a diverse group of people can contribute equally to. I like to call this process “Discovery” rather than “Design”, as it implies we are finding the right solution together, rather than individuals coming up with it and arguing their point. Here’s how we ran our Discovery session, or “Disco”.
We invited a mixed and fairly large group of stakeholders to the session. We wanted it to be an open session that anyone felt they could come to and contribute, but also that people didn’t have to come if they didn’t really care! We ran it in a communal space in the office to make it easy for people to drop by for a bit. We had designers, developers, product managers and key business stakeholders present. We started by explaining the session, our principles, and of course handing out a few post its 😉
User Story and Research
Our Product Manager presented the User story to the group. He explained the user need,
and how addressing this need would help meet business objectives. He also presented the data and the user research to back this up, which also gave ideas about how the user wants this need to be met.
We then needed to start creating some ideas for the user journey/features/functionality (N.B. not UI design at all at this point). However, we didn’t want to get into a standard “brainstorming” session. As Mary Poppendieck neatly covers, brainstorming often leads to a lengthy debate where only the loudest get heard, and can often take a long time before any collective decision is made. So to make sure we got ideas from all parties, we gave everyone time on their own to come up with their thoughts. People wrote them down or sketched them out, and then after a while they presented them back (as a side note, it was interesting how some people approached this by writing out their ideas in detail, whereas others drew diagrams of journeys – people think in very different ways!).
When people presented their ideas back, the group were able to ask questions, but we tried to avoid any questions about suitability of the idea, complexity of the idea, or how we would design it. The aim was to make sure everyone understood the functionality of each person’s idea(s), and we wrote the title of each unique idea on a separate post it.
This process also created several new ideas in itself. When people were presenting/understanding the current ideas, it was sparking new ideas. These were of course added to post its and explained to the group.
When we had garnered all the ideas we could we needed to understand which ideas were most suitable for us to develop. To do this, we mapped the ideas on a chart with two axes:
- Complexity – how complex it would be to build this feature
- Value – the extent to which it met the needs of the user and the business
However, this could easily turn into another lengthy opinion-based debate, which we obviously wanted to avoid. We also wanted to make sure we got the opinions of everyone (rather than just the HiPPOs and the loudmouths). So we had two main guidelines here:
- We only cared about relativity to other post its on the board. For example, we didn’t
need to discuss how complex something was, but instead whether it was more or less complex than the others on the board.
- We gave everyone a turn, rather than do each post it together. We went round the circle and each person could either move a new post it onto the chart, or move an existing post it to a different place on the chart.
Importantly, when it was their turn, people were able to ask the group specific questions to help in their decision. For example, having developers present helped give guidance on how difficult each idea would be to build, and having stakeholders from the business helped understand the value that would be created.
Once the mapping was complete, it became clear very quickly which ideas were worth discussing/taking forward (those with high value and low complexity). We had two ideas that fit into this quadrant, which we all quickly agreed we should take forward. Some people felt that we should also consider a couple of the other low complexity ideas, so we decided that we would do some research to better understand the value and complexity of these two as well.
UI design – brainwriting!
From the two top ideas that we wanted to carry forward, the higher value idea presented a bit of a UI design challenge. UI design is something that everyone likes to have an opinion on around here, and so we thought we would repeat the brainwriting exercise to gather people’s thoughts on this. People independently came up with their own ideas, sketched them out, and presented them back to the group.
This gave 4 clear options for UI design. We ended the session at this point, before we got into a debate about which was best. Once again, our opinions don’t really matter, all that matters is what the user does with the product. We agreed to mock up the 4 options, and test them with users.
There were many advantages of this session:
- All stakeholder groups felt like they could be involved as much as they wanted
- There were no lengthy debates with minimal outcomes (in fact that was minimal debate full stop)
- We were able to get ideas from a diverse group of individuals – everyone was heard
- Clear actions/next steps were decided with all stakeholders bought in
- Our outcomes are actually feasible to implement
Things that could have been improved:
- It wasn’t clear what “Value” meant. Was it business value? Or User value? Or a mixture of both? We need to define this better in the future.
- People kept wanting to jump into discussing design rather than functionality from an early stage. It could have been more clear what we were trying to map out exactly.
- The “Decisions” section could have spiralled out of control if we weren’t careful. The mapping clearly highlighted four winners, which is good, but in some situations this could be too many to prototype and test at once. Or maybe not?
Overall, it was a really productive session (about 90 mins) that everyone seemed to enjoy and fully engage in. We will be doing it again!