My team is designing an interface for a route planning interface similar to Google Maps or Uber: select a pickup point and destination. Unlike those apps there is a ~small set of acceptable pickup/dropoff locations. We've decided that in order to select a location, the user should tap on a map (not select from a list, or search for an address).

Currently we have two "buttons" at the top, styled similar to Google Maps, that serve triple purpose:

  1. Show whether the user is selecting the pickup or dropoff (by highlight color, reinforced by being tied to the color of the stops).
  2. Provide a label showing the name of the selected stop selection.
  3. Act as a large hit area for switching between modes

Three screenshots showing the various modes of the app screen

These label/radio buttons are clearly non-standard UI widgets. They are almost segmented buttons, they are almost a tab bar, except that they are stacked vertically instead of horizontally.

I welcome your opinions on this design (or suggested changes) as comments, but my question is: Can you give me a precedent for UI widgets similar to these?

I think that Kayak used to have this in their date-range picker, but they don't have this any more.

The Apple Store currently uses highlighting of large buttons for modal radio buttons, but (a) the labels on these do not change, and (b) these represent a fixed selection, not an application mode.

enter image description here

  • I don't know if there's a precedent, but at first sight I think it's quite confusing. Using the same map approach, why don't you simply use 2 steps and let users choose pickup , then in second stop they choose drop-off and passengers? – Devin Sep 21 '17 at 17:02
  • @Devin Thanks for the feedback. 90% of the time it should be one step: the system pre-selects an appropriate pickup spot, and the user taps once to select a destination. 5% of the time the user might mis-tap their destination and need to tap again to pick a stop on the correct side of the building. And 5% of the time the user might actually want to be picked up at a location farther away from the closest. The intention is to optimize the interface for the common case, while making it easy to reach the exceptions. From your comment and other answers, clearly we have more work to do :) – Phrogz Sep 22 '17 at 15:27

I'm not sure of any precedents for this besides the Google Maps example you mention already.

One reason that I'm not able to think of examples could be because there are a couple things confusing about them.

There are competing ideas being conveyed by the same "look".

Take your first screen for example:

[CLOSEST LOCATION] — This condition is satisfied; you can submit the request for pickup with this remaining as it is.

[SELECT FROM MAP] — This condition is unsatisfied, yet it looks just the same as the button above. If you want to keep these elements (see recommendation below), I'd recommend developing some way to clearly indicate that the field is satisfied.

Tapping the bright green "button" does nothing, and yet it's the most prominent thing on the page.

One thing that's a little tough to grasp is that the full-width, bright green button-ish element draws so much attention despite the fact that tapping it doesn't do anything. It's actually more of a status indicator than a button. The important elements are the locations, and yet they are hardly noticeable.

It seems reasonable to assume, as you already have in your design, that people are mainly concerned with where they want to go, and they'll likely looking for the closest pickup location.


Perhaps you can do away with the awkward pseudo-buttons, and do something like the following interaction:

In simple text: "Select your destination" and the user sees a map with pulsing, glowing, slightly larger, bright green dots, so their focus is drawn to interactive elements that are going to move them towards success.

*User taps a destination.*

"Your closest pickup location is Jefferson Ave. and 4th St. We can be there in 7 minutes.

Show where the pickup is on the map and provide options so the user can either Change Pickup Location or PICK ME UP!"

This would provide a clear, focused, streamlined experience: the user selects her destination and confirms. Optionally, she can change her pickup location.

  • No problem! It's a nice-looking design, for sure. Good luck – maxathousand Sep 22 '17 at 15:31

I love this question! I want to say something that I noticed right off the bat, then I have to go back to work, then I'll respond with a dutifully researched and fact-based answer. But for now...

  1. I like the popping color overlaying the b/w map. Just be sure you're meeting WCAG Accessibility guidelines 1.4.1 and guidelines 1.4.3 (you can use this color checker resources by WebAIM, or there are a ton of free ones out there).

  2. I dig the concept, most times I'm going to a "place" with an address, not to the "address". I assume the app will be able to zoom by touch?

  3. I don't love the radio buttons. Would that require a horizontal scroll for more passengers? That can be annoying. Would there be an option for voice? Could it be a select box? Or even a range that looks more tabular (as you said) which could take the bottom of the screen. Ok, good luck for now, and I will respond again.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.