Paper Prototyping

Using all of our previous research data and data analysis results, we had defined a clear set of user goals and the tasks need to complete these goals.  For our first iteration, we carried out a series of task analysis exercises before each team  completed there own rough paper prototypes which we then refined it initial working prototypes, and finally a low fidelity first iteration for user testing

Key issues / Actionable Goals

To recap five of the most important actionable goals where as follows

  1. Improved Booking – The current journey is unnecessary complex and includes unnecessary complex functionality such as the ticket and food selection
  2. Homepage layout refinement – The home page of ‘Movies @ Dundrum” suffers  from information overload, poor mapping of controls, lack of separation between various areas
  3. Improved Feedback on Site-  failure to explain important information, lack of user feedback, no booking summary on the order payment page. Missing and hidden content, interruption of user flow
  4. Site architecture – core site navigation difficult to understand with use of unfamiliar terminology and poor categorisation of content
  5. Device Responsive – Site is non-responsive and across other devices and is designed for the desktop.

User Journeys

We had already created three journey maps one map of the current journey which detailed the current  booking process (fig 1). A second and third map where also created the first of which was a high level simplified journey (fig 2) and the second a more detailed low map of the booking process (fig 3).

Fig 1 : Low level current journey map (view real time board)
Fig 2 : High level proposed journey map (view real time board)
Fig 3 : Low level proposed journey map (view real time board)

The initial journey map allowed us to investigate the current situation and identify where we might be able to make improvements to support the user in achieving their goals. The second and third maps where to allow us to understand as a group how we thought the new user journey might work. These gave us a guide and starting point we could work from as a group while brainstorming using our paper prototypes.

Information Architecture

Using the data we obtained in our card sorting exercises we created a number of iterations of the information architecture, starting with real time boards. We also created a HTML version of the information architecture which can be viewed here (the B option can found under Home). Unfortunately, we did not have time to test this with real users. We had also come the conclusion that the B option although very original and creative was not workable. We eventually opted for option 2 below, which was a combination of the card sorting results and team input.

Information architecture, option 1
Information architecture, option 2

Initial  prototypes

(Note: I will discuss my own paper prototypes here )

Our first round of prototyping was carried out using paper which allowed us quickly brainstorm as many possible solutions to the problems we had identified. All the below prototypes where designed with a 960 grid framework in mind. The 960 grid was developed and refined for the web by Nathan Smith and is an attempt to streamline web development workflow by providing a standard set of dimensions based on 960 pixels. It comes with predefined guttering, padding, spacing and uses a 12, 16 or combined column layout.   It has been adopted by many major frameworks such as Bootstrap and Zurb Foundation , and should make it reasonably easy to make the prototype responsive across all devices.

Home Page Vs #1

The first rough prototype for the homepage (fig 1)  was an attempt to get the process started and to begin to flesh out the idea of reducing the number of screens to complete the booking process while at the same time keeping it clear and easy to understand.

  1. The area in this section was an attempt to combine the image carousel/hero slider and the movie and date time section into one area. The reason being it allowed for the advertising of movies and the booking process to remain clearly featured. Which would have hopefully addressed the key tasks of browsing through movies and booking tickets.
  2. Area two would hold the list of movies with further movies available below, off screen. These would be updated based on the search criteria selected in area one.
  3. Area 3 was meant as to contain the some adverts that are currently on the ‘Movies @ Dundrum’ website.
  4. Area 4 was to contain the the core navigation.
Fig 1:  Home page, Desktop Option 1

Home Page, Desktop Vs #2

Besides refining and cleaning up the overall design there were few changes in this version (fig 2).

  1. Area one changed the core navigation from a straight horizontal list to a series of tabs, this was later rejected as it was felt it was a poor metaphor and would not reflect how the actual page would work which was to reload the whole screen.
  2. Remained as is.
  3. Area three, the filter/search option, was separated from the carousel and replaced the advert in area three from the first version. This was done to more clearly define it. It was imagined that the search function would allow users enter as much or as little data as they had. With the addition of data the remaining option lists would be refined depending on the data entered in the other two. If the user wished they could simply select view all to have all movies returned.
  4. Remained as is, apart from enlarging.
