The story of the Walkaway app
“I didn’t know I needed this, but now I know it might exist, I really want one!” (usability test participant)
After a year’s blood, sweat, tears and sometimes fun, I’ve finished the Interaction Design specialisation on Coursera: seven courses plus a final project to create this mobile app prototype centred on user needs.
I chose the brief of “Change”, with walking as a topic, because I have stared for long periods of time at web products related to walking. Could I design an app that would help people to walk more, to reconnect with the environment and feel better physically and mentally?
I started with observations and interviews with some possible users. All my interviewees talked about the joy of going for a walk, of being in nature and feeling physically alive. But they wanted a bit of an adventure in a walk. They know their local area and either walk there or not (if for instance the parks are unattractive or unsafe) and they wanted to go somewhere new for a change of scene. But they also wanted to know it would be nice/suitable for their needs when they got there. If you don’t have much free time, a Sunday afternoon is a big investment.
The current solution is to look up pre-planned walks. Someone has already done the walk and written it up, so you have a good idea what to expect.
One memorable moment involved watching a participant planning a walk. She googled walks in Epping Forest and found a couple, but then had trouble determining whether/how she could get to their start points by public transport. She was flicking back and forth between several walking and transport sites without solving the problem.
I realised that for the user, the walk and getting there are one task which is currently split in two, and that this presents a huge Catch-22. Your choice of where to go walking is heavily influenced by how easy it is for you to get there. But you can’t work out how easy it is to get somewhere without knowing where that somewhere is. Particularly if you live in a city, transport possibilities may be numerous and not always obvious, particularly once you take into account changing trains etc.
Most walking websites and apps present walks on a map, but this requires you to have a really good mental model of your transport options in that whole area; and if you’re a public transport user, distance as such isn’t necessarily a limiting factor. Then once you’ve chosen a walk you have the job of working out how to get there.
During the next phase — generating ideas — I thought about how much easier Citymapper has made it to get around London, and whether I could redesign the walk planning process as one experience, including both travel and walking. I also thought about the Diceman, and recommendation systems, and whether one could throw in an element of surprise by suggesting walks. Then we started storyboarding ideas.
This storyboard is basically the app I ended up designing. NB this is purely a visual prototype and the data is a mock-up. It assumes you have a database of walks — I kicked around a few other ideas for suggesting nice places to walk but accepted this existing solution for now.
Throughout the ten week course we constantly tested our designs with users, refining and iterating, even when we only had a few sketches on paper. Lots of ideas didn’t make the cut (including a walkers’ social networking app which no-one liked) and I learned a lot. Interestingly, when prototypes were a bit vague in parts, I found that people would project what they would like to be there which gave me some great ideas for the next version. I also found that people don’t recognise icons. It was incredibly satisfying to watch people exploring and understanding the later prototypes — and being surprised and delighted:
“I didn’t know I needed it but now I know one might exist I really want one, because I can think of so many scenarios when I struggled for this type of information and this would have really speeded it up.”
“It’s actually really exciting, it’s going to take me to places I wouldn’t have thought of myself.”
“It’s an app that needs to be made — you need to make it!”
I learned to treat my work as a constantly evolving theory that was there to be tested and improved with users, never defended. I found that recording sessions and listening back to them allowed me to hear more clearly what people were saying, and not what I wanted them to say. I learned to allow myself to have ideas without judging or dismissing them right away.
I found it important to repeatedly re-read my early assignments because it kept me centred in real user needs. I had started with an interest in disability but this somehow had fallen out of my design by the halfway point. It’s all too easy to design with a “standard” person in mind, when real human beings are pretty varied.
Many details in the app are based on things people said to me. The option of “minimal walking on transport leg”, is based on a disabled walker who found she sometimes got tired out walking through boring streets from the bus stop before she reached the real walk in, say, a pleasant woodland. The “busy rating” for walks has been universally misunderstood as for avoiding crowds, but was actually an attempt to address concerns of women walking alone who wanted to avoid lonely places for fear of attack. I don’t think my solution is that successful, but I’ve left it in as a placeholder for a better one.
If I was building this app for real I would do the following (leaving aside some hefty business considerations):
- A thorough technical feasibility study. I am confident that a version of this could be built, but it would rely on third party applications which would need investigation. The prototype is a wishlist, an aspiration. Contact with reality might cause significant changes.
- Because the project was so time-constrained I could not study in depth how the app should support the user while walking, although I got a lot of good insights, and I would look again at this. (I originally sketched in a satnav option but people didn’t seem interested so I took it out again to keep things simple.)
- I would talk to many more, and more diverse, potential users as I mostly had to rely on friends as participants for reasons of time and they tend to be quite similar to me. This is absolutely the wrong way to do user research! Encouragingly, I had positive reactions from testers on usertesting.com who were less similar to me and not in London.
- I would also consider use cases further. The prototype fits the “single user/couple departing from home in London and returning there” scenario, but how well does it fit, say, “multiple users meeting at a mainline station and departing from there” or “person living in rural Cornwall”?
- CONTENT. An app such as this would rely on the quality and number of walks in it; ideally new walks would be added all the time to keep the user returning. It would be worth considering an additional area of the app for the user to easily create their own walks. I have thought from the start that Walkaway might be part of a bigger app.
- How would one keep people coming back? I designed the app for people who could be encouraged to walk more, and it’s important not to try to be all things to all people, but some of my testers felt it was for casual use and would need development for more serious walkers so people could progress and keep using the app.
- Crowdfund it. This would be a great way to test whether people really wanted the app enough to make it happen!
The prototype still feels like a working theory, but I‘m happy that I addressed the brief of Change and my original goals. Please do chip in in the comments if you have any suggestions for improvements. And now I’ve handed in my last assignment I can stop staring at the computer and go for a nice long walk.