Planr for IOS - A User Story
Problem Statement
Planr was conceived through the discovery of a common problem often complained about: poor planning.
People seek clarity in their weekend plans but often find ambiguity when others fail to communicate, commit or plan ahead.
MISSION: To be the guiding light in group planning
User Interviews
From the discovery of this problem, I looked to potential users to find out what their common processes and pain points were. I did this through a series of interviews. I interviewed 10 different potential users in my demographic (young adults living in cities) and put together some key takeaways.
Overall users wanted plan details consolidated in to one place. They wanted plans to be concrete so it would be very black and white as to what was happening. They wanted insights on attendance and live editable lists to in order to know the things they needed to make their plans a reality.
KEY TAKEAWAYS:
Users want -
Location, time, details and checklists with accessibility and visibility for all
Competitive Research
From there I dove into competitive research and mainly looked into the tools my users were currently using: Facebook events, Groupme, Googledocs. I determined what these apps were doing right and where they were falling short. I chose to combine and optimize the benefits of using these tools while still focusing on the details my users sought after.
Personas
At this point I felt informed enough to create two contrasting personas. Enter Busy Brittany. She's a school teacher with little free time on her hands. Due to her lack of free time, she prefers not to have to scroll through long group messages in order to be in the loop with her friends. She seeks a straightforward solution to her pain points of feeling unprepared or uninformed.
And here’s social Sam. He likes to make the most of his free time but gets frustrated when others aren’t on board. He wants to be in the know for weekend plans so he can schedule accordingly and do all the things he wants to do. He seeks greater input about the number of attendees, the ability to make new events that he can invite his friends too, and a consolidated chat about the given event.
Busy Brittany can scroll down the Event Feed to see what's going on. Social Sam can plan events and see who's committed with the Headcount feature. He can organize lists of what people need to bring and see who's signed up for them. If either user has any confusion of event details they can message about it in the Event Chat.
From there I mapped user needs to features to get a clear sight of what application would solve my problem. Along the way I discovered a lot of potential features I could implement but were not sought out by my current users. I used the Moscow Method to determine what was immediately necessary and ended up with a planning tool framed specifically for my users.
Busy Brittany can scroll down the Event Feed to immediately see what's going on in chronological order. Social Sam can plan events and see who's committed with the Headcount feature. He can organize lists of what people need to bring and see who's signed up for them. If either user has any confusion of event details they can ask about it in the Event Chat.
Feature Prioritization
One of the main problems I faced was trying to solve other problems simultaneously with a million features. All I saw was all these great features I could add from doing competitive research and seeing what other apps had implemented. In order to narrow these items down further I used the Moscow method. I determined what could be incorporated in future releases verses what was completely out of scope for this application. This method helped me narrow down my requirements to only solve the main problems of my end users.
Usability Testing
I began sketching out my userflows into how they would fit in an application. I uploaded those sketches into Marvel and performed Usability testing. I put these screens in front of three separate users in order to determine if they understood the flow of the wireframes. Users were able to navigate from screen to screen. However, as they communicated their expectations and drawbacks, I found that the design needed to be more intuitive. I determined I needed to add more labeling and a clear direction for users.
From there I began to add fidelity and performed more user testing. I added a Create an Account option on the opening screen and added text to my icons so users were not confused by the actions they were talking when clicking them. The menu bar had a plus icon that confused users so I altered it and added text. One user claimed they would like to see the host of the event and that was added to the Event screen. Most users were confused by the New Event page so it was labeled "Host an Event" and "Post Event to Feed". Buttons and chat received shadowing to show interactive areas to be clickable options. One user pointed out that lists should show the status of completion before you click on them to avoid unnecessary action so "All set!" as well as other key words were added. It was noted that Chats and Lists shouldn't need search bars and should be chronological by dates. Dates and lines were added to distinguish chats. Overall, usability testing allowed me to make the tweaks that made Planr easier to navigate and understand.
