My partner’s sister is getting married in October this year (congratulations Catriona and Darren 😊) and recently she asked me to create an app to allow her guests to RSVP for the big day.
Most of my side-projects are based on ideas of my own and made up users, so I jumped at the chance to create something for real stakeholders and users.
In this post, I would like to take you through my thought process behind designing the app, showcase the components I created, and share my design process from a developers perspective, in the hopes that other developers may learn from this project.
In a future post I will discuss how I turned these designs into reality by building the app using React & Firebase, so stay tuned for that!
What are the high-level requirements?
I started the process by sitting down to figure out what exactly the application needed to do. Given that my partner’s sister is in no way familiar with how software is created, I had to treat this process with care. My approach was to get her to visualize herself using the final product.
“Imagine you type in www.mysuperweddingsite.com. The page loads. What do you see? What do you need to be able to do?”
“I need to see the venue and date. I need to be able to RSVP.”
Our initial conversation can be summed up into something like the above.
Users don’t think in terms of flows and pages. They think along the lines of I open this app and it lets me do this thing.
How did I proceed from there? I set about filling in the blanks by iterating. Iteration is an indispensable skill for designers and developers so I was glad to get lots of practice during this process.
“OK. Let’s imagine I’m John Smith. How do I find my reservation?” — Me
“You type in your name and it pops up.” — Stakeholder
“What happens if there are multiple guests in John’s party? Do they all respond individually?” — Me
“No. John will reply for everyone as a group.” — Stakeholder
“OK. What information do we need to know about John? We need to know if he will be attending, and anything else?” — Me
“We need to know which of our meal choices he would like. We also need to know if he will be attending our after party and if he has any specific dietary requirements.” — Stakeholder
“Great. And when he’s finished responding, where does he go from there? Is there anything else he needs to do?” — Me
“He would need more information about the day. Directions, transport, local hotels, etc” — Stakeholder
At the end of this conversation, I had a basic idea of what I needed to create.
- Users needed to be able to access basic information about the event.
- Users needed to be able to retrieve their reservation by using their name.
- Users needed to be able to enter reservation information for themselves and the members of their party.
Who are the users?
Next, I set about creating some personas to help me cover a range of needs for the application.
John Smith — Inexperienced web user. Has never used a wedding RSVP app before
A significant portion of the users expected are relatively inexperienced on the web. The extent of their internet usage would be comprised of visiting a limited number of websites looking for basic information. Searching for and using a news site for example. John Smith would have little to no experience interacting with a site that requires multiple forms to be completed, and complex sequences to be followed.
Jane Doe — Experienced web user. Has never used a wedding RSVP app before
An equally significant number of the users expected would have advanced experience of using the web. Jane Doe could be described as the kind of user who grew up using technology and would have no difficulty performing any moderately complex actions online. Jane is a frequent online shopper and is familiar with filling out multi-step forms, and has no issues with following sequences on a site. However, Jane is unfamiliar with RSVP apps/sites, having never used one before.
Joe Bloggs — Experienced web user. Has used a wedding RSVP app before
Similar to Jane, Joe Bloggs is an experienced web user. However, Joe also has experience using RSVP applications. Joe is a frequent user of sites like Meetup and EventBrite.
What are the use cases?
With some personas in mind, I set about drafting a list of situations in which they would use the app.
- New user — Can attend. Wants to RSVP.
This user comes to the site with the sole purpose of filling out their response. This function will need to be easily accessible from the home page.
2. New user — Unsure if they can attend. May want to RSVP.
This user comes to the site to find information about the event before they fill out their response. This led me to believe that important event information would need to be available on the home page and it would need to be easy to get to the RSVP flow from wherever that information is being viewed.
3. Returning user — Has RSVP’d. Wants to clarify details about the event.
Very similar to number two. This user needs to access event information, again reinforcing my belief that this information should be accessible from the home page.
4. Returning user — Has not RSVP’d. Wants to RSVP on this visit.
Essentially the same as number one. I decided that even if the user has visited below, there would be no functional difference for this use case on return visits.
5. Returning user — Has RSVP’d. Wants to review their response.
For this scenario, we have allowed users to re-enter the RSVP flow but instead of providing responses, they are shown the details they provided previously.
6. Returning user — Has RSVP’d. Wants to update their response.
Since meal choices and attendance numbers have to be confirmed in order to organize bookings, we decided that a user’s first response was final. Because of this, a user would be shown a read-only view of their responses, the same as use case 5.
What do the flows look like?
From the use cases, I was able to come up with a set of pages and how they would take the user through the application.
From the home page, the user can access all the critical information they need. They will be presented with some basic information upon landing, such as date and venue information for the main wedding, and they can access additional information on a separate page, or the RSVP flow to enter/review their information.
What colors/fonts do I need?
Things were starting to take shape. I was ready to start designing components based on some sketched wireframes I had put together. However, before designing the components, I wanted to create a color palette and choose the fonts.
Normally I would design in grayscale first and add the color later. In this case, however, the scope was limited enough that I believed I could skip that step. For more on why you would design without color first, check out this excellent article.
The main goal we wanted to achieve with the application was to get people to respond. I decided that a minimal color palette would suit our needs best.
I wanted to design something with as little distraction as possible, where the color we did use would stand out enough to lead the user though the flow we had designed to achieve our goal.
The grayscale colors would dominate most of the application. The primary green color would be used to draw the users attention to important actions and to add a splash of color where the design started to feel bland.
The primary color was also chosen based on the theme of ivy which would run throughout the entire wedding.
The red and orange colors are for error and warning messages only and were intended to be used very sparingly.
For the primary font, I chose Rubik and the secondary font Cookie. The primary font follows the minimalist style found throughout the design, and the secondary font adds a little bit of flair and contrast to keep the design from becoming bland.
What components do I need?
Based on the information gathered so far, I knew enough to be able to draw up some rough sketches of the screens that would be needed. From there I was able to deduce that I needed: button, input, radio, text-area, accordion, and navigation bar components.
What do the pages look like?
Finally, we were ready to start putting everything together 😃. With the flows designed and the components created, composing the pages was a straight forward process.
Notes on the pages
- The pages above are missing some graphics, pending work from an artist, and require some wording changes, but they are pretty close to the end product.
- The pages shown above are not the first designs. These are the versions after a few iterations of gathering feedback and making updates. Unfortunately, I made all my changes to the same file so I can’t show that progression here. Lesson learned! 🤔
- We ended up creating two separate information pages, one for each day of the wedding. The original flows shown above grouped all of the information together, but we found that in practice this led to a very busy page.
- As I mentioned above we aimed to minimize distraction by using a muted color palette. You can see in the above designs that we used the black and green colors to provide contrast in order to guide the user through the application. Our main goal was to get people to RSVP so you can see that all of the color used tries to coerce the user into completing that process.
Where do we go from here?
Having a design is one thing, but having a working application is entirely another. Allowing the stakeholder to use a live site may unearth future changes to the design, as will technical decisions and limitations.
My next step was to get something up and running as quickly as possible, in order to allow us breathing room for changes that might need to be made.
In my next post, I will discuss the development of this application using React, styled-components, and Firebase.
If you have any comments or suggestions for improvement on either the process or the designs themselves, I would love to hear them in the responses.
Thanks for reading!