Theatre Tracker App — The Process

Jean Marrapodi
6 min readAug 14, 2016

--

I’m finishing up a certificate for Coursera on Human Computer Interface Design, and our final project was building out the prototype for an app. This is the story of the design decisions and process for developing my Theatre Tracker app.

The Need

I’m an avid theatre goer. Like the people in this scenario, I haven’t found anything to keep track of the shows I’ve seen, and details get lost as I try to retrieve connections from my memory. We have IMDB for movies, but there is nothing similar in the world of theatre that can be used to look things up. I’m building the app to keep track of plays people have seen, upcoming tickets, and to find information about nearby theatres and their shows.

The Users

I see this app to be of benefit for theater goers — those who subscribe and those who attend occasionally. They can enter their tickets, and track and review what they have seen. They can get reminders on their wish lists, or of upcoming shows so they don’t miss buying tickets.

It is beneficial for travelers. People can search for a theatre by location and find out what is playing that night.

It is beneficial for theatre marketers. I envision this as a subscription service, and subscribing theatres can population the information about their seasons using a back end tool. The opportunity to order tickets within the app brings a great call to action. When a wish list is build out, there is opportunity for reminders to be sent about the show opening and closing. Users could opt in for this kind of service. There is also possibility for cross advertising and discount coupons.

Actors and other theatre staff can promote themselves in the people listing, and producers and directors can search the people database for staffing for their shows. This would be a crowdsourcing effort, and may also be a subscription base. Subscriptions may eliminate the need for ads.

The app would be helpful for theatre students as well as theatre patrons to research details of a show along with reviews to make decisions about attending, or to get the backstory details.

Design Process

The design process began with talking to people about what they would like to see in an app like this. I posted on Facebook and got some brilliant suggestions covering angles I’d not considered. One person suggested that I add a personalized field for the theatre as well as the show to include parking and restaurant deals. This leads to the potential for advertising to support the app.

Next, I used index cards and roughed out a design. This was useful to determine the flow of the app and help me recognize the many connections that needed to be included, so I also built out a diagram of the information flow between screens. These cards were shared with about 10 different people, asking them to think aloud their process as they used the cards as they would use an app. I discovered pieces that were missing, which were easy to add by just drawing another card and inserting it into the flow; as well as areas that might have been confusing. I got some new ideas about incorporating social media icons for sharing people’s attendance and individual reviews. I also found out that some people would prefer to do this on the computer rather than a smart phone. This is an interesting consideration because many theater goers are senior citizens who may not use cell phones, but who may have flagging memory and find something like the app very useful. Responsive design is something I’d not considered.

In the next step, I created some wireframes. This helped with sizing and determining what would and would not fit on the mobile screen. We weren’t asked to wireframe the entire thing. I suspect that would be helpful if the piece would be handed off to a designer.

Our next job was to build out the prototype, which took a few weeks so we could get feedback. Someone in class shared about MarvelApp.com, which is a free site that lets you build out the prototype and share it with others for testing. The site is relatively new, so the design features are limited. I wound up building out the app screens in Canva and importing them into MarvelApp, then linking the pieces together. During the design process there was an upgrade for a standard header and footer, which I really wish existed when I started. Having an interface with a standard footer would make coding the navigation much simpler. As I was building out all of the hyperlinks, I recognized how complex app design really is. I’ve done a lot of elearning development, but much of that has pre-built templates where you just drag coded buttons onto the screen and the coding is complete.

I shared the link to the prototype and got still more feedback. Someone suggested leveraging ads to monetize the app, which came up in the early thinking, but was eliminated at this early stage. Someone else suggested building in a wishlist, which I’ll include in the next round.

We were provided with access to UserTesting.com for 4 testers. Here we had users who knew nothing about the app who were coming at it cold, with the exception of the mindset they should adopt as users. I had four people who had no connection with theatre, and it was interesting to see how they clicked on the many things that I hadn’t build out yet, so I learned how important it is for the prototype to be complete before testing. They also didn’t click on the headers I’d included as generic items, but went right to reviews, plays and people which I hadn’t built out. In the next iteration, I used placeholders to mock that up. They also clicked on the first item that came up in a list, which wasn’t always linked, so I need to make sure I link something there every time. I’d put in about 8 theatres, but only build out the info on four of them. I think it would be better to limit the info to everything that works.

We did an A-B test on a variant of one of our screens. I tried streamlining my home screen, but changed Find Info to Research, and that confused people. I decided to keep the original home screen.

I got one comment that the app looked a little old school, which is important to consider. I am hopeful that partnering with a design studio that builds out apps will take things to the next level. I have no idea what that is going to cost.

Next Steps

  1. Locate Theatre Databases. In order to complete the production of the app, I need to figure out sources for the plays for research. Ideally, when a person selects a play, they have the option of looking it up for synopsis, characters and background, or if it’s playing locally, to add it to their plays or their wishlist. This is the challenge. Does this database exist anywhere? The theater people I’ve spoken to are unaware of one other than the publishers. There is some on Wikipedia, but this isn’t a reliable source.
  2. Locate an app developer. While my idea is fairly fleshed out, I need to find iOS and Android developers to build it out. I have no idea what this would cost.
  3. Revise the design to include wishlist and possibly ads. The feedback I’ve gotten has been really helpful. I need to rework the design to incorporate a wishlist and advertising to generate revenue. App sales may cover costs, but I don’t know enough to determine this. The wishlist, however, is an important feature to add.
  4. Secure funding to pay for development. Unless I can find someone who is willing to develop this on spec, I need to find a source to fund this.

It’s exciting to be at this point! Ping me if you have ideas.

User Need: https://youtu.be/fxFwjjZhnnw

App Prototype: https://marvelapp.com/fhe33a

--

--

Jean Marrapodi

Learning architect working at the intersection of low literacy & high tech