#8 Design & Interactions
Sketching and Paper Prototyping
This is the 8th article in the look back through the Professional Diploma in UX Design course by the UX Design Institute. Just yesterday I received notification that I passed the final exam, so pretty excited about that. Now to finish up these articles and really get stuck into creating the portfolio. I have been playing around with GitHub pages, Google sites, and Adobe Portfolio so far. I’m liking Google sites for its simplicity, Adobe Portfolio for its polished final look, and GitHub pages for its versatility. I’ll come to this in a separate article altogether I’m sure after I complete it.
The project overview
I was excited to get stuck into this project. After completing the numerous research and analysis tasks that just about all required formal documentation, it was a nice breather to come to a more open and creative project. With this project I could use my research and analysis to further develop ideas for the app’s design. Sketching out these screens can really get your mind working to visualize the app, just as with sketching out previous documents such as the user flow — it’s a great starting point. More relevant here with the Interaction Design project as you can really get to test out and see how your flow diagram is working out. I’ll get into detail of what worked best in my case~
Process
As pictured above you can see I began in the sketchpad with some smaller sketches (multiple screens on one page), then on pre-printed mobile template paper. This was good to work with, to get practicing with the scale and seeing how elements would fit onto the screen at near real scale. I also tried these on an actual handheld card prototype to see how it would feel in my hand while pushing the buttons and so on.
However all of these methods so far did not give an easy overview of the whole flow; a constraint for new ideas. So just like the printed template was dotted (squares), I went out and bought a small notepad. The paper was thin enough to see through to the next page. So with this, I could easily sketch out the next screen one after the other, just as you would do as a child with the corner of your your notebook or school book and make an animated bouncing ball or matchstick man.
This was easy, quick, and it kept me in the sequence planned from the previous Flow Diagram. You can see a knife there on the board. That was to cut each screen out soon after creating a small sequence. This is what really allowed for creativity. I like to work on the wall (or door in this case) to get a real idea of what I’m doing. Working on the wall keeps that scrapbook, mind-map feel and opens up a whole new world of thoughts.
The Screens & Interactions
Getting the screens up on the wall really was key to a solid workflow here. Also, having the printed flow diagram and customer journey map was helpful to constantly refer back to while sketching.
At first I sort-of crudely taped the pages up on the door (was stuck for space on my small office wall). As you can see the pages were moved around a bit. I hadn’t completed all of the screens so far. Once I found a good order I began to cut out the screens tighter towards the line. I kept some changeable elements to the sides; such as overlays, menus, keyboards.
A few screens in and I could get some ideas of how a user would interact with this flow. I kept some notes next to screens on mini-post-its. By having this up on the door I could see which screens were linked and get a clearer sense of how a user will move through the app.
I used one color to outline areas to be interacted with or that were important.
Menus
Below, are the menu ideas for the hidden slider hamburger menu, and the overflow overlay menu.
- The hamburger menu contains just about everything possible within the app — and so is only accessible from the home screen.
- The overflow menu is a contextual menu that changes depending on where in the flow you are.
Here at the search stage, it shows currency and language; options a user would want to change at the beginning of a search. Admittedly, the save progress option is a little premature here. Customer service is required and can be accessed at any time. Deeper interactions of these options were not further researched. Only the top-level flow was the focus of this project, though I wanted to add in how a user may change settings along the way, if need be.
In paper prototyping you can play around a lot with different UI features. One visible below is the shadow. Control the amount of shadow you want with the amount of tape used. Useful in further imaging how the end product might look.
Originally, I was set on having overlays or modal boxes for a lot of the screens. Though with a little research online and chat on the UX Design Slack channel with some of the mentors there, I found that it’s just as effective to have a complete new screen for something such as above. It lessens the chance for any accessibility problems later on. Though, there are instances later where the modal boxes were actually effective.
I experimented a little by cutting and replacing elements here. The center image shows how I expected the screen to be presented before entering Passenger Details. The modal box is outlined in blue. It seems reasonable to use a modal box here as the function is important at this stage, useful to the user. Control is also important, so I want to give the user the ability to take this away, should they want a clear screen to enter their data.
By slicing a few elements here I imagined the passenger 1 input area to animate/snap up in place of the Modal box, should the user cancel the Modal box. The final prototype later will demonstrate this.
Sliders
For the above calendar view, I wanted an easy way to access the following months. Prior to the above screen sketches, I did have static buttons to navigate through the months. It was quick to edit this sketch and try out the slider above with just 2 slits, one on either edge of the screen. And there, the paper prototype actually becomes a functional piece that’s easy to demonstrate and work with later when prototyping in software.
The Problem Areas
The search results screens above did not seem such a problem at the time as it did later on when prototyping in Adobe XD. These screens, as simple as they look have a lot of information to fit in. The information, the hierarchy, the layout, emphasis, and just about everything on the screen is one of the key areas in my opinion to take care of during this project.
Airlines vary in their delivery of these search results. Some overcomplicated it with too many options. Some gave too much or incorrect and confusing information. My objective for this area was simplicity, as much as possible. The flow should be intuitive. On the initial search results screen, the customer should be able to say “Oh, yeah, that flight looks good. Times are good, stopover acceptable, price is good.”
Upon selection the customer should be given the option (control, again) to view more information about benefits and details of that specific flight. An Accordion box was to be used for the ‘see more’ option. If the customer didn’t want to ‘see more’ then they could confirm their flight selection by pressing the very visible and commonly positioned ‘choose flight’ button. Alternatively a back button is present.
Also illustrated above in the Search Results Screens is the contextual overflow menu. It’s different here than on the previous search screen. You have the ability to Save Progress and Share Flight Details. The Save Progress idea is just an idea, and thinking back, this should probably be done via an auto-save feature. That’s for another day, though.
Ticket class screens took a good few iterations to get where I wanted. The sketches did provide a starting point. After finishing the high fidelity prototype I did find that I should have spent more time (even more!) at this stage of the booking. It was probably, the most problematic area to design. The final version of these Ticket Class Screens did look quite different to the above sketches. These sketches are meant as ideas either way, and not solid, final designs. I’ll discuss the changes in detail in the next article.
One thing that did remain from the above Ticket Class Screens sketches is the price information. It was obvious from research that this is something inconsistently provided from the competitors; realtime price updates, and visible on every main screen from flight selection to the price summary before payment. This is expandable, with detailed pricing information within.
Input Screens
Passenger input was required before any extras were added. As mentioned above, the option to Log in or Sign up was provided, via modal box, to speed up the process. The Passenger 1 input area is expanded by default. When the user selects Passenger 2, the Previous Input area is contracted.
This whole area went mostly as planned in the final prototype.
You can see above in the image on the right, the overflow modal is giving the contextual option to sign in or log in. In case of change of mind after canceling the previous initial modal box giving that option.
The above is an input screen for phone number. Note that it doesn’t have any irrelevant characters. Straight to the point. Each input area should provide the relevant optimized keyboard; email, numerical.
Extras
Adding extras were kept to the one screen. That was Baggage and Seating, in a familiar layout and functionality to the previous screen with text entry. The Slider on the top of the screen has the same functionality as the previous Passenger Input and Calendar screens. Now names are added to further clarify who needs extra baggage and seats. s you can see below the final iteration did away with the slider here as there was sufficient room on the screen to display everything. I will further discuss this in the prototyping article.
Extra baggage is clearly presented, with large buttons for easy selection, and price updated accordingly on the bottom of the screen. In the final design just ‘CONFIRM’ was not used. It was ‘Confirm Additional Baggage’ to be more specific.
Seating selection was a fairly complex screen to develop. I spent time with this one to fully think through the process and design.
As you can see above, I stuck to the plan. Here again a model box was justified for ease of correction. A new screen would not be optimal for seat information display.
The seat selection was followed by the Summary Screen, which concluded the project flow.
The Outcome
The customer journey map previously outlined some features to prioritize and keep in mind, and also gave an idea of how a user may flow through the app. The flow diagram gave me a technical, but not definite, outline of the actual flow through the app. This interaction design method of sketching out the screens and really thinking abut how they connect and how the user will interact was very productive. It helps the designer further conceptualize the overall customer flow through the app and develop new creative ideas for design. I did spend a little longer with this than I expected originally, though I was mostly happy with the outcome. It added another layer of cement (hmm…) to the foundation of the design and provided a loose framework for interactions within that design.
I put together a basic interactive prototype using the sketched screens. This was done int he space of 30 minutes in Invision. For rapid prototyping Invision is definitely more convenient than the likes of Marvel App. The use of the C key can create interactions as you are resizing objects or sketches. View the Lo-Fidelity paper prototype here~
Up next will be the Hi-Fidelity prototyping article.
Thanks for reading. And Happy Christmas! 🎄
