Peer-to-Peer Event Registration Flow
Web/Responsive // Applications used: Sketch, InVision
Objective: Design a registration flow that allows participants to register for the non-profits fundraising event.
Challenges: There were a few challenges we faced when working on this project. One of them being creating a system that was configurable for the non-profit to go in and edit the front-end. We needed to work on creating a flow that allowed them to add locations, teams, fundraising minimums, fundraising goals, etc. in order to work for their event. By talking to non-profit users, we were able to get an idea of what they were looking for and make sure what we were designing best fit their needs. Another challenge was making sure the flow worked for the end users (or participants) that would be using the product. There potentially could be a lot of steps in the flow so really going through and figuring out what could be condensed was critical.
Research: For the research, we worked on doing a competitive analysis on other products similar to the one we were looking to create. We looked at classy as well as Crowdrise to see how they solve these problems. Classy’s approach was very user friendly and simple. They do not allow the non-profit to configure to the level that we were looking for but for creating a simple, easy to use flow they did a really great job. On the other head, Crowdrise, definitely allows for more customization but it got a little tricky because there were lots of options and stuff started opening up below based off of what you clicked above. That made the experience a little hard to follow.
Information Architecture: This step was very important because we have a legacy application that had a pretty horrible IA and we wanted to make sure we were including the features but rethinking how the IA worked. The first step was drawing out the legacy IA and then seeing all the steps and functionality. This is vital in making sure everything is being considered from the research and brainstorming. This is the step that really solidifies all the requirements and makes sure every problem is being considered.
Wireframes/Low Fidelity: For this step, I did a mix of drawing out by hand on sticky notes so I could rearrange and see how the steps worked on paper. This is helpful for me to be able to go step by step for the most common flow to make sure it makes sense. From there, I took the sketches and drew them up in Sketch in low-fidelity (shown below). This was then shared with the stakeholders and discussed further.
High-Fidelity: Once we had settled on a flow that made sense from a business perspective and users perspective, I took the low fidelity and added in the UI to create a high fidelity prototype that I was able to test with users. This step was critical in validating the assumptions we had come up with in the research phase.
User Testing Round 1: For the first round of user testing, I tested on non-profit users that will be setting up these events for their participants. The goal was to show our customers (non-profit) the designs to get initial feedback on initial reactions, things they would change and things that don’t work for them. Some of the feedback included: Including zip code functionality on location page so participants can search by area and not just by city, Wanted more visual elements on the pages and the ability to change buttons/text/headers.
User Testing Round 2: For this round of using testing, I tested on end-users (participants) that would be using the product to register for an event. I gave users a task (walk me through the process of registering yourself and two children) and asked them usability questions. For example, “Where would you enter a discount code?”, “How to login if you already have an account?”, “How would you delete a registrant?” and “How would you edit a registrant?” I also made sure their wasn’t anything they thought was missing or was confusing/hard to navigate.
Next Steps: The next steps are to show the final designs to the stakeholders and then hand off the designs to engineers. There were engineers that were involved in the earlier stages to make sure we were considering scope and making sure this was manageable for them to develop, This is critical in making sure that designers aren’t just blindly designing a product that will be really hard to execute from a technical standpoint.