Open Search

My Process Building An App

September 17, 2016 6:00 pm
Categorised in: , ,
Reading Time: 11 minutes

This post details the full UX process I took for a recent app build project I was working on. My hope is by laying out this journey, it will help someone, somewhere, at some point with their planning and delivery of an app.

Premise of the app

Last year I spent a long period doing sprints on a piece of work I was pretty happy with. We had a project to develop an app where the user – having had an automobile accident – could, with the press of a button, receive a callback from a service that could handle everything from that point on. The service dealt with your insurer on your behalf to get you the best deal possible. This meant the cost was absorbed into the users claim so to all intents and purposes, free. Everybody likes free.

Thing about road accidents though. They tend to make a mess that you need to move out of the way somehow afterwards. Usually very quickly. This makes them very temporary. To aid the service provider  in getting the best deal for the user would mean there needed to be a way to capture any useful evidence at the scene. Ideally within the app. Keeping the data bundled together seemed like an obvious point to make. Rather than allowing a user to collect over different apps and then allowing them to sync into the app would be pointless and not beneficial to the user. This added a further layer of complexity as it meant that the user would potentially have need to have multiple incident reports. The user may want to access over time perhaps whilst dealing with follow up calls from the service.

Once the evidence was collected the user would probably want to do something with that evidence. So, functionality for uploading the report was required. This would also necessitate a login system which communicated with the server. This provided the core idea of how the user would use the app.

Basic user journey

It is always best to quickly map out a journey with a pen and some sticky notes. This allows you to quickly move things around, delete things so much faster than working on a computer. Do not jump straight into a prototyping or visualisation tool. After a bit of pen and paper work we envisioned the user journey in an optimal situation would go sort of like this:

  1. User downloads/opens app
  2. User creates account
  3. Inactivity over X period until required
  4. User crashes car and opens app
  5. User presses button
  6. User receives callback from service
  7. User collects evidence
  8. User submits incident report
  9. Inactivity in app over X period until required
  10. Service follows up over other method, typically phone conversations
  11. User may access app to cross reference with evidence whilst dealing with service
  12. Inactivity in app over X period until required

It’s obvious how with iterative development from point 10 on the app could be further built out to allow deeper integration with the service and the user. Adding in updates to an ongoing case into one space and allowing the user to keep track of information would be great v2 stuff. For v1 it was agreed that that user flow would work.

Early development

When I began work on the project some of the basic ideas were already being discussed but the basic flow of the main journey was obvious. Specifically steps 4-6 were an easy target so we did some early visualisation work using an early version of the brand. The images below show how we thought these steps could work. First these are the initial stab we took at a home screen.

Couple of quick visualisations of the home screen

There are a few things to note here about these.

  • Man, I hated the red on this from the first second. Bear this in mind later. It was already there when i was handed it with the brand mark, so I tried to steer away from it. I lost that battle for a long while. My reason for wanting to avoid red was because according to colour theory red semiotically red is a warning colour to the european mind. Red is the colour of blood. Red gets our hearts racing and puts us in an alert state. When you’ve had an accident you don’t want to be stimulated, you want to be soothed. Trust me I’ve had my fair share of car accidents.
  • The early brand was supposed to connotate a helpful smile. The brand mark looks more like womens pants. Once seen this cannot be unseen.
  • I quite liked having user details at the bottom. I liked the idea that the user could be reassured that the app knew important core information before any user action had been taken.

Early visualisation of accident reporting

Once the user has pressed the request button they would go to a confirmation screen to try to minimise false requests. Upon confirmation I wanted to give the user tips on what to do next. Imagine, in your, mind that next the user takes the call from the service. They’d then proceed to the crash report.

Quick early visualisation of the proposed core user journey

And, ahhh, oh god, that radial menu. I was not keen. This was some account handler bullshit about wanting an innovative way of completing the report that had been mocked up before I was involved. Whilst there is evidence that radial menus can be useful in certain circumstances, such as gaming, they are useful when its for repeated actions, not for an app where the user comes to it once in a blue car crash. When I’ve had a crash I want things to be straight forward. Something to focus on. I don’t want to have to decipher a UI to do this. I saw this as a friction point.

The radial menu did not last long.

A new look

Time went by, some people pushed bullshit around a room in meetings and the project went off the boil for a bit. When some turned the gas back on the project had a new name and a new look and feel done by the branding team whilst I concentrated on laying out how the actual journey worked. In this instance, rather than working this through in wireframes in Axure, as we had brand style in place, and there was a requirement to, we went straight to colouring in.


