First Low fidelity Prototype

As a team we decided to look at various prototyping tools before beginning. We reviewed the various solutions we had developed from our earlier paper prototypes and established how we intended to maintain consistency while working on both mobile and desktop versions of the prototype while working remotely from each other. This did prove to be

a challenge but one which we dealt quite well in my opinion.


First Low infidelity Prototype

Before we began Ali as part of her early paper prototyping had taken the time to create a mobile prototype in Invision. This gave us another point of reference to work from as a team and also gave us our first exposure to a prototyping tool and kept us focused on a mobile-first approach. As we were all coming from various backgrounds there was much discussion as to what tools to adopt and this  provided us with a base level to work from and got the experimentation and debate started .

What we used

All team members had various suggestions as to what to adopt. I personally had a preference for a tool called Hotgloo having used it in the past. Hotgloo sits somewhere between a HTML Prototype and Invision. It does not require any animation to be undertaken as all of its  controls and UI elements behave as per HTML controls and UI elements reducing the time to completed prototype. It also supports the 960 grid as well as templates for various devices. Unfortunately it does have  rather step learning curve and it was felt it might not be best fit for what we wanted.

We also took the time to look at moqups. Again this supports the 960 grid and is reasonably easy to get up and running with. Where it did fall down was the fact that it could not produce fixed elements and creating any type of interaction required that we mock each state of the interaction, also we encountered problem with mobile mockups. These issues on top of the fact none of us had used it and so it had not got a champion, meant it also failed to be taken on.

Adobe XD, the new kid on the block and a tool most were eager to try out proved to have a lot in its favour. It was very easy to use, once you took 30 mins to review it. It allowed you have all your prototypes on one large work area making it very easy to switch between your various art boards for comparison. It also supported the 960 grid. Most of us where already familiar with many of its shortcuts, and being Adobe it was just very usable.Where it did fall down down was again the fact that it was missing fixed elements, if this feature had have been in place it would have been the only contender. To remedy this issue we opted to use it in conjunction with Invision.

Invision was chosen as it provides integration with Adobe XD art boards making it very easy for rapidly integrate changes into the working prototype without having to do much more than upload the same filename. It also supported multiple device templates and allowed prototype not only be embed on webpages but also usable on a mobile phone, which greatly simplified user testing and added an element of realism.

With choices made we began to prototype

How we worked

NOTE: Due to the volume of work involved and the fact that work was split across three team members I will only address in detail my experience of prototyping the desktop part of the redesign while lightly touching on the other team members work at end.

Before beginning we agreed on a shared UI library across mobile and desktop. Danielle managed to source a UI library which covered nearly every possibility and gave us a huge leg up when it came to consistency. From this Ali developed an overarching style guide (fig 1) which we used to keep us aligned on styles particular to our prototypes, such as where we needed to create custom styles which the UI library did not cover.

Fig 1: Style Guide (Full size version)

Both myself and Danielle took on the task of creating the visual elements of the prototype in Adobe XD, neither of us had used this application previously so this proved to be a great learning experience. I took the desktop prototype and Danielle the mobile. Meanwhile Ali began work on creating the site architecture which was derived from the earlier card sorting research.

Ali was also took charge of quality control for any of the artwork being uploaded to Invision, as she was also responsible for creating the various interactions and linking the screens in Invision. This proved to be an ideal configuration for the team as it ensured consistency across all our work with Ali catching many minor inconsistencies which collectively would have been extremely jarring.
With myself and Danielle providing the final piece of quality control by reviewing the completed prototype at its various stages, we ensured that consistency was maintained from start to finish.

For communication, we used a combination of Google hangouts, Slack and in-person meetings. Although we did not complete any actual finished work when meeting in person they were useful for touching base and brain storming ideas.

What we produced and addressing 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 design for desktop.

For our first iteration we produced a total of

  • 49 Desktop Art boards
  • 41 Mobile Art boards
  • 2 working prototypes
  • 1 Style guide

Homepage layout refinement

For simplicity I will address this issue first. Below (fig 2) is the homepage in its entirety

Fig 2: Home page

Starting with the core navigation at the top of the page, based on our card sorting we greatly simplified this navigation. The logo was also integrated into this, the logo also allowed the user to switch between the swords branch and Dundrum branch which removed the landing screen forcing users to select there desired location, we envisaged this picking up the user location form the browser and saving this for repeat visits.
The search and user account options were added to the far right. The search option fulfilled users requirements for easier find-ability of content while the user account provided the point of entry to the requested (by both management and users) user account functionality.

Fig 3: Core Nav

In (fig 3) below you see the carousel, we felt it was prudent to keep this as its a recognised norm across all competitors sites and the current ‘Movies @ Dundrum’ website. We added the ability for the user to cycle through the images through the use of the three dots and also added a book now call to action.

Fig 4: Carousel

In fig 5 you can see the main body of the page, this first contained two call to action buttons these provided options for users who were unsure as to what movie they where booking or new those that made a spur of the moment decision of an unplanned trip.
The ‘Top films’ section was aimed at those movie goers who attend the cinema to see major releases such as our primary persona Luke.

