The requirements of the course was to design a fully interactive and responsive user interface project. Each week, we would do a step (or two) of the UX process and we would need to present a live working version of our project at the end of the term.
DESIGNING LAYOUTS, USABILITY TESTING, REITERATING
I took the lead in creating the first prototype and worked with the team to conduct a usability test for version A of the site. After analyzing the user’s feedback, I started creating a second layout we call version B.
FRONT-END WEB DEVELOPMENT
I developed the framework for the site and worked with team members to research the technologies that we were to use for each of the field’s modules, and was responsible for the date inputs as well as developing the best way users were to choose whether they were going on a return/one-way/multi-city trip.
I planned the product road map with the team, delegated the tasks based on the team member’s strengths in the development process, was responsible for code review, and then ultimately pushing the site to production.
The Team & Resource Management
My team comprised of my classmates: Anna, Tala, and Vivienne. We split up the development work by the different features in the booking module, taking into account the team member’s strengths.
We found pair-programming extremely useful:
- The easier it was to communicate
- The faster it was to solve problems
- The quality of code increased
- The number of bugs decreased
One team member created a draft of the persona. In the next team meeting, we evaluated and refined it.
Alex has recently taken over his family business but regardless of how busy he has been lately, he still finds time to plan vacations for his wife and two kids. Alex is an experienced traveler and is always looking for new ways to make traveling more comfortable for his two kids.
The Site Structure
As a group, we used a Page Description Diagram (PDD) to communicate Information Architecture decisions without talking about the visual design. I found this to be really effective as we got to focus on content and feature set and determining a clear hierarchal prioritization, which helped us establish the key tasks of the project.
Based on the PDD, we determined methods of grouping content. As a group, we created a Site Map to organize the booking module’s content that allows users to navigate through the module to select the flight they are looking for.
Using sticky notes, we mapped out the User Scenario, the steps Alex would take to search for flights. This was done as a group in a brainstorming session. We determined Alex’s key steps in blue, comments for the designer in green, ideas in pink, and questions that may arise in yellow.
We envisioned a linear structure for the booking inputs. Using the whiteboard, we drew some Wireframes which represents the skeletal framework of our module. (The text in green being the modules that will display when the field is clicked on.)
The Visual Design
Two team members created the moodboards, individually. In our next team meeting, we evaluated and refined it.
The green and orange hues were from the corporate logo. We concluded that sticking to the brand’s colours would make the overall site design more cohesive and enhance the user experience. The greens are to be used as an accent colour and the bright orange would be used for call-to-action buttons.
Putting “Version A” to the Test
I designed version A with a fellow team member and I created it’s hi-fi prototype of the module in InVision.
I took the lead on developing the UX Research Questions. We sent out our list of questions (including a link to the prototype) to get reactions on version A.
The majority of the people we tested the prototype on commented about the Combined Date Input Module. Version A combined the Departure Date and Return Date selections in one step. The idea behind it was the first click was for your Departure Date and the second click was for your Return Date.
After receiving this feedback, we assured ourselves that changing it a two step process would be much easier for end-users. We started the site development with version B in mind while still maintaining the clean, easy to use and friendly environment.
The Development of “Version B”
We took the linear concept of version A, and split the Departure Date and Return Date inputs, and called that version B. This meant, we could no longer hide the return/one-way selections in the combined date module, so we positioned it above and parallel to the input fields.
A rough coded desktop version of version B looked like such:
See the redesigned booking module in action: shuura.com/eva
I learned that detours such as version A are all part of the process. Had it not been for version A, we wouldn’t come up with version B. The beauty of the UX process is that we can keep reiterating and nailing down the design that best fits the user’s needs.
Sometimes, the AHA! moments come unexpectedly with impeccable timing. In our case, 24 hours before the presentation, a brilliant idea came to mind; When users select “Multi-City”, we don’t want to take them to another page and lose whatever trip information they’ve started filling out. That’s what the majority is doing (over 90% of airlines have it set up that way). If the user clicks “Multi-City”, another row of flight information fields will appear below the original set of fields.
I pulled an all-nighter that night to get that feature set up and running the way we believe Alex would enjoy experiencing the most. It was an incredible adventure and I’m proud of what the team pulled through.