Again the dreaded red rode strong. Now with a hectic background at a road by night. The angles on icons are sharp not rounded adding none of the softness a curve provides. Whilst I appreciate we had a cohesive look and feel I found the look still too harsh with no calming elements. Knowing we would user test later and would have the opportunity to change later if my theory was validated I kicked up minimal fuss. If you know you are user testing. Don’t fight battles over UI at this point, raise concerns at the time but make sure you focus a couple of tests on those concerns later.

In terms of UI language, at this point, the app was to launch first on Android so I used a lot of Material Design visual elements, form fields, buttons, etc, to integrate better with the platform. As it was Android, we went with a hamburger menu. Interesting choice, more on that later.

Journey Development

With a brand in place I was free to plot every step of the job that the user would want to perform whilst in the app. A lot more work went into this as we worked to solidify functionality so draft upon draft lead to what I’ve called version1.  The first version was interesting

early Beep coloured in flow diagram

Whilst a lot of the core journey in terms of reporting an incident and creating an incident report remained the same from this initial user journey, a lot changed. Solely for the better in my opinion. At this stage in the project I had the opportunity to user test the prototype the current journey utilising people within the company I work for that fit the young, relatively new to driving, audience profile that we’d  internally envisioned as the initial market we’d target the app towards.

I think at this point we user tested using a prototype based on the internal build of the app which was at a point that by with effort we could get complete a journey. So we spent some time doing that, Things like camera, text fields, etc, weren’t wired up. The upside here was if testing was successful we’d be further along. This is not necessarily a way I recommend people should work, especially for apps and especially with limited access to developer resource. Because the downside to working like this is if the testing shows a lot of problems with the journey, you have a lot of work to chuck in the bin.

we chucked a lot of work in the bin.

User testing results

User testing revealed users could not find any functionality behind the hamburger. Which pleased me. I’d been secretly hoping for this result and it was glorious to have that validated. Despite the fact that it meant a lot more work for me and the team. User testing also revealed that users weren’t a fan of the UI elements including the red that I’d been hating on since the beginning of the project.

Journey Development after user testing

After taking in the user feedback, we refactored the app to be based around the tab bar navigation pattern developed by Apple. For me, this should have been the way from the start. I’m not a fan of hiding navigation in hamburgers. My rule is: if you hide something, you must be prepared for users not to find it. Users avidly discovering the nooks and crannies of your app is not a given when app is a utility-on-demand SaaS product. Here we created a clear route between the two primary actions a user wants to complete in the app:

  • Reporting an Incident
  • Completing a task around a already reported incident

Along with other IA improvements like moving the About page off the main view and into the newly created incident*; envisaged a multi-stage form style path through incident reporting, rather than the tabular check list style approach we implemented in the previous version. The hypothesis being that shepherding the users through the incident report more directly would ensure more completed reports at the instance of the user creating the report. This journey is below.

second Beep coloured in flow diagram

User Testing

As dev continued in parallel implementing back end changes, I proposed testing utilising a pdf prototype. The PDF prototype would be presented on device and would run between screens of the app. Where appropriate the journey would be broken up with a question. As the test subjects were being filmed and guided to verbalise their experience as they were going through these prompts provided enough of a rough estimation of a users experience on device to glean usable responses from the test subject.

The bonus of this method is speed and efficiency balanced with a high level of visual fidelity. Having busted chops to get large amounts of the UI work done previously, this was really a case of reordering visuals into a new user journey. This also allows development to carry on unaffected. Again I should stress:  ideally at this point in a project you shouldn’t have spent this much time on visual styling. The considerations we were making could have been validated far earlier into things. But I find that the  learnings you eventually take from a project are worth far more than the sweat and tears you put into them.

The carousel below represents the entire user flow we used in for the prototypes from here on it along with the questions the users were prompted.

User Testing Results

The results for this round were far more positive. The tab bar navigation model we had used proved a hit, so development carried on to build that in to what we had. The multi-stage form-style approach to incident reporting tested poorly. Users felt constrained that they couldn’t do things as they would want to, e.g. the user should dictate when they can take the photographs of the scene, especially in instances where they could be in danger. So, we retested again multi-path tabular approach again. This tested much more  positively. We also discovered that users needed a bit more orientation into creating an incident report. Which was nice as that wasn’t something we were necessarily looking for. We continued a few more round of prototyping using this as a basis, tightening up the ideas.

The big takeaway from these testing sprints was that the app could do with an on-boarding experience to orient the user and really introduce the app and it’s service. That and the branding. I finally got to validate that the red, sharp corners and night time imagery were not the things that you want to see minutes after rear-ending some big looking blokes van. So that went off for a rebrand.


