BASE Logbook App

*This is a work in progress, and this page will be updated as the project proceeds.

Intro

This project started out as a personal attempt to solve a problem I had, and I designed it to suit my own requirements. My initial intention was to use it as an exercise in learning how to create my own apps; it was to be my end product from the iOS and Android courses I signed up for. But I quickly realized that my approach was all wrong. If I was to invest that much time in making a product that has the potential to be useful to so many others, then I need to make that investment worthwhile. To do that, I first needed to find out if other BASE jumpers would be interested in this product, and to what extent.

 

Assumptions

Logbooks are boring, but they don’t have to be. I have two paper logbooks from my skydiving experience, and my current BASE jumping logbook is a spreadsheet online. Filling out the information is a dull experience, and retrieving it is worse. Photos and videos from these jumps are either on old tapes, back-up drives, online in a few places, or on SD cards. Also, it is sometimes helpful to have certain details from specific experiences to refer to when encountering a new but similar experience, but with all of the details scattered to the four corners, it can be difficult. So, with tongue firmly in cheek, I thought surely there must be an app for that? I did find a few logbook apps, but none tailored to my needs. There was a logbook app specific to my needs, but it was outdated and less than delightful. So I set out to design a BASE logbook app that would be very useful, very usable, and very, very delightful.

 

APPROACH

I started out by writing out the information I required in the app, then thought about how to make inputting and accessing that information an enjoyable experience. Inputting information quickly and easily was the first step to making the experience enjoyable. One thing about BASE jumps is that the jump itself is just as important as the object one is jumping from, and perhaps even the gear used on some occasions. Being able to add to the logbook using either one of those vectors and cross-referencing them led to the single and persistent “add” button. On tap, the buttons for adding Jump, Object, or Gear would pop out, allowing the user to choose their starting path. From any path, the user can add details from the other primary categories.

Adding events and locations would be improved by enabling camera and GPS location services. This could be done either just before or just after the experience, rather than done at a later time when a lot of the details of the experience are lost or forgotten.

Stories and Sketches

Lots of photos and videos would make the app visually appealing, and it would also be a great place to store and retrieve these videos, especially in context to the experience.

Of course, all of these ideas of mine were just assumptions. Is this what others BASE jumpers would want in an app like this? Do other BASE jumpers even log their jumps? For those who do, are they even interested in another way to log their jumps?

Fortunately, I have access to a large community of jumpers I could reach out to (not just my friends). I put together a survey on Google Forms to find out answers to the above questions, and posted it to various online and social media forums.

 

 
 

 

The initial response was terrific, the number of respondents exceeded my expectations. There were some great insights I didn't expect. I had assumed users would want their log to contain photos and videos, but those were actually not as high a priority. I was also surprised by the number of jumpers who logged their jumps just how important that was to them.   

 

 

Some great news is that most of my assumptions were validated. The most exciting thing I saw was the level of interest in a better way to log BASE jumps. Although, there was some conflict between that desire and how satisfied jumpers were with their current methods.

The soft data element is missing at this stage, though. Assumptions still to be tested will be validated or shot down once users have something physical to work with. To that end, I needed to map out the features and flow. I did card sorting exercises to see which features mattered most, and in which order they mattered. It was my plan all along to have the elements linked in a referential database, which was disclosed at the start of the testing. 

 

 

With the features and flows mapped out, I started working on wireframes and navigation models. I've been keeping in mind the on-boarding experience, which settings to capture up front versus which to show in context in the user journey. It is important to let the user decide how they want to get their information into the app. While there isn't a wireframe for it, part of the on-boarding experience will suggest the user making authentication a requirement when opening the app (for reasons obvious to many jumpers, at least in the US). Another initial prompt will prompt them to import any existing logbook data (CSV, JSON, etc.), or start by manually adding to the app. The user can choose to start with a jump, the object they jumped from, or add their gear into inventory. If the user starts with a jump, they will be able to add the object and the gear in that flow. Or, they can create inventories of gear, and of the objects they jumped from. Then later in the Add Jump flow, they will simply select the gear and object from a list they've already populated. 

 

 

The most important thing about the app is to give the user the ability to log a new jump as easy as possible. Using location services, for example, is a great way to have quite a lot of information collected automagically and populated in the app.

Of course, there are no shortages of navigation options to work with. The hard question to answer is "which is the right navigation UI to use?" I sketched up several different options and put them into InVision and sent the link out to my test base to get their feedback.

 

 
 

Stay tuned for the next progress update...

 

Next Up

Funny Or Die Case Study

Funny Or Die Case Study

NextGuide Case Study

NextGuide Case Study