The Hemingway App
We unfortunately had to change the problem.
When at first we thought that we had tackled each other’s problems, Ben seemed more at ease with my app, whilst I got more insecure about my app down the line.
We faced various issues with the app and its usability.
As this was an for Ben who travels a lot and stays in places with limited budgets, in locations such as Nepal, India and Morocco, it needed to be an app which could work offline. This therefore required the app to be really simple, extremely fast to load and a useful resource.
The first idea consisted of an app that could let the user know how long it would take them to read a specific book. This was so the user could pack accordingly and take the necessary books he or she wanted, depending on the length of the trip and the time they would take finishing the books.
However, the functions that we were thinking of applying to the app required internet connection. Furthermore, the app had various elements that needed of social media and outsourcing through the web to become the functional app we wanted to create.
When sketching the first three screens rapidly, we could both tell that we were complicating ourselves, so we decided to gravitate to another solution, also in the area of reading and travelling.
The new App
The new app and the idea behind it is much simpler. For now we have an app that works like Lonely Planet, in the way that you could download the information beforehand, arrive at your location and have all the functions that you will need.
This clearly means that the app has limited to no social media usability. However, this keeps in line with the experience of reading a book; it’s an experience felt by a single individual, you’re not trying to share socially and it indeed has a romantic/nostalgic element. Especially with fiction/novels, which we will be focusing on.
The best way to tackle this experience is by making the app a pleasurable experience, in a way that it does not interfere with the reading experience and it keeps a second position behind the book itself. It must act as a guide or trivia that helps the reader contextualise with his or her surroundings, get further immersed in the book, yet it does not stand out.
Furthermore, the user could potentially re-live the experiences told in the book by visiting the places shown on the app. This could change the experience of the reader and he or she can further understand the context, the social and political background and any other circumstances that the author or the character in the novel experienced.
As far as I can tell, this app hasn’t been created (I am most likely wrong but will keep looking for it, or an app that does something similar).
I need to find out (Austin?) if this project is available…!
Switching to the new concept clearly worked. The new feedback I was getting from Benjamin was clearly shaping the app, plus not questioning the app as a whole, as it did before.
I quickly realised that Ben is quite the smart cookie. Another thing I noticed from him, he wasn’t about to let me off easy.
He wanted an app that was absolutely bespoke for him. This meant every element of the app had to pass under scrutiny and work exactly as he would expect it to work.
When this should have been stressful, this was actually refreshing. Not only did he act as a real-world client, he pushed me to make the app perfect for him: the user. This was a great way for me to begin my first week in GA, with a hard challenge that drove me to find the best solution and product.
I did however believe I had good ideas that I could’ve pushed further, as initial pitches proved to be unsuccessful with Ben. However, due to time constraints, these ideas had to be scratched off the table.
One that I thought it could encourage the user to explore, was having the locations unlock as soon as your GPS reached the destination, so you could have all the info, and only then be able to save the location. However, Ben (cleverly) suggested that it could be quite infuriating not to be able to know about a place because you weren’t physically there.
What if you don’t have time?
What if you want to read all the info and trivia before making sure you embark on a possibly long distance?
Ben had many more reasons why this idea (and others) wouldn’t work. So I took them on board and worked around it.
I was finally twitching and re-designing the last iterations of the design based on the feedback that I was getting.
From being a chaotic and thick process, by Thursday the 5th, this chaos was simmering down and funnelling into a product that was getting streamlined into a cohesive piece.
Putting it through the final testings — paper tests and through Marvel — , we were finally able to see how the interface was developing and how its usability will fit the demands of Ben.
The last function which I kept basically ‘shoving’ aside, was how its search function would work. Something which Ben obviously inquired in depth, and I had no real solution.
I originally had a search field which could only choose one point of interest. Ben wanted the possibility to explore multiple. Back to the drawing board.
I cannot overstate the importance of learning user-flows. I tried coming up with the solution in my head, but when drawing it out as a user flow, the solution (which is embarrassingly simple) became pretty clear.
When you go to the search field you have all the possible points of interest in the city below. Whilst typing a name, book or author, you are effectively filtering out — tag by tag — (or categories) until you reach the criteria desired. This effectively lets the user explore multiple points or a single point in the city.
When the search bar was clarified, I loaded all the screens into Marvel, made sure that (almost) every single element was clickable; as I said before, Ben would not let me off easy.
He reviewed it and was happy. That made me happy.
Looking back on the presentation, and the comments I was given, I could’ve improved on the following.
When it came to the iteration of the design, I feel that I could’ve made that clearer by highlighting some examples and then showing how this was solved; such as the search bar example.
I also figured that I might have repeated myself when presenting the design iteration process and the story of how we got to the product in the presentation. This issue could have been easily solved by explaining the design process via user testing in depth and with examples as stated above.
Another comment I got was that I did not stick to the brief, which is indeed true. However, my approach was to sell the product. So I divided my presentation in two. First half was to sell my product to stakeholders as it were, and the second half, to explain in depth what went right and what went wrong with the design and the process of building the product with Ben. I, however, did not make this clear which caused the audience to get lost in the presentation.
However, I engaged with them very well and got excellent comments after the presentation was done.