Fig 5: Body

The image below (fig 6) shows the bottom half of the page including the footer. The bottom section contains advert which cycle while the footer contain secondary information.

Fig 6: Footer

The final section is the quick pick feature, this is essentially how the booking feature from the original paper prototypes was progressed. We felt it was to overwhelming be placed at the top of the screen. The competitor analysis suggested that placing it as a fixed feature at the bottom of the screen which content would scroll under, was a well-established norm.

Fig 7: Quick book

Improved Booking – Stage 1

The improved booking system was eventually broken down into the following five hi level stage process at it simplest, with a further sub step depending on the scenario.

Beginning with when the user has left the homepage for the ‘What’s on at Movies@Dundrum’ page. This page shows a list of all list of movies (fig 8) filtered depending on if they selected the ‘Whats on Today ‘ button or ‘View all Movies’ button from the homepage.

Fig 8: Whats on

At the very top of the body content of this page are two filter options, one which allows the user filter by the day and the second a custom filter option ‘Filter by: All Films & events’ which is described further on. Fig 9 shows the custom filter configured in the off state. We realised later that the call to action for the filter button was weak and needed to be addressed.

Fig 9: Whats on Filters – off

Fig 10 below shows the custom filter configured in the on state. This provided a number of options to the user and in particular, addressed our secondary persona ‘Rosemary’s’ issue of wanting to be able to find a child suitable movie quickly while under pressure.

We had initially intended to implement a filter or search option on the homepage, but after a first attempt at trying to add this to the homepage with all of the required functionality needed to full fill users needs it led to it becoming overly cumbersome and began to clutter the homepage. This was basically repeating the problem that the original ‘Movies @ Dundrum’ website had, information overload on the homepage.

Fig 10: All Movies filter – on

The next screen shows a Movie within the list of ‘Whats on’where the “All Times” button has been enabled (you can see this is in the bottom left of fig 10 above). This causes a seven-day list of all times to appear below the movie details. Each individual time is an actual button and when clicked will take the user the tickets selection screen.
Each button also contains a short abbreviated information icon above the time showing if the movie has hard of hearing enabled or is a mezzanine option available, below the time is the type of screening that is available.

Fig 11: All Movies -Times Expanded

The final screen before the user move to the ticket seat and food selection is accessed if the user selects the title of the movie, either from the home page or from the ‘Whats on…’ page. The user will be presented a with a page with information relating only to that particular movie. This information is identical to whats shown on the ‘Whats on…’ page.

Fig 12: Movie Details

Improved Booking – Stage 2

The actual selection of tickets and adding of food was shown from our research to be one of the most important areas needing a redesign. The current ‘Movies @ Dundrum’ website suffered form many issues. Such as a confusing array of ticket options, meal deals combined as part of the overall ticket, hidden or missing functionality and poor feedback to the user in the form of informational text and order review.

Fig 13 below shows the first part of this stage of the booking process in its entirety as one page. We opted to progress the accordion functionality from our earlier paper prototyping sessions and selected the below layout for the following reasons.

Firstly it addressed the issue of lack of trust and confusion, by having the key stages in the booking process accessible from one screen. This allowed the user move back and forward through the available options without incurring a confusing page load, which was shown in the user observational research to be a problem.
Users could see at all times exactly what movie they had booked as the movie details are maintained at the top of the screen.
At the bottom of the screen, the issue with trust is addressed as informational feedback through the use of a running total which is fixed to the bottom of the screen

I explain all of these features in further detail in later sections of this post and will address the issues of Improved Feedback on Site, Site architecture, Device Responsive independently.

Fig 13: Booking Process

Ticket Selection

The ticket selection process had proved to be a particularly confusing issue for all users, with the use of unfamiliar terminology, causing confusion…

“Large tickets, that’s confusing, what does it mean”

Combining of tickets and food offers into one ticket and providing no information as to what was been offered….

“So, this is for …? the fee is for …?”

And the removal of certain deals for no clear reason after the user had previously seen them via another booking…

“Wheres the child kid pack one”

We felt to combat these issues that it was first necessary to separate out the food and ticket offerings and identify what exactly was available (fig 14). Ticket selection was then made clearer by firstly segregating tickets by type, such as “Adult”, “Child” and “Student” and then assigning the various pricing options i.e. “VIP”, “Standard”, etc. This segregation of tickets and food and then further categorisation of pricing was a dramatically different approach to the current site which presented all the information related to food and tickets as one. To further address the informational issues we also included descriptive text below each pricing offer

Fig 14: Booking Process – Tickets

Seat Selection

Similar to the tickets we once again broke out the seating option (fig 15). The screen icon was moved to the top as it had appeared off-screen for certain users on smaller screen sizes. We also opted for simple squares to represent seating as the icons used previously had caused confusion with users trying to figure out which way the seating was pointing. A simple legend was also included

Fig 15: Booking Process – Seating

Food Selection

