At the end of last year, we made a little project on designing a movie ticket app. This case study is something that we did in our free time just for fun, so there might be some part of this exercise that isn’t technical enough or not according to the best UX practices.
We also tried to build an actual working prototype. However, since we don’t yet have any mobile developer, for this project, we did it in HTML/CSS.
Background
Indonesian apps, in general, arguably still need a lot of catch up UI and UX field. One of the worst examples is the UI&UX for banks (and financial related app) where even log in, or registration sometimes can still be a hassle. However, for this little exploration, we tried to do a simple movie ticket app.
Generally, the UX for the movie ticket app that I’ve used is not too bad, but here we are trying to see if we could explore a better alternative to the current apps, both in the flow and in the presentation.
Let’s Start!
The Product that I’ve Used
To start, I tried to compare a few different Indonesian movie ticket apps that I have ever used before. I came up with th6ese four: Go-Tix, XXi Cinema 21, Traveloka, Mata2 (Sadly closed down at the time this writing started).
For each app, I wrote down the things that already work and also the things that possibly can be improved.
Apart from these four apps, we also did the Atom app, where we found some distinct features that we haven’t seen in the local apps above.
The Purchasing Habit
Listing down personal habits in purchasing movie tickets helps me building the questionnaire that will base this case study. Here are some from my notes:
- I already know what to watch in the cinemas, but I just don’t know when it’s playing in my local cinemas
- Sometimes when I’m bored, I will open some movie app looking for any good movies currently playing. If the trailer looks good, there’s a good chance that I will make a purchase
- I will check the Rotten Tomatoes or IMDB score before I make the purchase
- All cinemas are pretty close to where I live, so I choose the cinema based on screening time most of the time
- etc.
Assumptions
Even when I just started this exploration, I already had a few assumptions that I wrote down. Looking at the competitive analysis and my purchasing habit above will also bring up more assumptions.
These assumptions could be a new feature idea or just some things, or features that I think are not working on the other apps. It could be small, and it could also be big. Some examples below:
- Notification features should be mandatory to cater to the user who does not know the date of the upcoming movies they want to watch
- In most of the tested apps, the user needs to “select a city” before selectin which movie is playing in that city. How would people who live in between two cities do their search? Should they search twice? It should be easier for most people if we build “cinemas around you” instead of a city-based.
- Based on my purchasing habit, I will check the RT and the IMDB score of a movie before making a purchase. It might be a good idea to have this within the app to make it easier for the user to make a purchase decision directly in the app.
- The ability to see the trailer in the app should be mandatory.
- It would be great to build a rating system where we use emoji to represent the rating of a movie; for example, standing-ovation emoji represents that the movie is outstanding!
- Etc.
Questionnaire
To challenge our assumptions, we formulate questions based on it. For example one of my assumptions is
“User will check the rating of a movie before making a purchase”
And then we make it into question:
“Do you usually check the movie’s rating before making a purchase?”
With the answer of either yes, no, or sometimes.
The challenge here is to make questions by not mentioning or describing the feature. Perhaps mentioning a feature could turn the question into a suggestive one. For this assumption below:
“A feature to notify user that a movie is coming to their local cinema would be great”
I tried not to translate this into this question:
“Should there be a notification feature when the movie is playing in your local cinema?”
As it seems that the response would probably be “Yes, this feature would be great!”. Instead, we tweak it into a more subtle sentence/question like the bold sentence in the yes/no question below:
Have you experienced the following?
a. Randomly check which movies that are playing near you.
b. I already know the film that I wanted to watch, but I don’t know when it will play in my local cinema.
c. Pre-ordering movie tickets
The bolded sentence above will possibly give us the answers without mentioning or describing a specific feature.
From this exercise, we figured out that not all the assumptions were able to be converted into questions, though.
From Questions to Data
We shared the questionnaire on our Instagram account, and we got 144 respondents (we specifically made it in Bahasa Indonesia as we are targeting Indonesian). The downside of this approach is that the audience type is not diverse enough since most probably our Instagram followers are mostly designers. But we can live with that as this is just experimentation.
When we looked at the data, we do realize that perhaps the questions (and the prefilled answers, e.g., multiple selections) should’ve been more thorough. So here’s an assumption: it would possibly be better if we run the questionnaire with a small number of responders first, looking at their response and then reiterate our survey before sending it to a more significant amount of responders.
Insight
Some of the insight that we got from the data is helpful for us to make the design decisions. However, not all of them gave us insight. Some of it will just create more questions than providing answers. This issue probably has something to do with setting up a more thorough questionnaire? Or perhaps it’s acceptable that not all the answers will be insightful?
The Low Fidelity
Now it’s time to draw! There’s nothing special here, just an awful drawing put in One Note :)
High Fidelity and Prototyping
I’m trying to breakdown some of the most exciting design that we did here:
Landing Page
Playing near me will be the default mode for the user. Within the dropdown, the user can still select options like Playing in Favorite Cinemas and Choose a City. Both options are available in the local apps that we reviewed.
Thoughts & concerns:
- While we are not sure how many movies will be playing at once in a city/area, we thought that the approach to stack the movies sliding to the right might be quite painful if there are quite a lot of movies.
- The other concerns here were whether we should put the title and genre (since the genre is vital based on the survey) under the cover in this app, as some of the apps do.
One of the opposing arguments is that the cover should already tell what type of movie it is. We also found that Atom (and Netflix) don’t show this information. At the time, we decided that we wouldn’t put the title and genre below the cover.
After checking the prototype, I felt like it is important to put the title at least for the “upcoming” section, where the notification button covers some of the title parts. Either that or changing the notification button style (adding transparency or changing position).
Detail Page
Some of the design decisions here were derived from the other apps that we reviewed (like making it easier to switch between dates in GoTix or Discussion from Mata2). Some others are additional (like RT review, etc.)
Concern: This pullup UI I’ve only seen in iOS apps but never in Android one, so one of the concerns is whether there will be difficulties in implementation for the Android app.
Venue & Seat Selection
We keep using the same time selection UI pattern on the bottom of the screen, whether it is to switch between dates (in venue selection) or to switch between screening time (in seat selection). This UI component will probably help the user not to go back and forth between the pages when they need to change this parameter.
A few concerns:
- Is it important to show the row and column number in the seat selection?
- Should the user be informed of the difference between the venues?
The Prototype
You can check the prototype below!
What do you think?
In the real-life scenario, there are a lot more things that need consideration in making an app. This case study is just a very simplified version of the process. A few things that we didn’t consider in general, including:
- Are the graphics to excessive? Will it make the app heavier?
- How much effort will the developer build such experience?
- Testing the prototype to the user to see if the UX makes sense for them.
By no means that this process and the design itself are perfect, I realized after prototype that there are more things to be done, and there is quite a lot of missing stuff in the design.
Should you have any suggestions on what to improve in this kind of process, please let us know in the comment below. Also, if you like this type of content from us, please let us know in the comment so that we might be making more in the future!
Cheers!
The team:
Iswanto: Concept, Low-fidelity mockup, Writing & Video
Ghani: UI Design & Graphics
Sulis: Prototype
