Now that my efforts to develop the HipHopListings iOS app myself had not provided me with the desired results, I decided to seek help. I got as far as creating a basic app version of my existing HipHopListings (‘HHL’) blog and installing it onto my phone. However, it became pretty clear very quickly that Apple weren’t going to accept my app or that “AppMaker”, the 3rd party tool I was using, were going to submit the app for me. Alex, an experienced end-to-end developer, was happy to help me with developing the app in return for a modest fee. One of the first questions that he asked me however was whether I could provide me him with a short brief of what to build.

At this stage, I had thought about my product vision, assessed the opportunity, created wireframes and even started developing the app myself. What I hadn’t done, however, was define the minimum functionality which needed to be included in the app. I thought I had a reasonably good idea of my target users and their problems that I was looking to solve through the app. Also, I felt I now had a better steer on the criteria Apple use to approve an app into their App Store. I just needed to translate this is into some well-defined features and requirements that Alex could work against.

The challenge was to rein myself in whilst I was outlining the product requirements. I could easily see myself falling in the trap of overdesignining this app, now that I had an experienced developer to help me. I therefore used Tristan Kromer’s version of a mix of the “Lean Product Canvas” (by Ash Amaurya) and the “Business Model Canvas” (by Alex Osterwalder) as a technique to try to keep my requirements as ‘lean’ and ‘minimal’ as possible. This is how I broke it down:

1. Customer needs and goals (problems) (1) – The key user problems I was looking to address through my HHL app were twofold: (1) how do I find out about upcoming Hip Hop shows in my area? and (2) how do I find out about upcoming Hip Hop releases. Both seemed like fair assumptions to make as I’ve received lot of a feedback on these problems from having done HHL over the past 4 years.  
2. Customer needs and goals (requirements) (2) – In my brief to Alex the developer I translated the user problems mentioned under 1. in the simplest way possible: (1) enable users to easily view upcoming shows and go to a 3rd party ticketing site (see Fig. 1 below) and (2) enable users to filter listings by area and by date (see Fig. 2 below). I also asked Alex to set up Google Analytics so that I could track users’ actual behaviour and validate some of my assumptions.
3. Keep it simple – I decided to keep the design of the app as simple as possible at this stage. Let’s get the app approved by Apple first (which can be a real pain in itself), get people to use the app and comment the functionality. Once I’ve established that users actually do find the app of value in terms of finding out about gigs and releases, I can them improve the functionality further and worry more about the user interface / visual design. In his “Lean Product Canvas” Tristan Kromer refers to this approach as ‘trimming the fat’.
4. Customer needs and problems (3) – Based on previous feedback, I thought it would be good to add a very basic ‘discovery’ element to the app; a very simple ‘Featured’ screen which users can turn to for curated shows and releases which I’d chosen to highlight (see Fig. 3 below). I reckoned this feature would be relatively easy to get feedback on. Firstly, through tools Google Analytics and Flurry I would be able to monitor the number of views of this screen. Secondly, I felt this would be the kind of feature which would be easy to get qualitative user feedback on. I could use both feedback methods to validate one of my assumptions: making it as easy as possible for users to discover new shows and releases will be a powerful proposition for HHL’s (target) users.   
5. Constraints to consider – One of my personal goals was to learn more about designing for mobile. And learning I did. My original design went largely out of the window as soon as I realised from testing that Facebook’s more traditional split screen view (see Fig. 4 below) would probably be easier to implement and for users to interact with. After all, all I wanted is a clean and simple interface, no frills, and it looked my original designs were probably a bit too elaborate compared to some of the simple user interfaces that are working well (with Facebook, Hailo and Vine as good examples). Also, I realised that I had to update the app’s content manually via a back-end which had to be kept as simple and intuitive as possible. I spent a good chunk of my time think about the user flow involved in uploading, updating and removing the app’s content.

Main learning point: actually putting down my functional and non-functional requirements down was both scary and exciting at the same time. Scary, because I really had to rein myself in and be realistic about technical and financial constraints. Exciting because I could apply some of my ‘lean’ lessons learned to my own app and think about the key value I could provide my (target) users with in the first iteration of my HipHopListings app. If anything, it was great to go from creating my original vision to submitting my app with Apple within a month. As scary and challenging as it felt at times, I felt I had created something tangible that I could launch, validate, learn from and build on!

Fig. 1 – My design for a “Shows” to enable users to easily find out about upcoming shows and go to ticket sites

Fig. 2 – My design for a simple filtering functionality, enabling users to only look at shows in their area or by date

Fig. 3 – My design for a simple ‘Featured’ screen which highlights pre-picked shows and releases

Fig. 4 – Facebook’s split view mobile app design

Related links for further learning:

1. http://grasshopperherder.com/business-model-canvas-for-user-experience/