City Sleuth: An Abbreviated Case Study

BACKGROUND

Sites like Time Out, Gothamist, Thrillist, and apps like Kamino and Field Trip proved that young adults of (all ages) wanted to explore their cities, and hungered for unusual, insiders’ knowledge about their urban landscapes. By gaming cultural exploration into a scavenger hunt, the curious would have a competitive reason to get off the couch, and onto the path less-followed.

Problem Statement

Hip urbanites want a means to find off-beat areas of their cities and the cities they visit because they would like to be more knowledgable about unusual facts and rarely visited places. We will know this to be true when we see users trigger information at those locations.

Product Solution

City Sleuth is a mobile, augmented reality app that invites users to tour different neighborhoods and collect site-specific information artifacts.

MY PROCESS

Interviews / Analysis
Personas
User Flows

Card-Sorting
IA: Sitemapping
Sketching & Wireframing

User Testing
Affinity Mapping
Revisions

Build
Collect Input / Revise
Plan Next Iteration

0.1 UNDERSTAND THE PLAYER

INTERVIEWS

To verify my assumptions about a scavenging app, and to begin the generative process, I conducted four scripted, F2F interviews with potential players. Since the app would be created for urbanites with free time, a discretionary budget and a hunger for cultural experience, and given the potential for adult content, I selected college-educated subjects over 21, skewing toward their 20s and thirties. However, it would be ill-advised to rule out retirees with a zest for experience and learning. So, I included one over-50 man.

All of the interviewees liked to explore cities in general, and New York City in particular. They all regularly sought new, out-of-the-way locations for pop culture, as well as drinks and food. Though only two had ever conducted a scavenger hunt, all the participants were enthusiastic about one dedicated to history, music, and mystery. Though they would use it to socialize with friends, and possibly with other players, they would not use it as a way of meeting people.

PERSONAS

After affinity mapping key findings, and cluster mapping emerging insights, I built three personas, which would ground the task analysis for user flows.

User Flows

Generative and competitive research clearly established the fact that people prefer scavenger hunts as a social activity. While our players users wouldn’t use City Sleuths as a medium to meet others, they would like to share the experience with friends and family. With the primary business demand to book hunts, two core functions are clear:

• Finding and booking a hunt

• Inviting friends to that hunt

The order in which these tasks are conducted seemed interchangeable, (and was verified by later interviews).

0.2 DESIGN

Preliminary IA

Knowing the users needs and expectations in accomplishing core tasks, the app seemed simple to map. However, I needed to check my expectations with potential players. With an open card sort, I asked research subjects to organize functions according to their expectations. Without a common nomenclature, it was sometimes challenging to interpret and categorize creative naming conventions. Nonetheless, a similarity matrix emerged that suggested some modifications to the app structure.

Noting the grouping of hunting searching and preferences, I restructured the architecture to group these with search. Likewise, it was clear that communications with friends and other players was important

WIREFRAME AND PROTOTYPING

Starting with paper sketches, I built up digital work for testing.

After concepting on paper, I built medium-res wireframes in Balsamiq. However, it became abundantly clear with the medium-res screens that duplicating functions on the home and hunt screens was at best wasteful. So, I tweaked the architecture’s site map, before building a hi-res prototype.

0.3 USER TESTING & REVISION

With a high-res prototype on Invision, I was ready to conduct remote and F2F usability testing.

The objectives for testing were to determine if users understood the app, observe interaction for usability challenges, and note any opportunities for improvement. In 2 in-person and 4 remote sessions, subjects largely matching my personas consented to be recorded with the clickable Invision prototype.

By Jakob Nielsen’s scale, the testers identified one minor usability problem, and a couple of opportunities for improvement, but no significant issues.

• Searching for a ‘Hunt By Name” was confusing, and in the next iteration became a search by zip code or neighborhood.

• “Saved Hunts” was confusing for first time users. It opened the possibility for on-boarding with brief, descriptive text.

• Younger testers, in particular, were eager to see Venmo as a payment option.

0.4 USER INTERFACE

Time for the visual build! Choosing a limited color palette, a Google font, and a grid system, I built out an initial style guide and first round of interface iterations.

Examining these screens for WCAG accessibility issues with tools such as ContrastChecker uncovered areas for improvement. Design peers also gave me invaluable input toward strengthening the latest prototype.

To view the current prototype, visit: https://invis.io/SVTB98UFC4Y

EPILOGUE

What Went Well:

• Initial generative research was very helpful in uncovering activities and apps that excite the customer base, and helped shape my product features. For example, I uncovered consistent desires for history, mystery and music, as well as shopping, food and drink. To launch a Minimal Viable Product, I eliminated all scavenging involving monetary transactions.

• Site-mapping refinement with card-sorting eliminated redundancies and superfluous design barnacles, and it streamlined user task flows. User input strongly trended in a couple of categories that helped refine an easy navigation for a simple architecture.

• User testing and peer reviews helped me shape my app into a well-recieved final prototype.

What Did Not Go Well:

• I scheduled inaccurately for my app.

• I had technical issues with recording remote user testing.

• It was a mistake to use an open card sort to evaluate an otherwise simple architectural structure. Subjects were very creative in both naming conventions and categorical association, which affected statistical correlation. Also, without a common nomenclature, many of the app’s features were sometimes whimsically grouped. I’m sure there would have been more rigorous thinking applied in a closed card-sort.

What Can Be Improved:

• Earlier and more frequent user-testing would help me build a simple and elegant architecture earlier, and also identify design choices that users tend to prefer.

• User content ratings for hunts have been suggested, and should be planned for in the next iteration. This would not only evaluate the features on existing hunts, but also provide invaluable insight into the development of new areas for business development.