For the food selection (fig 16)the offerings were also segregated into the various meal deals and again with further segregation provided through the various pricing options “Large”, “Medium”, etc. Buttons where included on the food section as it was felt it needed to confirm that various different meal deals had been added, preventing the user from accidentally adding these additional options.

Fig 16: Booking Process – Food

Improved Feedback on Site

The issue of information feedback and certain cases missing information proved to also be quite a serious problem with it scoring second highest on our categorisation matrix from our observational interviews, with a value of 23.

To address this we took a number of approaches, the first of which was an easily accessible order status fixed to the bottom of the screen, fig 17 and fig 18 show these both in the closed and expanded state. When expanded the user can easily edit any of the options already added to their order without losing any of the other added items no matter what stage of the booking process they return too.

Fig 17: Feedback – Order status closed
Fig 18: Feedback – Order status open

As part of our solution to the poor informational issues, we also included informational modal windows. The first of these in fig 19 shows the informational modal for tickets types, this had been a common problem across most users who were unfamiliar with the tickets types available. The second of these in fig 20 was to inform users when events had taken place in the background, in this case when food had been included as part of a ticket option, this was the one ticket option where food was included as part of the ticket. These feedback solutions where further expanded on in the final iteration in the form of inline messages.

Fig 19: Feedback- Information modal
Fig  20: Feedback- Information modal

The final part of our solution to user issues with trusting the site and being unsure as to what was purchased was to completely overhaul the final payment screen. The current site had one payment screen with a simple order total. As well as redesigning the layout we expanded on this page by including the order summary, and also highlighting the booking charge at the end of the page. We put the acceptance of terms and conditions front and centre and disabled the final payment button until these had been accepted.

Fig 20: Feedback- Order review

On the final page the user has presented once again with a full recap of the order and the option to send tickets as an email.

Fig 21: Feedback- Order complete

Device Responsive

As stated previously due to the large scale of this project it was not possible for each of us to cover all areas of the prototyping process and hence far I have focused solely on my input into the project. What follows is a brief summary of the mobile and tablet prototypes developed by Danielle and Ali respectively, I will address only the key differences between these and the desktop version.


To begin with, the standardised UI library and style guide ensured that there was consistency between all prototypes.The mobile prototype made similar use of the 960 grid by stacking its elements where possible and resizing elements as long the result was still usable on a mobile.

The first issue we encountered was the cinema location selector on the desktop version sits in the top left of the core navigation. We found on mobile that this was not possible as there just wasn’t the room. The remedy to this was to include it at the top of the body content of the homepage, fig 22 The second image fig 23 shows the re-positioning of the filter functionality and the re-scaling of page content to fit the screens width. On the desktop the filter functionality was set on the far right, again this was not possible on mobile.

Fig 22: Cinema selection drop down (full size)

Fig 23: – Resizing & off screen scroll  (full size)

The following screens show how the 960 grid facilitated the stacking of elements and resizing of content areas.  The filter functionality (fig 24) although containing a large number of options stacked quite easily on mobile and was also adapted to fill the full screen. Fig 25 shows how content width was re-scaled and positioned on the movie details page, whereas previously the movie details and video set side by side on desktop they are now stacked.

Fig 24: – Filter Stacking

Fig 25: – Content Stacking

In certain scenarios, it was necessary to have elements of the interface fill the full screen of the mobile phone. Fig 26  shows a modal window in full screen mode while fig 27 shows we adapted the quick book functionality to function on mobile phone. Initial trials  to enable the quick book functionality on mobile phone in its desktop configuration proved extremely difficult to implement and it was felt that a full screen option would better address this.

Fig 26: – Full screen modal

Fig 27: – Full screen quick book

Similar to the quick book function the order summary (fig 28) was also changed but instead it would also allow a user move directly to the billing stage (fig 29), while still providing the option for the user to edit the booking using the edit buttons

Fig 28: – Order summary off

Fig 29: – Order summary on


Engineering the site prototype for the tablet was again aided by the use of the 960 grid system. With tablet the key concern was portrait view, to provide for a screen size of 768 pixels a small amount re-scaling was needed, you can see the difference between landscape and tablet in fig 30 and fig 31. After this, it was necessary to ensure that key functionality on the various screens fitted with these dimensions.

Fig 30: Tablet Landscape
Fig 31: Tablet Portrait

Site Architecture

Using our data from our card sorting exercise which we had then developed in real time boards into a suitable site architecture we created the below navigation for the prototype. We felt this addressed the issue of users being confused as to the location of content, as its derived mainly from user feedback and categorises content into logical areas.

Fig 32: Navigation Level 1
Fig 33: Navigation Level  2


Secondary Goal

A secondary goal which was addressed in the main site navigation was the request by management as well some users for a login area.This was provided on desktop (fig 34) through the user account icon on the right of the screen. The last two screens  show it functioning on mobile where it assumes the full  screen display and is accessed via the hamburger menu & then settings menu option (fig 35).

Fig 34: Account login

Fig 35 – Mobile account

Fig 36: – Mobile account


Leave a Reply

Your email address will not be published.

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

Up ↑