Demo 01

Storyville: Solution

02 Design Decisions


Focus on Core Functionality

We decided that our core functionality was allowing users to create and take audio tours. Our focus was to make this process as easy as possible. This meant removing any clutter or features tangential to this goal. We removed the ability for others to add their own audio clips (as a response or their own memories/facts) to tour segment locations, deciding that this would take away from someone else's tour and clutter the experience.

We still think that it would be a great feature, but because it was not central to the goal of the app and which needed honing and simplifying in this iteration, we decided to add this feature to our wish list. Streamlining our application workflow to make it as simple and straightforward as possible to make and take a tour was our ultimate goal. Instead of adding a lot of options, we decided to make the process have the fewest steps.


 

Being There

The current iteration of the app requires that people making or taking a tour be at the physical location. The app plays the audio segment for that location once you're there. Making tours location-sensitive allows tour creators to know that the tours will be experienced in the same way that they were created. We chose not to allow people to take the tours 'virtually' in this iteration because we felt that being there was what was really important to experiencing the audio portion of the tour.

 

Tour Accessibility

We realize that because of our user base (retirees), tour accessibility was a key concern for our design. By making the tour location context-aware during the recording phase we ensure trips are accessible for other retirees. Also, being context aware allows the application to suggest nearby place names when making a tour.

Tours can also be selected by level of difficulty using metrics like tour length (miles, stops) and activity level (easy, medium, hard). We assume these are calculated based on iPhone GPS sensors or through map topographic models while making the tour.

Our current design focuses on walking tours. However, other modes of transportation can be added in another version without changing the interaction.


Teasers

Users see a map and list overview of the tour before they start. On the map, they can see quick teasers of each location by tapping on the location before starting a tour. We found through our research (and in our personas) that although recent retirees liked to experiment and try new things, they wanted to try before they buy. We thought that the idea of teasers would appeal to them and enable graduated commitment.

 

Tour Flexibility

Storyville's simple make a tour flow allows users the flexibility to navigate listeners however they want: they can instruct users to their next location (as part of the audio narration), or create segments that start and end at a particular location. By using locations for each leg, users can wander a bit and still be able to come back to the tour without losing their way. This is because Storyville makes sure to include directions to the next location from wherever users are located.


Gentle Ratings and Creep-Proofing

We decided against star ratings, instead choosing a recommendation model. Because the goal of this application is community-building, we wanted every act of participation to be valued and appreciated. We thought that using a star-rating model (where users could rate a tour from 1–5), would promote a competitive, non-inclusive and potentially unfriendly environment.

Instead if people taking the tour like the tour, they can recommend it by giving it a 'thumbs up'. This encourages users to provide positive feedback and others can still sort tours by recommendations.

We also added a feature to report a user for review if the tour had any creep factor to it. This allowed for crowdsourced moderation of the community and content but at the same time allows a third party to decide whether tours or users should be blocked.

 

Rewards for Tours

During design iterations we decided not to include a reward or payment system for tours. It was initially included in our hi-fidelity wireframes (below is an example of a price button that was similar to ours), but we decided to remove any payment scheme for tours because it redirected focus from the community-building model. However, during class discussions we thought that adding tips for a tour or rewards would be an excellent option for a later iteration.

 

Context-Aware Information Retrieval

The information retrieved is transcripted audio linked to locations. The app let's you store and record audio tours. By organizing clips into tours, we make retrieving audio tours location and context-specific.

 

Senior/Retiree-Centric

We made sure that the application was targeted and suited for seniors specifically by considering accessbility at every step of the design process. All the measures used such as difficulty level, length, proximity are senior-specific. The UI also uses fonts that are for the most part larger than 12 pt. and large buttons. We also chose to stay with the basic iPhone UI template so that the look and feel is familiar and buttons that are logical next steps can be brightly colored to draw attention to them.

 

Customization without Complexity

We have made the application just flexible enough to offer the users a very personalized experience without having to walk through a cumbersome number of steps. The user gets a 'real' human intimately familiar with an area guiding them through a neighborhood with a unique viewpoint and in their own voice, rather than a less personal guidebook or history lesson. Users can make new tours and begin to have conversations about neighborhoods and within communities.

  


We hope you enjoy Storyville!




Basic Interaction Design   Spring 2011   |   Human-Computer Interaction Institute   |   Carnegie Mellon University