I have lived in NYC for four years, and do not own a . Several of my friends do, though, and I’ve always paid attention to the way they talk about street cleaning. Dealing with it seems to be a uniquely stressful part of their lives. When I ask them to explain why the process of moving their once or twice a week is such a hassle, they usually have a lot to say, and end up making street cleaning sound like some kind of wretched occult phenomenon.

For my most recent group project in the User Experience Design Immersive course at General Assembly NYC, we focused on this problem space. Over the course of 12 days, we designed LIEU: a car service designed to help busy people in Manhattan and NYC accommodate unforgiving street cleaning schedules. I had two fantastic group-mates: Naomi Krenitsyn and Alice Bae, and what follows is a chronicle of a very rewarding learning experience.

Initial Brainstorming

In retrospect, it would have been a good idea to just google “how to come up with a good idea.” When we first met to workshop ideas for this project, things just weren’t quite clicking. We were doing good research and having thoughtful conversations, but maybe the weather was weird, or the stars were aligned incorrectly — either way, we did not quickly arrive at what felt like the idea. Such is life.

We regrouped the next day, though, and things finally starting rolling. I don’t remember exactly how we came up with the agreed-upon idea (I think it was somehow tangentially related to a discussion about hiking?), but I can definitely say that caffeine was involved. By that point we were a day behind all the other groups and felt an extra sense of pressure: I think that spirit carried through the rest of the project to help us create something we were all really proud of.

First Phase of Research

After carefully studying our competitors in this problem space — including SpotHero, Parker, TaskRabbit, and others — we set out to begin doing user interviews. Our primary target audience was people with cars, and our secondary audience was freelancers, so we planned our research accordingly. We conducted extensive interviews with seven people who own cars in NYC and four freelancers, and distilled these conversations to a series of insights about their respective behaviors, attitudes, and pain points.

The insights we got from our interviews with car were:

  1. Users get stressed out about parking and think it is expensive.
  2. Users have to inconveniently adjust their schedule to keep up with parking laws and avoid getting tickets.
  3. Users’ driving habits depend on their location and job.
  4. Users are wary of other people driving their cars and need reassurance.
  5. Users trust professional services that are credible and come recommended.
  6. Users would pay $10–35 for a one-time use of our app’s service.

The most important thing we learned from freelancers was that they are comfortable driving other people’s cars for money if there is a system that protects them.

Screenshot from final prototype.

Design Process

Considering our limited timeframe, we decided to focus on setting up functionality for recurring car-moving schedules​​ as opposed to one-time use. Practically speaking, if this app were to exist it would need to have options for users who didn’t want their car moved every single week, but on our instructors’ recommendation we decided to aim for this more reasonably achievable short-term goal. Nonetheless, our interviews revealed that weekly street cleaning is a common pain point among car owners, so our recurring schedule design did directly reflect the data we were working with.

The biggest challenge we encountered while creating this app was having our designs reflect our users’ mental models of how they should work. Information architecture was something I always took for granted before working in , but now I understand just how crucial it is. When we would give users earlier versions of our prototype and ask them to complete a simple task, it was always fascinating to see where their sense of how information should be structured was different from what we designed.

During early rounds of usability testing, we would ask our generous volunteers to modify an existing LIEU booking, and they would go to a completely different part of the main navigation than we anticipated. This was an essentially a miscommunication on our end that had be rectified for the next version, and also a reminder of the ways in which information can be steered, modified, or perceived through predominantly tactile — or haptic — gestures. When somebody opens an app, you don’t want them to have to spend time figuring out how it works, they should just know. This is a very physical, non-cerebral thing, and as such, it is a strange and compelling foundational aspect of human-computer interaction. At the end of the day, you just want users to intuitively tap the right part of the screen without having to put any thought into it.

All this is to say: the main modifications we made to our LIEU prototype primarily took place on this level of detail. Important buttons were not always placed in the right places, and it wasn’t always clear how to find information about LIEU’s insurance plan, change account information, or figure out the answer to certain FAQs. Over the course of three rounds of usability testing, we changed the screen which provided users with information about previous parkers they had partnered with, simplified the navigation bar, and changed the iconography around to make it as clearly communicative as possible. At first, the overall system flow of the app felt like a tangled cobweb, and by the end, it was a whole lot neater.

You can see our final prototype here.

Closing Thoughts

For the first three projects of the course, we presented to our classmates and instructors after turning everything in. This time it was different: we were pitching an app instead of telling a broader story about our process, so we spent some extra time workshopping our presentation deck, and received feedback from our instructors on how best to convey the information we needed to convey in this different context. We tried to anticipate what sorts of questions they would ask us about the app, for example: How would parkers access the primary user’s car? (Our answer: a keyless lock system in the style of Zipcar.) I was pitching stories constantly as a cultural critic, but this was something else altogether, and ultimately a pretty unfamiliar kind of storytelling for me to try to do. I can tell that it’s something I’ll get better at with time, but it was a very cool experience to try to figure it out. We put a ton of hard work in out project, and it was rewarding to feel like we really had something to advocate for. It was a nice way to close out the LIEU endeavor.

We also plotted out some hypothetical next steps for the app if we were to continue its development. As previously mentioned, we would want to introduce one-time booking functionality in order to account for situations involving parking meters and any kind of unforeseen event. We’d also want to create an option for users to have their car moved back to where it originally was after street cleaning ends, and partner with an insurance company to figure out exactly what system would work best for LIEU. Lastly, it would be crucial to continue building out the app for the freelancer-user (we only did some initial wireframes in the scope of this project), and continue testing our high-fidelity prototype to get it ready for launch.

If you are curious to learn more about my previous projects, here are some other case studies I’ve written.

Source link


Please enter your comment!
Please enter your name here