P4

Project 4, week 7 of a ten-week User Experience Design Immersive at General Assembly in New York.

These assignments begin painstakingly slow—some classmates didn’t get their proposal approved until well into the work week—and (although each team has a project plan and manager) they end at a furious pace. Ed, Kevin and I were not the only ones banging our final documents a few minutes before deadline on Thursday night.

Proposal

For this project we were to pick a theme, brand and opportunity that the three of us could be excited about. We proposed “Waze for the wrist” an Apple Watch app that would allow New York’s Citi Bike riders to track road hazards on their route, and a companion feature for the existing Citi Bike phone app. As with Waze, the data would be available as an overlay on Citi Bike’s smart phone map, and could be sent to city agencies for help with law enforcement or urban planning.

We felt the proposal would be an opportunity for Citi Bike to engage more customers with branded digital products while improving bicycling safety across New York. In addition, it fit New York’s embrace of #visionzero, the international campaign to eliminate traffic fatalities.

Thankfully, our instructors approved the idea quickly.

Research

SURVEY

With limited time, we didn’t think we could pull together a meaningful survey of Citi Bike riders, so instead we wrote more general questions about bicycling and technology and tweeted them to hashtags used by biking organizations and ride share programs in half a dozen U.S. cities.

We confirmed a few assumptions:

• Many people ride bikes. Over 80% said they had ridden a bicycle in the past year.
• But more than a quarter of those respondents said they felt unsafe biking.
• Vehicles and potholes were most often chosen as complications to biking.
• Over a third said they had been involved in a crash while bicycling.

Although only a small handful of riders said they owned a smart watch, we assumed that as prices drop, watches will become more and more commonplace.

INTERVIEWS

My team took part of an afternoon to talk to Citi Bike riders at two stations in Midtown. Each of us did additional interviews with NYC bike riders on our own. The quotes we collected echoed the results of our survey:

“I bike all the time and I’ve been in four accidents with cars.”

“I’m afraid to bike in the city.”

“I broke my arm falling into a pothole. It would have been good to have a warning.”

CONTEXTUAL INQUIRY?

Our casual observations of NYC bicyclists outside our school building probably didn’t rise to the level of contextual inquiry. But two of us took Citi Bike rides (Ed is a regular commuter), and I watched the intersection of Broadway and 21st Street over lunch on a few afternoons. My biggest takeaways were not bombshells:

• New York bicyclists are often in a hurry.
• New York bicyclists do not ride safely. They ride against traffic, through red lights, through crowds of pedestrians and on sidewalks without warning. They seem to demand the respect of a car driver with none of the responsibility.

COMPARATIVE STUDIES

Running parallel to this user research, Kevin downloaded a number of apps from other ride share programs and did a quick comparative analysis of their features.

We also looked at a handful of apps built to track road hazards, including London’s Give a Beep and Philadelphia’s CyclePhilly.

TECHNICAL CONSTRAINTS

Part of the reason for this assignment was to learn what sensors are available on different devices, what data is available and what protocols are needed to use that data. Since we would be designing a watch app, Ed and I read the surprisingly enjoyable watchOS Human Interface Guidelines, and Kevin and I persuaded an employee to let us play around with a watch at an Apple Store over the weekend.

Synthesis

PERSONAS

We created two personas to give some personality to our research data. There was no correlation between gender, age and riding habits—we simply wanted to represent both female and male riders, young and slightly older riders, people riding for transportation and recreation, and people both marking road hazards and reading that data on a map.

FEATURE PRIORITIZATION

Using those personas, we brainstormed possible features and prioritized them using my favorite Soviet acronym technology. MoSCoW stands for Must, Should, Could, Won’t:

Design

APPLE WATCH APP

In the spirit of “mobile first”—the idea that you begin to design a website by dealing with its limitations on a smart phone—we decided to tackle the watch first. I sketched a simple flow and converted it into a medium-fidelity prototype that we tested on NYC bicyclists (using phones and laptops rather than an actual watch).

The user flow was straightforward. The app would load automatically when you check out a Citi Bike (as the phone app does now). An onboarding screen would remind users of how the app works. Then riders could tap the watch once when they encountered a pothole, debris, rough road or other physical hazard. Tapping twice would track close calls with vehicles, pedestrians and other bicyclists. And pressing firmly would allow the user to record a license plate number.

