Final Refinement Design
Click the links and/or images below to access our prototypeMobile Prototype
The audience for our app, We Do, is people who plan their own weddings without a dedicated, paid wedding planner. In order to make sure that our app was as helpful as possible to our potential users, we spent the first phase interviewing people who plan their own weddings and researching the available tools that these people relied on the most. Eventually, we summarized all of this information into the following personas. (A more thorough write up on this can be found on our Needs Analysis brief ).
Sarah is an extremely organized and conscientious bride to-be. She started planning her wedding over a year in advance and values the opinions of people she trusts and being in creative control.
Judy, Sarah’s mom, is a very empathetic person with a focus on helping Sarah stay within her strict budget. She values being able to communicate with Sarah quickly and easily about tasks related to the wedding
Rebecca is a more laid back bride to-be. She started planning her wedding less than a year in advance but feels that she is good at planning, so she’s not too worried about it. Like Sarah, Rebecca values being in creative control.
John is a businessman who has experience planning events and managing people. Despite this experience, he does not feel super compelled to help with the research phase of planning and mostly steps in at the end to help his partner decide between a few options. He doesn’t care much for the wedding planning process, but wants his partner to have as little stress as possible.
With these personas in mind, we decided to aim our app towards people who want to have precise control over the wedding planning process, like Sarah, by allowing users to create a highly personalized experience. However, we also attempted to cater toward people like Rebecca, by developing experiences that are easy to use and helpful with limited customization. Additionally, we tried to support Sarah and Judy’s relationship and John and his partner’s relationship in our design by creating interfaces that encourage sharing and collaboration.
Users' current tools
Currently, people who plan their own weddings are using a variety of online and offline tools to help them through the process. Excel spreadsheets were by far the most common tool used to keep people organized and store information such as cell phone numbers, addresses for potential venues, day-of wedding schedules, and many other important lists. However, these spreadsheets were often extremely detailed and long. They made it hard for users to get a good idea of how far along in the process they were and how much left they really had to do.
Additionally, people have been using a variety of online resources for inspiration and planning advice, such as Pinterest, Wedding Wire, and the Knot. However, many of these resources are overwhelming to new planners as they are often a multi page list of tasks or just a grid of images that all link to other websites. In place of these, users typically end up using a list or spreadsheet system given to them by a friend or family member who has recently gone through the planning process.
Our perception of the problem
There are a lot of moving parts and dependencies that go into planning a wedding. Planning requires a high activation energy to detail the time and action for each task. For users that have never done this before, a wedding planning checklist tells them roughly which month they should start fulfilling each task. However, it doesn’t give a clue of how long each task will take or any additional information the user should know. Additionally, there are part of the planning process that can’t be predicted by a static checklist. For example, some florists may increase their prices if the user wants peonies in the winter, which is offseason for peonies. If the user thought about choosing other flowers or rescheduling their wedding, they might have avoided this price increase, but a simple checklist would not be able to tell them about this. Sometimes users are missing similar guidance about aspects of their wedding such as when they should start planning big-ticket items like venues and catering and what to consider about these items given their circumstances. In current checklist systems, the user has to complete 100+ tasks over 1-1.5 years without knowing exactly how long each task will take. Usually users who want more help with the planning process hire a professional wedding planner. These cost somewhere around $10,000, which is inconvenient or impossible for partners on a budget.
We have designed an application that allows our users to break down and manage their wedding tasks so that they stay on schedule. One of the major design decisions we made during this project was deciding to become a wedding planning “crutch” to our users. As we mentioned before, when we looked the wedding planning applications available, most of them only supported breaking down tasks at a high level. For example, Wedding Wire has a checklist item that simply says “Book a Vendor” and there are no smaller tasks within finding a vendor such as researching food vendors, scheduling a cake testing or visiting X hotel. We wanted to create an app that would allow people to customize their tasks and provide a simple indicator to show that they were on track.
One of the major design constraints we came across was choosing to design for desktop or mobile. Ideally, our users would be able to access this application on both desktop and mobile and we debated heavily which one to design for first. We made a lot of assumptions about our user and assumed because our users were using our app as a wedding planner crutch, they would want to access it on both. For mobile, we assumed this interface would be helpful to our users when they were on the go or performing field research such as going to a dress fitting. In this process we imagine the user would need to upload photos of dress options and record price details on our application. On the other hand, we assumed desktop is more helpful for research based tasks such as finding a DJ or band in the nearby area or following up with guests via email to the RSVP list.
Given the time we had to work on this project and members of our team expressing different desires to design for either mobile or desktop, we decided to split up our feature sets where mobile designs would have on the go tasks with the ability to check them off quickly and progress bars to indicate which tasks users needed to complete first. Desktop designs would deal with more tasks geared towards a lot of typing including sign up, configuration, and research tasks. We blackboxed several features on both designs due to the time constraint, but have thought through what those features would look like if we were to continue this project in the future.
Design Decision Pivots
The change from not recording user's data to recording user's data
From our initial user interviews and research into inspirational designs, we took issue with the all-in-one approach to wedding planning applications. Users frequently mentioned that these applications, most notably Wedding Wire, were too overwhelming to look at with hundreds of tasks on to-do lists and were too rigid and not customizable. In addition, we found users were pulling from multiple sources to help plan and organize their weddings, using wedding planning guides, complex spreadsheets, and Pinterest boards for everything from inspiration to minute-by-minute scheduling for the big day.
This led us to the decision that we should design an application that serves as an auxiliary tool to aid in the wedding planning process. The users we spoke to were either working or in school so wedding planning was happening after work or whenever a free hour could be found. We wanted to optimize the planning process during these times by giving users a clear direction for what they needed to do next. We began designing what would later become our task screen, a screen that gives the user one concrete thing to work on at a time.
To design for these times when users would plan their wedding in between everything else that is going on in their lives, we decided on a mobile interface. What came with choosing a mobile interface was the decision that we would not be soliciting data from our users about their wedding. Users would simply tell us what they wanted for their wedding (i.e. flowers, decorations, a cake, an officiant) and we would give them tasks to do like “Schedule consultations with 3 florists” that they would then mark as completed or not relevant for their wedding.
As we concluded our Design Development phase, users who interacted with our paper prototype were consistently confused about our intentional stance of not recording user’s data. When given a task to schedule consultations with 3 florists, they wanted data on the 3 florists they had already researched to be displayed, with phone numbers for them to call and schedule the consultation. By showing them our app in isolation, the idea that they would be recording data elsewhere and using our app as this secondary helpful tool fell flat. In addition, because we weren’t recording any data specific to an individual user’s wedding, we were never able to ensure that the task we were giving the user would be 100% relevant to their wedding. This led us to a pretty significant reversal of deciding to not record users’ information and not building the all-in-one wedding planning application.
We decided to create an app that would allow for user customization, storing and saving of user’s specific results, and collaboration on the app between different members of the wedding party in order to address our user’s feedback and needs. This decision had a major impact on the app moving forward and allowed us to create an app that is more valuable for our users.
Based on the feedback from both our usability test and our heuristic evaluation, we changed two major experiences to make our app more aligned with our user’s need, as outlined below.
- Dedicated Task Page
Instead of only being able to mark tasks as completed or irrelevant, we incorporated a page for each task that allowed users to store and view more information that would help them plan. To begin, we added the ability for users to add results from either research or visits with different vendors to the app as well as to a Google drive, and we presented these notes and results to them in other tasks pages when the information was relevant. This helped speed the planning process along for our users since all of the relevant information needed to complete a task was all in one place and accessible either through the app or Google drive, depending on what is most convenient for them.
- Adding and Editing Tasks and Categories
One of the biggest pieces of feedback we got about some of our original designs was regarding the inability to add tasks and categories that were an important part of the planning process for one users wedding, but would not be relevant for most users. In order to accommodate people who wanted ice sculptures and elephants at their weddings, we added in the ability for each user to create their own tasks and categories as well as edit existing ones to be more applicable to their own needs. Doing this allows users to rely on our app for all of their planning need as opposed to just being an add-on to their more robust planning process.
Timeline vs. Category
Initially when we designed our app we wanted to create a timeline that provided a list of tasks for people to accomplish per day. When we spoke to our users they mentioned how they preferred if tasks were pre-listed for them and all they would have to do was follow a specific amount each day. For example, Rebecca gets overwhelmed seeing all the list of things she has to do and often does not know how to prioritize. We felt that if we just provided a daily timeline that gave each user tasks to do for that day and allowed them to look ahead at future tasks that it would be enough for our users to feel organize.
However, when we put our paper prototype in front of our users, we realized that people who wanted to view tasks for that day also wanted to see upcoming tasks within the category. For example, if there was a daily task that asked our users to decide on a band or a DJ for their wedding, that user would also want to check up on that category and see what other upcoming or past tasks they had done in regards to the music for their wedding. We gained a key insight in that our users not only valued organization of tasks daily, but also organized thinking about tasks in terms of categories (eg: Wedding Attire, Music, Decorations). Thus there was a need for our user to view their daily tasks and see which categories they were in for the day, and to also access a page where there are tasks organized by category.
"Am I on track?" Progress Bar
Planning a wedding is a stressful process. Users place the details of their wedding into our hands, and we schedule all of their tasks in all of the categories. Therefore, we thought it was important to show them their progress in each of their categories. Initially we thought that showing them the following design would give them a percentile for how much they have completed, and a good idea of how much they have left to complete.
Feedback from our heuristic evaluation stated that it was not clear how we calculated 32%. They also questioned how we weighted tasks. There are some larger tasks like "Research a venue" and some smaller tasks like "Confirm the officiant". There was confusion around how the size of the tasks contributed to the 32% remaining. We also concluded that the value of this bar was knowing a time measurement of how far out they are from the day of their wedding and how far they are from completing the details of their wedding. Most importantly, they want to know if everything will be completed before their wedding. If they are falling behind, then we designed that we should alert them to pick up more tasks, catching up on schedule. Therefore, we redesigned our progress bar, and this redesign produced two designs.
- The specific color of red induced anxiety
- Being compared to other users made the tester feel unnecessarily competitive
- The arch of the progress bar reminds them of a speedometer, which also induced stress
- The specific color of red induced anxiety (same color red as the other design)
- Our users did not like being compared to most users. Our users just wanted to know if they were in danger of not being done on time.
- Users prefered this design because this representation showed how far away they were from the actual date and in the details they needed to plan.
If we were to develop this application, our next steps would include: fleshing out the configuration process, recording information, and adding customization to each category and task.
Currently we have designed that we ask them a series of questions. From their responses to these questions, we would know how far along they are in the wedding planning process, and therefore, what tasks to give them next.We know our users do a lot of research on Google Sheets. Usually, they do the research on desktop. We would want to add the functionality to link with their Google Sheets. We were thinking about displaying their Google Sheets or allowing the information they insert into our application to populate a spreadsheet. Then allow viewing or editing capabilities on mobile, so that when they go consult with a vendor, they have all of their requirements and details on their phone. Some users might want flowers, and some might not. Our application plans to give users the ability to add (and remove) tasks and categories so that they can incorporate details they value into their wedding.