Fig 2: Home page, Desktop Option 2

Movie Details & Booking, Desktop Vs #1

The first prototype for the booking screen (fig 3), was again focusing on the issue of trying to reduce the number of screens in the booking process, and reducing the jarring effect of page reloads while moving from one page to another. It also tried to address the issue of trust through clearer information feedback.

  1. Area one would contain an image of the movie the user had selected.
  2. Area two contained all the relevant information on the movie itself, including a synopsis. This was later separated out onto a separate page due to the large cognitive load of booking and movie information combined.
  3. Area three allowed the user expand or close more detailed information on the movie.
  4. Area four was to function as an accordion and again addressed the issue of trust by allowing the user move back and forward between the various parts of the booking without having to reload the page. The user could expand and close these areas by clicking the arrows or any part of the title bar.
  5. This area was again to address the issue of users not having enough information during the booking as regards what was booked and how much they had spent. This feature would remain fixed at the bottom of the screen and content would scroll below it, it was expanded on in later prototypes to address issues with space for content.
Fig 3:  Movie details and booking, Desktop Option 1

Movie Details & Booking, Desktop Vs #2

The second version of the booking screen (fig 4) did not include the movie details as it was assumed to be off screen. The main reason for this variant of the screen was to show the accordion expanded and also to try an alternative for the fixed running total in the previous screen (fig 3)

  1. Area one moved the running total to left hand side of the screen, it stayed fixed in potion as the user scrolled giving the impression it was moving with the user. This was later rejected as it would not be possible to replicate on mobile.
  2. Remained as is.
  3. Area three shows the accordion expanded for the food selection. It contains a list deals available.
  4. Area 4 shows the add and remove buttons for each meal deal. These would have interacted with the running total and would allow updates to reflect additions to the booking.
Fig 4: Movie details and booking. Desktop Option 2

Home Page, Mobile Vs #1

As part of the prototyping, I created a paper version of how the desktop home page from fig 2 might work on mobile (fig 5). Again working on the assumption we would be using a 960 grid, the elements on the page simple stack one on top of the other where needed.

  1. Area one would be where the ‘Movies @ Dundrum’ logo would sit.
  2. Area two is how the core navigation would respond when viewed on mobile. It would collapse into a burger style menu which would fill the screen when accessed. Both the menu and logo would sit in a fixed header which content would scroll under.
  3. Area three is the carousel which would simply scale to fit.
  4. Area four is the filter/search option which again would stack and scale to fit.
  5. Area five represents the list of movies.
  6. Area six shows the date selector expanded
  7. Area seven shows the time selector expanded
Fig 5:  Home page. Mobile Option 1

Booking Screens, Mobile Vs #1

The following screen (fig 6) shows the booking screens described in the earlier desktop screen presented on mobile. Again where possible content simply stacks

  1. Remained as is.
  2. Remained as is.
  3. This area contains the movie details
  4. This area contains a description of the movie with the option to view more
  5. Accordion mention option
  6. Fixed running total
  7. Area shows show the accordion expanded for food selection, in reality, this should have run down the screen rather than being cut off.
  8. Area eight shows the area users would click to add a check in the box next to the item they wanted. I felt there was a need to change this from the add and remove buttons on the desktop due to the lack of space which would make the buttons small and difficult to click on.
Fig 006 Movie details and booking, Mobile Option 1

Ticket Booking Screen, Mobile Vs #1

The final screen shows the mobile version of ticket selections screen (fig 7)

  1. Area one shows the fixed header with content scrolling underneath it
  2. Area two shows the list of available tickets and their prices, this greatly changes in the first low fidelity prototype due it not being practical for accessibility point view as it would be difficult to select any of the items
  3. Area three shows how users would add and remove tickets, again it suffers from the same issue as area 2
  4. And finally, area 4 shows a slightly refined version of the running total
Fig 7: Booking Tickets, Mobile Option 1

Other Teams Members Prototypes

The two other team members prototypes can be viewed below.

Before taking the next step of creating our low fidelity pro type we reviewed the various paper types and decided what from each to progress to the next stage.


Leave a Reply

Your email address will not be published.

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