Tell it like it is,
In a way they want to hear it.
Party Planner is a web application that helps restaurants and bars book their available spaces online.
Party Planter is a responsive/adaptive web application that allows restaurants and bars to manage a profile to advertise unbooked spaces for events and parties. The web application will have role-based authentication and an API that can be used for native development down the road. This document will outline all pages and functionality of the site.
For business, administrators will have the ability to read and edit locations and user account information. Location managers will be allowed to edit only their profile information and associated locations. Registration, log-in, and password-reset functionality should exist as functions of the API.
When browsing the site, anonymous users can search and filter locations. The search criteria will be a geo-coded address and radius. Predictive search should be used to display location suggestions while typing. Location-based results will be returned with a set of filters on the left-hand side. Filters will be defined in UX discovery and data modeling.
The Party Planner project can be divided into two parts: a CMS dashboard and a consumer-facing website. One biggest concern in the ideation phase was the website’s search function when anonymous users browsing the site search and filter locations. Predictive search results are based on geo-coded addresses and radius. Users can further narrow the results by using the left-side filter. The user can to select multiple filters to narrow their search, similar to e-commerce filtering. The page refreshes using AJAX upon search or filter action. Searching and filtering are done via a search provider such as ElasticSearch or Solr. This helps with performance and scaling the result pages in the future.
During our user interviews with six potential customers, we discovered an interesting fact: Men had a harder time finding locations than women, and they also were more hesitant to ask friends for suggestions. Even if they could figure out the search function, they still felt less sure when making decisions. Their decisions were more affected by how cool they thought the location was than how far away it was. That is, they didn’t mind traveling more for a fun weekend event.
I considered two common consumer user cases: Users who have a clear idea about where and when they’d like to host an event can go ahead and type in a restaurant’s name with direct or fuzzy search; users who aren’t as sure can start searching by topic. Popular locations will be listed on pages with aimless search.
Aligned with the consumer flow, here’s how it’s reflected on wireframes.
From a quick interview of three location managers and some online research, I determined their daily tasks relating to reservations: Check, approve, decline, or adjust booking info; track booking status; publish a venue's updated calendar and booking status; manage budgets; and update advertising keywords with current menu and discount. The image below shows the flow.
The location manager’s dashboard contains analysis, a to-do list, a calendar, and an inbox built in. The dashboard is complicated for a couple of reasons — a hotel or restaurant chain can have multiple location, plus, in each location, there are multiple rooms with different capacities, and each room has a different status (booked, pending, or unread). It will be important to display this information in the right place with right hierarchy and provide enough flexibility for location manager to edit.
I’d like to highlight the “open hour” selector in the last wireframe gif. This is an insight view of the dashboard for location managers. Here they can set individual times for each party room and different operating hours. They can also add more than one time period, so they will have enough time to clean up and reset the space before another party arrives. Or they can set their holiday schedule for when the office is closed.
During user testing, we received feedback on the traditional cost range system (from $ to $$$$) and realized it wasn’t necessary to toggle between “group” and “individual.” The dollar sign signifiers are now part of the lexicon thanks to Yelp, OpenTable, and other sites, and we are confident that users can implicitly understand these ranges without explanation. This makes the results less complex.
Titles like ”Events We Host” sound limiting should be left more open-ended, like “Recent Events Here,” for example.
Other features include age gating, which assures accounts that parties are all (or not, depending on the party/venue) at least 21 years old on the search page, because it affects the searches/results and users should confirm one more time in term and conditions before they are able to submit the booking request. (Users should confirm once more in the terms and conditions before they are able to submit the booking request.)
BEFORE
AFTER
My biggest challenge was lack of resources. I was given a little insight into the technical planning but nothing related to research, goal, or design direction. I realized it was time for me to propose and sell my idea to the client and reach out the the resources I already have for research, creation, testing, and iteration. Design is an organic process, and different designers approach each concept and its translation to wireframes or visuals in different ways. You have to find the process that brings out your personal strengths and with which you are the most comfortable. Understanding users, how they operated before using your product, and their daily behaviors are equally as important as design itself.
Thank you.
Soon we'll be in touch.
Oops...
A problem occurred while sending your message.