Insight Author
Patricia Herrero
Senior UX and Product Designer

Designing a Wayfinding App

A Design Sprint Story

November 8, 2017
Marino Insights Cover Image

The Sprint

We were very fortunate to have the opportunity to learn directly from Jake Knapp, pioneer of the Design Sprint process and author of ‘Sprint’ - honed during his time at Google Ventures. We participated in a highly intensive, hands-on workshop in Bologna earlier this year and came back to Dublin all excited about this innovative design process we just had first-hand exposure of. Now it was time to put all our new learnings into practice so we decided to complete the Sprint process on one of our R&D projects. But what is a Design Sprint?

A Design Sprint is a ‘battle-tested’ process to define a problem, compare and contrast competing ideas, create a quick prototype, and get user’s feedback - all in 5 days.

This 5-days, 5-steps structure would give us enough time to test our product and answer critical questions, with a dedicated day for each of the following: 

The Design Sprint process

We decided on wayfinding as the topic for our internal Sprint. We've had plenty of experience working with mapping and location in mobile apps, but wanted to build a complete location-based system to push our ideas even further. For this purpose, we believed in the potential of using a blend of new technologies to design and build a wayfinding solution.

To narrow it down, we established the focus on a university campus wayfinding solution. As we are currently based in DCU Alpha campus, an innovation hub for companies in Dublin, we felt it would be the perfect setting for an initial test of our concepts.

We are passionate about technology at Marino and we will take any chance to venture into new technologies, so as well as implementing the Sprint process we took the opportunity to explore emerging technology, hardware and devices we were excited about. We were thinking in terms of augmented reality, IoT, wearables, voice interfaces, beacons or computer vision. So much potential and many things to try out, right? So, where to start?

The Discovery

Day 1 - Defining and Mapping the Problem

We started by setting a long-term goal for the Sprint: for a ‘person to be at the right place at the right time, no matter their ability’, achieving this by effectively routing people around the campus.

We continued by turning fears into questions by writing ‘What If’ notes that would surface possible issues we might encounter. With our ‘What If?’ notes we started to think about potential technology limitations, app discovery and adoption, last minute location changes, facilities discovery, accessibility for people with disabilities, and overall, about the need to design for everyone, no matter what that person’s ability.

Defining Project Goals, What If's and User Flows

Once we listed all our initial questions, we mapped out a basic user flow of how they would start interacting with our product and the steps a user would follow to get to their destination.

From the beginning, we considered our audience, and had a discussion of the benefit of designing for ‘residents’ (‘students’, in a normal university setting) vs ‘visitors’. This was tricky to decide since, in our view, both audiences would have similar needs in some contexts but very different depending on the type of campus. In our case, as we are based on a university innovation campus occupied by companies, there are no classes or students as such. Since we wanted to test with our current location, we decided our primary audience would be ‘visitors’, people who might be looking for a company office they are about to meet, a meeting room or any other place where an event could be happening within the campus.

Coming up with Inspiration 

‘Lightning Demos’ are a great way to get a good understanding of what’s already out there. Before we got started, we decided to carry out some individual research and come back with a few ideas each, so we could discuss as a group. We didn’t limit ourselves to look at competitors’ products but to a range of concepts that solved similar kind of problems in any context.  

The range of ideas we came with was broader than we imagined. We took inspiration not only from other products or apps, but bowling or Hotter/Cooler games, research papers, spatial sound videos, film scenes and even Geiger Counters. Some interesting examples we discussed were:

We drew one idea per sheet and presented them to the team. After discussing all ideas, we organised them by topics as orientation, tactile navigation, spatial positioning, companion, speech, computer vision or context.

Organising Lighting Demos by topic

We found this part of the process very valuable. The ideas captured by the team provided creative solutions that contributed to solving our problem from different perspectives. This was the final step in gathering all the inspirational materials we needed to start sketching a solution.

Sketching Solutions

After a full day of understanding the problem, deciding on a goal for the Sprint and getting some inspiration from our Lighting Demos, we began focusing on solutions.

We started generating ideas individually, they could be written or drawn, didn’t matter. These ideas would feed into our ‘Crazy 8’ sketches. 

Getting our initial ideas down

For those of you new to the Design Sprint process, the Crazy 8 exercise basically consists on producing 8 different sketches on a 8-times folded sheet of paper. You can experiment by drawing your initial ideas, then exploring the opposites, thinking of alternatives or work on a flow. Challenge is, you have 1 minute for each idea to be sketched - no pressure!

‍We survived the Crazy 8s!

Day 3 - Decisions, decisions...

At this stage we had a stack of solutions. That was great, but it was also a problem since we couldn’t prototype and test them all. To decide on what ideas we would focus on, everyone was given small dot stickers to mark the ideas they considered should be included in our prototype. This would create a heatmap that would guide us towards what ideas we should include in our storyboard. For this process to work, a person has to act as the Decider to make a final call when voting - so our Decider received extra dot stickers to vote with. 