Testing

APPLE WATCH APP

Because of limitations in prototyping software, we couldn’t duplicate the watch’s “press firmly” interaction and ended up walking people through each type of interaction in order. Even so, we uncovered a series of questions:

1. Would the instruction screen disappear automatically, or would there be a “continue” button? Would the user see that screen every time they boarded a Citi Bike, or would there be a way to opt out?
2. Would the follow-up appear just at the end of the ride, or would there be a way for the user to add details immediately? If so, would that cause more of a hazard than it eliminated?
3. What if someone marked 6 or 10 hazards over the course of their 40-minute commute? Could they be expected to remember the details of each event? Or to take time to enter them when they arrived at their destination?
4. How would the voice recording be used? Siri voice translation is not great. Would it be good enough to help in sifting through the data? Or would it be a neglected field of error-ridden off-topic entries, like reader comments on a blog post?

We decided that we would require even less interaction with the watch: one tap would mark any hazard, and the confirmation screen would provide a recording option so users could leave themselves a voice memo to remember what they had marked. At the end of the ride, users would be asked to sort their hazards into three basic categories: rough road, lane blocked and near collision.

Critique and Questions

APPLE WATCH APP

In retrospect, we didn’t think through this as clearly as we might have — and we didn’t talk to enough bicyclists about the hazards they encounter and what technology would meet their needs. Two UX professionals reviewed our work and quickly made a series of diagnoses.

1. Ryan Snelson, a General Assembly instructor who works with early-stage startups, said that you really don’t want anybody doing anything with digital technology while they’re on the road. He asked us to think more about user behaviors, and to concentrate on what the user does before and after the ride.
2. Jess Greco, Director of UX at Pager who also teaches at General Assembly, noted that user interaction isn’t really necessary to track many of the hazards we’re concerned about. If the pavement is rough or the rider gets in an accident, sensors on the watch will know. If a series of riders slow or swerve at the same place, mapping algorithms will be able to tell there’s an obstruction in the road
3. Both asked questions about how the data would be used. What benefit is there to marking debris in a bike lane, or a close call with a driver? Neither of those are long-term conditions. Would the aggregate data highlight dangerous intersections, or just make a very messy map?
    
   Similarly, turning in someone’s license plate number might make the bicyclist feel better, but it’s not a trustworthy source for law enforcement—and there may be legal reasons you wouldn’t want to post private plate numbers on a public map.
4. In summary, Ryan said, you’re asking the user to enter a world defined by hazards. Think about the ultimate goals of the app. Does its use contribute to safety, or does it just make people paranoid and vindictive?

On the bright side, Jess and Ryan said that our project was minimum viable product (MVP) material, and one of the better proposals they had seen that day. They appreciated that we launched into our prototype rather than dwelling on our process.

A quick sidebar about process

I was an occasional consultant for the other half of our project—the modified Citi Bike phone app. Like in the last project, I was interested in mapping how the existing app works and finding improvements that were low-hanging fruit. But, like in the last project, I wasn’t sure when to fight for my ideas and when that was intruding on Kevin, who had ownership of the phone wireframes. Kevin himself suggested we work more collaboratively, but under tight deadlines and with different visions, it seemed like we all felt more comfortable working apart.

I also discovering (and rediscovering) that I need solitude to wrap my head around a problem before I can contribute effectively to a team. Each of our group projects have been ambitious tasks to begin with. When class schedules include lectures, homework and career-related tasks (all important things), time evaporates. When home life and self-care are also priorities, the remaining minutes can be swallowed up.

And then there are crises. Last week my computer overheated in my bag and baked the logic board, leaving me running to the Apple Store and working on equipment loaned by Ed and General Assembly. This week a physical plant emergency surfaced with a nonprofit board I sit on. And on Thursday I emerged from a marathon work session to learn that — in the 24 hours since I had checked the news — there had been two more horrific incidents of videotaped, race-related gun violence involving police officers.

Finally, my team was wary of scope creep. We had lots of good ideas, some of which we reigned in at the last minute because we were afraid we were losing focus on the one big thing we wanted to do: provide a way for riders to track road hazards and see those hazards mapped on the Citi Bike smart phone app.

