SOGO.NYC - UX & UI Case Study


Your New York City transit planner.

View SOGO Protoype


New York City has the highest rate of public transportation use of any American city, with 56% of workers commuting to work via public transport every day. More than 8 million riders use the MTA rail system every weekday, and the bus lines further serve 5.5 million riders per weekday.

Public transit in New York, while commonly used, can be complicated to understand and navigate, and even harder to rely on. Needless to say, this results in many scheduling issues and wasted productive hours.

The millions people that rely on the transit systems of New York to get to work every day need a better way to move efficiently through the city, and need to be able to make educated travel decisions on the fly.

My Role

Developed the concept, conducted market research, defined market opportunity and target audience,  refined the feature inventory and feature prioritization, made user flows, sitemap, low fidelity and high fidelity wireframes, created logomarks, designed comprehensive high fidelity UI screens, style sheets and specs, and basic screen flow prototypes.

Product Development Process

Initial Research

Our goal is to empower the user to move around New York as efficiently as possible, so it seemed like the app should include all of the major modes of transit in NYC. Unsurprisingly, the most commonly used are the subway system and the bus system, but there were several other options that seemed like they could be a useful fit when trying to plan a route with mixed modes of transit. 

  • Subway
  • Bus
  • Ferry
  • Carshare (ZipCar, Car2Go)
  • Bikeshare (Citibike)
  • Taxi
  • Rideshare (Uber, Lyft)

This app would likely have a fairly broad set of users, as it would be useful to nearly anyone who rides NYC transit on a regular basis. However, I created a user persona who had a compelling need for a product that allowed him to plan better routes throughout the city, so that as I developed the product I could check back to be sure it was solving for his specific needs.

The areas of focus for the app were the things that seemed like they would matter the most to AJ as he used the app:

  • Current/Updated transit info
  • Comprehensive options for mode of transit
  • Ability to Combine modes of transit
  • Intuitive to use the robust feature set
  • Ability to Plan en entire schedule/route for the day
  • Step-by-step route assistance once en-route
  • Accurate Timelines for travel time

Market Research

It seemed unlikely that there weren't already apps existing that would share at least some functionality that would let NYC residents see their travel options. There ended up being four other apps that served similar purposes: Transit, Moovit, Embark, and CityMapper. I made a feature inventory, listing out the features that I thought would be most useful for AJ in an app, to see if anything existed already that had all the bases covered.

Overall, the Transit app had the most complete feature set, and all of the other apps did seem to be decently good at the core functionality of finding routes and then navigating the user through the city. However, there were various key features missing from all of them, including simply showing the transit cost and allowing for filtering for the type of route and mode of transportation. 

One piece of functionality that was not present at all in the other apps was the ability for a user to enter multiple locations at a time, in order to plan an entire route for the day. The other apps all require the user to enter locations on at a time, as you need them. Multi-location route planning seems like it would be especially useful for AJ.

Defining the Product

At this point, having defined a user and analyzed the competition, I was able to formalize a problem statement:

The people that rely on the variety of public transit systems need a way to be able to see the combinations of travel options available to them, schedule their routes, and receive status updates so they can make intelligent travel decisions on the fly as conditions change.

We believe that creating an experience that allows NYC public transit users to see a range of options and schedule their routes in advance will lead to an increased feeling of empowerment because they can confidently make the best planning decisions to help achieve their own daily goals.

Once the problem was clearly defined, I was able to make a feature prioritization chart.

The features in the High Impact + Unexpected quadrant were the ones that would be the biggest product differentiators. In particular, I felt that the ability to enter multiple destinations at a time would be a unique feature with strong utility for "power users" that had days full of scheduled appointments. Making the app specific to NYC is also a differentiator, as none of the other apps had a complete list of transit options for New York, and instead used more generic options that were common to other large cities. Finally, showing the cost seems like a very simple and useful thing to do in order to empower users to make the most educated decisions, but only one of the other apps attempted it.

App Structure

At this point I moved into sketching an initial sitemap, and then charting some user flows. 

Sketching the app flow initially by hand was useful because iet me move faster, and the incomplete areas were much easier to notice once there is a visual in front of me. In this case, I realized that there were several steps in the actual flow that I still needed to account for in order to fully meet the user needs.

The sitemap sketch basically helped me create an organized sitemap much faster once I took it to vector. It also made me realize that I needed to account for the options available in my planned tab navigation in addition to the screens found inside of the normal user flow.

After sketching, I made clean versions of the app flow chart and sitemap:

My next step was to begin to design the UI by sketch some low fidelity screens on index cards. I find this very useful, as they are about the same size as a phone screen and allow me to walk through user flows by sequencing the index cards, and it also helps me identify where specific design elements can be placed in ways that are consistent and intuitive UI patterns.

High Fidelity Wireframes

The final step before jumping into actual UI design was to create high fidelity wireframes.  I designed these in very high-fidelity in terms of placement, proportions, type sizes, and spacing, and actually did a lot of my visual problem solving here so that the full UI production would be focused more on styling. Below are some of the more complex screens, although I made high fidelity wireframes for every app screen.

UI Design

The first step was to set up a color palette for SOGO. It is a robust app with a lot of features, and a lot of potential to be confusing due to the amount of data present on many of the screens, including the critical "live map" screens — so I decided to design the UI to be be a very minimal white, grey, and black palette so that the color that was there would really pop. To this end, I also styled a custom map in MapBox, so that the multicolor maps everyone is used to seeing wouldn't interfere with the navigation routes and CTA buttons. Allowing the color to pop would assist greatly in guiding the user through the multi-step process of setting up routes, and would also let the brightly colored bus and subway lines that New Yorkers know so well to really be easily identifiable.

I chose a bright emerald green as my primary color. The positive color associations of "green = go" were  too good to pass up, and I also liked the associations that green has with health, growth, and financial success. The rest of the palette is based on shades and tints of the primary green.

From there, it was a matter of designing all the components and defining styles in Sketch while maintaining a clear visual hierarchy and thinking about the various interactive states. Below are some of the key screens:


Using the high fidelity UI screens, I made a fully functional screen flow prototype in InVision, which can be viewed in a browser or on a phone here. 

Specs + Stylesheet

I organized the artboards and defined the type styles in Sketch, and then exported all the artboards to Zeplin, where developers could find specs, spacing, and color values for all of the graphic components. The simple stylesheet for type and colors plus all of the screens can be seen here. I also made a simple visual stylesheet in Sketch to demonstrate the interactive states for the various interactive components in the app.