‍Deciding on what ideas to address in our storyboard

Storyboarding: Planning the prototype

Once we decided on our focus, it was time to create the storyboard - a plan for our prototype. We chose to sketch out a story for a user to find their way to a destination being led by 3D spatial sound and audio cues. We drew the whole flow we were thinking of, which included voice recognition, AR and computer vision.

We carried out research on how to design for voice and wrote a script to suit the storyboard. However, this wasn’t really the core of our user testing since we wanted to firstly confirm if 3D spatial sound guidance would work so we focused on prototyping how to guide a person on a journey from A to B.

Sketching out storyboard

We also sketched secondary interactions as checking your current location, how arrow directions might change or how a user might switch between views. We wouldn't be using these yet, but it was useful to put those thoughts down for now.

Sketching out other interactions

Day 4 - 'Faking' it, time to prototype

For our initial prototype, there were a few elements we were wondering how to ‘mock up’ to quickly test our concept, such as 3D spatial sound, haptics, warnings or 'happy jingle' sounds. We decided to only choose some elements for our first few tests and went for the 3D spatial sound, warning elements and audio cues. It was time to make it real and create a 'fake' model of the final solution. As Google Ventures says:

"[Day 4] is about illusion. You've got an idea for a great solution. Instead of taking weeks, months, or, heck, even years building that solution, you're going to fake it. In one day, you'll make a prototype that appears real....And on [day 5], your customers—like a movie audience—will forget their surrounding and just react."

Prototyping a solution certainly presented a challenge for our design team, since visual interfaces weren’t the core element we had to plan and prototype. In this case, the core task lied in 3D sound and voice interfaces - a more abstract design to represent and communicate, as you might imagine. 

We also had to prototype this fast, it wouldn't be realistic to be able to build a fancy 3D sound app in a day so we had to be creative and find ways of 'faking' the experience for our testers to feel they were being guided by an app. We had to go out and measure the number of steps a user might take to complete our test route, create a constant sound that would guide users in the right direction or find a soundscape app to mimic how 3D sound might work.

Since we wanted to test our 3D sound concept first, we decided not to start prototyping the UI yet but focus on guiding a person by the sole use of sound.

Day 5 - Testing early and learning fast!

We established as our user testing goal to guide people to their destination without the use of their vision. Our hypothesis was we could achieve this by using 3D spatial sound, combined with voice guidance in some cases. Even though we started thinking of a UI solution within the storyboard, we decided to leave this dimension out of our user testing scope.

For this first test, we decided to test the path between the DCU Alpha campus entrance and our office. Our core research question was: What is the best way of guiding a person to their destination?

A few different approaches arose from the Discovery phase and we wanted to investigate what would work best. Some of our questions were: 

  • Would providing people with the number of steps they need to take be effective to represent distance?
  • Should we use traditional right/left instructions or clock directions?
  • Will 3D sound guidance work on guiding people to their destination?
  • Will voice instructions or audio cues be needed?

After we established our user testing goals and research questions, we recruited a few volunteers in the office to test our concept - they didn’t know what they were getting into! 

Test #1 - Distance representation  

To get started, we wanted to test our hypothesis on distance representation. Our initial idea was that it might be easier for people to understand distances in number of steps than understanding metres to be walked. We were curious to test this idea, even though we were concerned about the number of steps not being calibrated for each person.

For this first test, we obstructed our tester’s vision and attempted to guide them to their destination by calling out the number of steps they had to take for every segment of the path. We complemented this by giving them clock directions (meaning 9 o’clock to turn left, etc.) when it was time to make turns. 

Our tester following our voice instructions and going off the path

The use of clock directions was based on research that indicated that: 

Blind people usually use a clockwise notation to orient themselves’.

Our findings:

  • Number of steps are relative to each person. As we had predicted, every person’s steps are different, thus while giving this form of instructions we quickly realised that it would hardly be precise. We expected these measures to be slightly inaccurate although we didn’t account for the particularly short steps people would take when you obstructed their vision. For this approach to work we would need to use a form of step calibration to assess how many steps a person should take to cover a given distance.
  • Need to warn users when going off-path. We observed that offering o'clock directions might not be enough in some cases. We observed our tester having difficulties walking straight due to the lack of vision and the need of ‘spatial’ warning sounds (meaning that user would hear them on their right or left side) to alert users when they are going off the path.
  • Need to communicate elevation changes and obstacles within the surface.

Test #2 - 3D Spatial sound using external source

For this second test, we also obstructed our tester’s vision and used an external sound source to guide testers to their destination. For this purpose, we created a constant sound that testers would need to follow. To complement this constant sound, we introduced the use of ‘spatial’ warning sounds to alert testers if they were going away from the path. Testers could hear these warnings from either their right or left side, according to their deviations from the path.

‍‍Creating sounds with the Figure app