Another new brand was developed and fed into testing. As it tested positively it was was rolled into the journey changes. Video work was done and I used the assets from this to create an on boarding experience to orient users. This followed the messaging from the video so was an easy development. In terms of user journey, this would be presented when the user first launched the app and prior to account creation with users swiping to view each new message. Always best to provide users a way to skip through something like this, just in case it’s a pre-existing user who is re-installing the app or otherwise doesn’t want orienting.  So skip controls would take direct a user into login/account creation.

Again the new brand look and feel was incorporated into a PDF prototype and final group of test subjects were assembled for a thorough testing upon. This was envisioned as a final sense check before the v1.0 launch which was fast approaching. The final prototype screens used in this test can be seen below.

Test results

This version tested incredibly positively, look and feel and improvements to the user journey left us feeling we were in a good place to finalise these as the last changes and anything later would be bug testing. Issue testing can be provided by users using your apps on device using services like Applause. This is exactly what we did in this instance and they certainly did their jobs. So it was a positive that we had finalised our v1.0 user journey.

Developing the app

Sooooo… Confession, I secretly built this in Swift from home on an evening. Yeah, it’s one of those. There were elements that I of the user journey I wanted in that we couldn’t do in time, I knew this was some of my best work in terms of really developing a solid user journey. It was something I was really proud of. The other key thing is, if you look at this app, it introduces you to pretty much every API and touches on the key input sensors in iOS development if you want it to.

My skills in Swift were relatively nascent at this point. I’d been playing with Swift since Swift 1.0 first came out. I’d built an IoT device in my house and was feeding that through to an iOS app. I had an unhealthy love of ScrollViews at the time. Like everything was a ScrollView, because it was easy to have a longer screen if necessary. But I was getting pretty in-depth with CoreData. So I was going for it, but getting hung up on the one project and not expanding beyond the confines I’d created for myself.

With this project I saw it for what i was and threw myself in to UIKit. Just to see what we could do. Oh look, TableViews are much better to use than ScrollViews. Ahh, so that’s how you do animations. Damn, I wish I’d learnt about CollectionViews before I built his on boarding section. Oh handling keyboard isn’t automatic. The revelations were fast and I a dropped vast arsenal of knowledge bombs on myself in such a short period. It was glorious.

Initially this was going to be a project I’d get x amount of time on a week to keep my boredom sated. That got canned off after about two weeks. Never the less, I persisted. I haven’t worked on it since just after we released the v1. At that point the only known tasks would be to add an uploader for a finished report (wasn’t bothered) and to fix audio recording/add a visualiser when recording. I’d say 80% done from a point I’d release.

I’m honestly glad I spent my own time learning how to develop a full app experience like this. It’s made me the bomb at Swift.

Native vs hybrid

One of my bones of contention with the final product we were producing was that I didn’t find the technology solution we were using particularly responsive in terms of performance. The decision was made internally that the best route to market was to consolidate development by utilising PhoneGap to create cross platform HTML5 app. Distribute via app stores, hybrid apps are really WebView wrappers around a web app. What I found was this added latency in a couple of key areas. The video below highlights some of this latency in comparison to the native build.

  • The initial boot of the app to a usable state is far quicker on the native version than the PhoneGap version. I assume based, it seems as if the app has wait until ViewDidLoad (or later) has fired before loading the HTML in the background and then parsing the javascript. This adds a perceptible delay to a ready status. Once inside the app, the content has loaded, no further delays.
  • Responses to interactions. Again, it seems as if the web app had to wait for touches to be passed to it and then the javascript to act on it before responding. We are talking milliseconds latency here, but extremely noticeable in context of an app where touches are handled as soon as they are detected.
  • Scrolling appears faster in the native app. This will definitely be related to being in a webview and scroll speeds are a noted issue in Safari.

Once seen, these annoying niggles with the PhoneGap version really blew the immersion using the app for me.

One of the joys of the fact that I built it on the side meant I could add in little UI features that I wanted in and finessed visual touches. Examples being the main press for assistance button. I was free to add in the animation on the background shapes that missed the V1 cut. The wealth of assets that I could easily adapt meant that I could really bring the onboarding animation more in line with the promotional video materials. Because I was building this alongside development, I’d already had a tab bar implemented before it validated in the real model because I knew it was the correct UX decision and this allowed me a zen wonderland over doing things exactly as I wanted them.

This really was a fun build.


This joint was penned by @elmarko