Finding a problem
Interview a member of the class and find a problem they are experiencing that could be solved by a mobile application. Work through the double diamond methodology and produce an experience map, prototype and high-fidelity screens.
The project started with a conversation with my classmate Gina — like most Londoners she had a busy schedule and struggled to fit her interests and social life around major commitments. I walked away from this initial brainstorm thinking that the problem to solve here was helping her fit more learning into her life (she has a passion for reading and history), especially in down time such as her commute.
With this in mind, I undertook broader user research (finding users that were busy but had learning objectives was quite easy — there were 14 of us in the classroom), exploring both the topics of commuting and learning. This provided a body of research that I could reference to help make design decisions as the project progressed.
Ideation session 1.0
How might we turn a tube carriage into a classroom
Given a slightly unusual brief (building an app for a single user) I conducted a design studio (ideation session) with Gina very early on in the design process. I call this Design Studio 1.0 because it quickly became clear that Gina was very specific about how she liked to learn.
Design studio 1
The initial HMW statement was ‘how might we turn a tube carriage into a classroom’, but it became apparent that Gina was much more interested in a social learning experience. We felt that this pivot justified another design studio to fully explore this new direction.
Ideation session 2.0
How might we turn a commute into a social experience
Our second design studio focused on ‘how might we turn a commute into a social experience’.
In retrospect, it’s fascinating how both ideas, in seeking to connect similar people and help them meet, are not a million miles away from being dating apps in their own right!
Design studio 2
We came out of this with two similar ideas. The first was a book club where users could share their commute and chat about books (retaining a learning element). The second, a concept we called ‘Tube Buddy’, where users could find interesting people to share their commute.
I built a rough experience map based on Gina’s commute, getting not only a sense of how much she hated it, but also the significant constraints on using a mobile app in this environment (lack of connectivity is the tip of the iceberg etc).
Constraints, the full picture
In refining the experience map I interviewed Gina about her journey in more depth and uncovered some of the main reasons being on the Tube was so miserable for a smartphone user (especially a petite one). It transpired that the carriages were often too full to raise a phone and look at the screen, and too noisy to hear audio through headphones. This would be the key design challenge for the project.
I decided that this required a problem statement with enough flexibility to navigate these constraints and finally settled on the following:
The London transport system is huge and there are loads of people, but Gina is struggling to find someone that shares her interests and her route.
How I approached the problem
While brainstorming, Gina had talked about ‘non-places’ (virtual places that inhabit real places) and I thought this was a great metaphor for a virtual book club on the Tube.
We would provide users with a way of chatting and seeing the shared sections of their tube journeys, while leveraging a community of interest (and Gina’s interest) around books. Users would experience the benefits of the app on their commute, without needing to actually use their smartphone on the train.
With this in mind I framed the solution to the problem statement in this way:
Gina notices that one of the girls she chats with in the Underground Book Club app shares the second leg of her morning commute — she suggests they meet up next week.
Given the time constraints I didn’t really want to design a chat app from scratch and so I implemented design patterns from Slack, WhatsApp and Facebook Messenger. I chose to focus on exploring topic-based group chat (it’s a book club app after all) and indicating commute overlap (these people want to meet in person).
The initial task-based testing was more or less disastrous. Users not only struggled with a low fidelity UI (despite being based on patterns used by some of the most prominent apps on the planet), but were unable to orientate themselves and perform basic tasks.
Prototyping on paper
Tasks are only meaningful to users who have an understanding of what the app is and does — the scenario was not providing enough context. The low fidelity nature of the prototype was also not helping users orientate themselves.
To compound this problem, the tasks themselves were also too complex given the information available on the screens to the user. Problems started on the second screen. Users tended to stumble through this but on screen three had no idea what the iconography and UI elements represented. A dead end. Time to re-think the approach.
Realising that users weren’t getting sufficient context from the pre-test scenario I began work on the app on-boarding screens. Taking users through these screens before they attempted the tasks not only provided me with feedback on the on-boarding screens crucially also saw users start to complete the tasks that had previously been so problematic.
It was now time to start working on the block and low fidelity digital prototypes in Sketch. I exported screens into Marvel and tested the interactive prototype in the same way as the paper prototype. Users were given a scenario, taken through on-boarding and finally asked to complete tasks.
Block fidelity wires went through multiple rounds of iterations with the more complex screens seeing around seven rounds of changes in response to user feedback.
Considerable time was spent making changes to the block fidelity wires because even at low fidelity (above) the screens had lots of moving parts.
You can view the Marvel prototype here.
This brief required me to output high fidelity screens. Stepping away from the prototyping I went back to the user (Gina) to talk about visual design. I got a very strong steer from her with Italian Vogue, and created a mood board that fused classic literature with elegant travel. The colour palette was inspired by an Art Deco cover of the Great Gatsby — a book I took on to feature in the screen design.
The high fidelity screens
The time constraints forced me to step away from testing with unresolved issues. I was having to address these problems even as I working up to high fidelity in Sketch. This will always be problematic given how much detail is on the screens at this point. I was still iterating (left) on the design of the user profiles and particularly the bottom half of the screen showing a user commute crossover.
The high fidelity core screens finally came together — a chat app for book lovers that lets users see who shares their commute. An app for the ‘non-place’ that is the Underground Book Club, a virtual book club that exists across 270 stations and hundreds of miles of track in between.
Revisiting the experience map
The app provides a social learning experience outside of the commute. But it also aims to address and improve the commute itself by helping users connect with other users that share their interests and their commute.
There’s always more to do, this is what I would focus on next:
Explore the user data comfort zone: After interviews and testing, I ultimately designed the shared commute visualisation so that origin and destination were obscured. It would certainly be interesting to explore user comfort around personal data as it could provide opportunities as well as limitations to further work.
Iterate on the shared commute indicators: UI design time was extremely limited and I think that the in-chat shared commute indicators could definitely be improved. Even after on-boarding, they were still proving unintuitive for users.
Investigate business plan: Never a real consideration for concept projects but something that would certainly be a solid next step. The app itself would require capital to build, support and market and it would be interesting to consider how it could be monetised and what a viable user-base would be.