Our findings:

  • 3D sound is an effective way of guiding a user to a destination. We found some minor issues we would need to refine but overall we confirmed the suitability of this approach to guide people without the use of visual representation or voice instructions.
  • Need to communicate approaching change of direction. We observed the difficulty to understand when they needed to take a turn before reaching the turning point. We are investigating potential solutions for this issue.
  • Idea: Use of off-tone sound to alert user going off-path. Substitute the warning sounds when the user was going off-path by an 'off-tone' sound - a variation of the constant sound. 
  • Idea: Use of sound to mark stair steps. While testing this approach, we also thought of the possibility of using a beat to mark each step while user was using the stairs.

Test #3 - 3D Spatial sound using soundscape app

In our third test, we also obstructed our tester’s vision and tried to remotely guide them to their destination. In this case, we were not talking to the tester directly but creating the illusion they were interacting with the sound only - getting instructions through their headphones.

We used the SoundShade app to guide people to their destination. We gave headphones to our testers so they could listen to a constant sound marking the way, and a secondary sound warning them when they were going off the path - located on either right or left side. For this we used a constant sound of a fireplace marking the way and a storm sound indicating deviations on their path and warnings on obstacles.

Using 3D sound to warn testers when going off path or finding obstacles

Our findings:

  • Lack of 3D sound positioning accuracy. This approach proved not as effective as the external source test due to the difficulty for users to identify where the sound was coming from. There was a confusion particularly to differentiate between front and rear, and also for 'in-between' directions (12 to 3 o’clock range, as an example).
  • A secondary sound source was effective to warn users. We used it to warn users when they were going off-path or alerting them of obstacles on their way.

What we learned

We successfully guided people to their destination by using 3D spatial sound (binaural audio), which validated our initial hypothesis. The Sprint process was a cost-effective way to test our concept. It allowed our team to have enough time to come up with ideas, test and learn from them, but not enough time to overthink those concepts.

This process gave us a shortcut to explore a range of new technologies without the time and expense of launching a fully functioning product. Testing early was vital for us to learn about what worked and what limitations we might encounter in future steps.

This project also allowed us to expand our knowledge on emerging technologies and explore new approaches to the design process. As we mentioned, it certainly presented a challenge for our design team, since visual interfaces weren’t the core element but 3D sound and voice interfaces - a more abstract design to represent and communicate.

This Sprint has made us certain of current technology limitations and how to work within these. It has also served us a starting point for a range of ideas we would like to investigate further in future sprints.

What’s Next?

3D Spatial Sound

As we confirmed the possibility of guiding a person to their destination by using 3D spatial sound (binaural audio), our next step to turn this concept into a reality is to build an audible wayfinding interface that guides a person to their destination.

We have started working on a 3D spatial sound prototype that guides people by using 3D sound and a complementary visual compass that defines waypoints to direct people to their destination. Our concept is that guidance wouldn’t rely on maps but on audible cues supported by a simplified interface to represent position, directions and final destination. We are investigating some additional challenges that arose from our user testing sessions as how to not only represent direction but distance through 3D spatial sound or how to communicate what direction 3D sound is coming from. We are working on refining this experience to effectively represent distance through sound and for 3D sound position to be clearer to users.

‍This process will also involve the design of meaningful sounds that will successfully guide people, and communicates the difference between front and rear sounds.

Geolocation technology

Alongside this, we are undertaking research on geolocation technology - investigating from beacons to wifi signals, GPS or electromagnetic fields. We are currently running experiments with beacons and looking for the best solution to accurately detect location both indoors and outdoors. Unfortunately, our findings so far have shown that currently beacons are unlikely to offer anywhere close to the accuracy that we would need for our initial 3D spatial sound wayfinding scenario.

We will therefore need to consider slight changes in our scenario to adapt to current technology limitations in a second phase of this project. Due to the mentioned limitations, we are looking at alternatives not to rely on beacons for positioning but use them as proximity landmarks.

For this purpose, our next step will be to build a beacon proximity grid to improve location accuracy. We started developing a sample application that places beacons throughout our office and maps out the nearest beacon - which would make tracking a person’s movement through the room possible and identify when they approach a beacon’s proximity.

Making it a reality

We have seen through this process that, while working as a cross-functional team, we can quickly get up and running with a new idea, each of us bringing our strengths and experience to creating something completely new. And now we’re looking forward to keeping on building on our initial findings. As Rick Farrell, Google's Senior UX Designer says:

‘Each phase of the (Sprint) process generates more than concepts, it actually generates motivation to get things done in the future.’

And this initial Sprint has certainly given us the motivation to continue to keep learning and experimenting with emerging technologies at Marino. Now it’s time to take what we learnt and make it a reality.

Are you interested in a Design Sprint?

Got a big opportunity, problem or idea? Need answers quickly? Our Design Sprint Package is a practical method for answering critical business questions. It works for companies or organisations of any size. Talk to us about a Design Sprint.

Take a look at our team's insights

View all our insights

Let’s chat about how we can work together to create something great

Get in touch