Designing App
I designed an app that aims to help people plan for events by entering a few details and have the app shoot out potential venue spaces for. The app shows the available event spaces depending on the stuff the user inputs. Each event space comes with a prebuilt arrangement for the event space. Well what happens if the user does not like the already built arrangements? That’s fine because users have the option to customize their spaces as well.
Early Iterations
In my early iterations, I understood that I had to focus more on the core elements like the main features of the app instead of the bell and whistles like color. I did not have any colors because I wanted to focus more on the navagiton and elements then color.
The no colors versions of my prototype was very helpful because when I had users test it they focused more on the process then if this color was pretty. A mistake that I made in my early iterations and overall was that even though I conducted user surveys to see what that app needed, i injected my biases into the app I created. It is a very common rule to not design for yourself, but for your user. But I learned that it is hard to do when you are designing something you want. So in my early iteration I built the app based on assumptions. For example, in my special request screen I prompted users to enter in any special requests. However I did not have UI(coding) to properly showcase that capability, so I just assumed people would know that clicking on special requests was the same as writing it. I also had the mindset of simplicity is the best. Which is why I took the elements from my homepage and spread it across 4 screens and just had a search bar on the homepage. I did not want people to be bogged down by details, however I realized I did not add in enough details because many of the users stated that it was a bit hard to navigate at first. This is what I learned when I conducted my A/B testing.
A/B Testing
So I learned while some users liked my simple design, it was still difficult to navigate. I learned this using A/B testing. A/B testing is like testing vanilla vs. chocolate ice cream and seeing which one people like best. Even though both flavors are different, they are both still ice cream. For my A/B test I had use the site UserTesting with 4 users. The original home screen(A) versus the home screen with posted recommendations(B). The reason I had my B screen with recommendations is because I wanted to see if navigation would be easier if users were presented recommendations for their events before they even put in their requirements. In this A/B testing I was able to see in real time how random users reacted to and used my prototype for booking an event space. During the A/B Testing I watched how users were a bit confused with the lack of navigational cues that were given in the prototype. For example, on the A homepage all users said they did not know what to do or that it was an event planning app. This was due to page not saying the app name anywhere and just having the search button. However, navigationally is more than words. I noticed that users had difficulties knowing what was clickable or not due to the words that were clickable not having boxes around them. Or the inconsistency of what was clickable and what was not.
I made these changes later in my prototypes,created with Figma, to solve that problem. Figure 3 illustrates how those little changes made a huge difference. The left screen show inconsistency with the fonts and typeface of what is clickable and what is now. Is “Legend” clickable? Is “OK” clickable? However the right side is more consistent, any word that has a non-black color(except the menu at the bottom) is shown to be clickable.
One last thing, I noticed in the A/B testing was that users preferred the design with recommendations, because it had helped them book their events faster.
Learning Points
What I would have done differently is to focus more about the navigationablity of the prototype more. When I saw users going through the final prototype I noticed many of them were confused on how to navigate the site. Words such as “size” and “size of the party” made a huge difference in how they were able to understand what to do. Also adding boxes around places where the user could click provided useful. I would have also added an extra filter named price since I know planning for events are cost sensitive.
Overall designing the “My Event” app, I learned the importance of laying down key elements first and worry about aseestics later. I also learned that you should not inject any biases when designing, because your intended user might be confused.
Final Product!
There is a link below to the My Event! Tell me what you think!
The Link To My Video