Would of, could of

SMALL PHONE STUFF

So this is a laundry list of little things I wish my team would have recommended in addition to our One Big Idea.

1. One of my first problems with the app was that I tried to log in. I had never set up an account. Although there’s a way to skip the login from the first screen (orange circle, below left), that link disappears on the login screen. And there is no back button. The only way off the Login screen is to tap “Forgot your password?” and then, in the upper left corner of the “No worries!” screen, there is the slightest shadow of a chevron that takes you back to the home screen. So for my first easy fix, I would add a bright chevron and Skip Login link on both center screens (far right).

2.
It seems like many people who use the Citi Bike app would want to plan a bike trip. And indeed, a map comes up after the login screen. But the only way to plan a route is by tapping on a bike station marker on the map. Doing so centers the bike station you’ve selected and brings up a button at the bottom of the screen that says “Plan a ride.”

My team alleviated the problem somewhat by adding a “Get directions” list item on the main menu. I would restore the original app colors and make a few changes to language: rename the section “Map Options” and use the app’s existing language for the list items “Plan a ride” and “Map layers.”

3.
But let’s talk about this business of tapping on a station marker. Why, when you tap a station on the map, do you get a screen that lets you plan a ride, but if you choose a station from the list of Nearby Stations in the main menu (also accessed from the list icon on the right side of the nav bar) do you simply get sent to the Map with that station centered? Presumably you’re looking for a nearby station so you can take a ride. If so, you have to tap the station icon again to get directions. Wouldn’t it be better if the Plan a Ride modal popped up immediately?

4.
Speaking of the nav bar—can we do something to clean that up? Kevin had a couple good ideas that he said were supported by his user research, but Ed and I talked him down at the last minute. Maybe we shouldn’t have.

• Each bike station marker acts as a graph showing how many bikes are available. This is smart and easy to understand. What’s odd is that the nav bar contains a toggle that changes each marker from showing available bikes to showing empty racks to park bikes. The icon inside each marker changes, but the coloration does not.
   
  I’d love to talk to Citi Bike and do an extended A/B test on that toggle. I bet it’s more confusing than helpful. Except for a few stations that have valet service (and those could look different) if a station has lots of empty racks it has few bikes, and vice versa. I would remove the toggle completely.
• The Stations list icon looks a lot like the hamburger menu. If the empty rack icon is not being used on the toggle, I would use it for the station list icon. Or use the shape of the station marker itself.

5.
As one would expect, tapping the magnifying glass icon on the right side of the nav bar takes you to a Search Location screen (second in row below) where you can enter an address. When you click a location on the list, it takes you to the Map screen with a gray pin at the location you entered. Similarly, if you hold your finger anywhere on the map screen, it drops a gray pin on the map.

This pin does nothing. You can’t select it; you can’t plan a route to it. I propose that instead, searching for a location or dropping a pin would bring up the same Plan a Ride modal that I talked about in number 3.

There is more silliness, but I think I’ll quit with five wishes.

Next steps

BIG PHONE STUFF

As far as our main feature—showing reported road hazards—I’m not sure what I’d do. For our presentation, my team and I decided there would be one on/off button on the nav bar to control a map overlay containing all types of hazards, and each hazard would look the same. You’d have to click into each one to see what it was.

Perhaps that’s too simplified. I imagine most users would like to tell at a glance whether the road has a pothole or it’s blocked off for a street fair.

After talking to Jess and Ryan, I’m convinced that using data from riders phones, watches or even the Citi Bikes themselves is the way to go. It keeps the rider’s mind on the road and eliminates inaccurate and redundant marking of hazards.

Not all hazards are easily trackable or valuable to know about.

• A road construction filter, drawn from city data
• A rough road filter, based on bike movement.
• A bike traffic filter, populated by data from sensors on the bikes—or from riders’ phones while the Citi Bikes app is running
• A way of quickly, accurately and safely reporting the license plates of vehicles in bike lanes. If a camera were attached to the front of each bike and the images were processed with the same number-recognition software used on highway speed traps, that could be valuable to law enforcement and give bicyclists a way to channel their frustration. It would be fun to do a test with Citi Bike riders using Apple Watches to control the shutter.