Here's a design problem you may find interesting.

Feel free to help by answering or commenting. All input is welcome.

The design goal: an easier tool for users to enter a type of location on a mountain side. The location consists of:

  1. The elevation band: Alpine, Treeline, or Below-treeline. These aren't absolute elevations; they vary depending on where the trees grow on a particular slope.
  2. The aspect: North, Northeast, East, etc, the compass direction that someone is facing when they look downhill.

The thought is that two drop-down boxes are more error prone than a graphic data-entry tool. The data is combined with other data and then used in avalanche-risk assessment, to keep mountaineers out of danger. The thought is that users are conscientious about data entry; their own safety depends on it.

The proposed solution is still at the design stage; no code is written. The proposal started with three concentric circles, one for each elevation band, which are divided into eight wedges, one for each compass points. The users will click one of the 24 options that represents the slope on which they're reporting. A similar tool was spotted in another setting, but that doesn't mean it was tested for usability or data quality.

Since this is not a common tool, it was further proposed to add skeuomorphic details: the colours of trees and snow, and the mountain's shadow. The tools dimensions are large—so each target is bigger—in keeping with Fitts' Law. Have a look at the drop-down solution (left) and the proposed tool (right) in this mock-up:

Two drop-down boxes (right) versus a skeuomorphic tool (left)

A limitation: the intended users are not available for any testing, because their work is seasonal and currently they're all away. Testing with the general public won't work because they don't know the concepts.

Two questions: Are there other ways to get this input from users? What heuristics should be in play, here, to make the proposed design better?

  • 1
    I don't know about the aspect label because maybe that word is correct for the target audience, but other than that, this looks great – Devin Jul 30 '15 at 1:50
  • Thanks. Yes, aspect is the term to use. In the question, I provided a link to the Wikipedia topic on Aspect because I realise it's a strange domain to most of us. – JeromeR Jul 30 '15 at 7:39
  • 1
    Just a note about your comment on testing the general public, if the scenarios you provide them with are good enough, then it should not have an impact that they don't know the subject matter. For example, if you are testing the circle concept then asking the participant to select an alpine environment facing south should be enough. If they can't get the concept of selecting via the circle, then your experts may not either. – Varedis Jul 30 '15 at 7:59
  • 1
    @JeromeR this is a very elegant solution. One question: what's the user's micro-workflow here? As in, is the user naturally aware of elevation and facing? Or will the user have to think about elevation first, then think about facing? The 2-in-1 control is very helpful when users think intuitively in those spatial dimensions, but it can help to separate the axes into different controls if users are not cognitively used to combining the two dimensions. – tohster Jul 30 '15 at 8:07
  • 1
    Note: colours of treeline and below should be switched. Trees only grow below the treeline, and the part between treeline and snow is very sparse. illustration – PixelSnader Jul 31 '15 at 12:06

I agree with @nightning finding directions and accurately mentioning them is difficult.

Not sure what device you are targeting. But if that has an inbuilt compass then this solution may work.

Ask the users to point out which direction is downhill and then select their elevation.

Simple mockups to demonstrate how the first step can let the users just point the phone in the direction of the downhill and in the second step enter their elevation

Simple mockups to demonstrate how the first step can let the users just point the phone in the direction of the downhill and in the second step enter their elevation


I'm not expert in this field, still I see some flexibility can be provided to the mountaineer, like re-sizing and positioning the concentric circles to mean something like:-

There is no 'Below' on the East side, and I'm on the NE Alpine. Please refer to the modified image below.

Ignore this suggestion if this doesn't make sense.

enter image description here

  • Thanks. It does make sense. These users only need to select one of the 24 possibilities during any given task. So if there is no below, then they simply would not select it—because the users wouldn't report being at a location that doesn't exist. In fact, the mountains aren't round, they zig zag in all directions. :o – JeromeR Jul 30 '15 at 7:35
  • I'm just thinking about this idea some more. In essence, adjusting the circles to match reality is moving toward using an actual map, complete with contour lines. It was proposed. Dev said they could, and then the idea went away for some reason. It's worth revisiting. :o – JeromeR Jul 30 '15 at 20:05

Your proposed solution looks great and should work fine. That being said, I can give a few inputs to possibly improvise it. Mountaineers and Hikers use something called as Alpine Club Maps or AV Maps to orient themselves. You can take a hint from these maps to include certain things so as to provide a bit more details to mountaineers. For example:

  • Contour Interval - I know this is not exactly a map, but mountaineers will really appreciate this detail here.
  • Height information (if possible)
  • Scale (usually 1:25,000)

The advantage of giving these details is that mountaineers can directly align your tool with their AV Maps and can more precisely and easily enter details about their location. You can also refer to Austrian Alpine Club website for more details.

Hope this helps!

  • Thanks. Any idea is welcome, because it might help me think of a way to improve the design. I think the users are aware of elevation and contours, and they see these—and the scale—on their maps. This tool is only for entering the aspect and elevation band, in a multi-step data-entry process. Thanks for the link. Can you think of any other ways I might improve this tool? – JeromeR Jul 30 '15 at 19:37

I know nothing about mountaineering, looking at the concentric circles input diagram though these things stood out to me.

It does a very good job in concisely capturing the essence of the 2 dropdown menus and allows a user familiar to the system to quickly select their current location. However, it does take a moment to decipher what the diagram is representing. Not much of a problem for a repeat user.

Not sure if this is a problem for mountaineers, I personally am pretty terrible with directions. A downside to the diagram is that it requires the user to project their current location relative to the mountain from the POV of the mountain.

Suppose you have a compass in your hand, you look to find the peak of the mountain. You need to sort of use the compass to represent where the peak is to see that you're SE from the peak.


download bmml source – Wireframes created with Balsamiq Mockups

Whereas if you reverse the orientation and put the user at the center, you can ask where is the mountain relative to them. Then they can use the compass directly. It does mean you have to split this into two steps, but they're easy screens to tap through.


download bmml source

Mind you this is coming from a person who's directionally challenged. Perhaps mountaineers are used to reading maps and therefore this may be a non-issue and a single diagram would be more efficient.

  • Thanks. It's interesting: you want to simplify the control by making it two steps. We started with two controls and the idea is to see if we can reduce this to one. One of the other comments got me thinking that if we just use a map, everything else can be inferred/calculated by software—except the treeline, which varies. So that's still two clicks. :o – JeromeR Jul 31 '15 at 4:25
  • 1
    I'm probably influenced from working with too many over engineered legacy systems where a few more, but clearer steps help get the task done more effectively. -_-;; Re: maps: Funny, I also thought about overlaying a map and asking the user to indicate their current position. But then it becomes hard for the user to know where exactly they are unless they have a GPS device. And if you have a GPS device, you would still need to enter in your coordinates, which is a hassle. – nightning Jul 31 '15 at 20:10
  • 1
    Then I was thinking what if the system to enter the data is in on the same device and it can automatically save their current location. I figured you probably wouldn't be asking this question if the system can automatically determine the user's location... so maybe your solution is the way to go for the current scenario. – nightning Jul 31 '15 at 20:11
  • I really appreciate this feedback because you're setting me on the right path. The team is replacing a legacy product in phases; the UI is already designed to be responsive and touched (fat-finger friendly)—though on the mountain there's the gloves≠finger conflict to think about. The product uses a map in another part of the interface (reporting wildlife sightings) to interpolate data, so it's logical to extend/reuse that pattern here for elevation-and-aspect entry. This requirement might be a "me too" because someone saw it in action elsewhere. But if they insist, at least it'll be usable. – JeromeR Jul 31 '15 at 20:38
  • By the way, @Nightning, if you write this up as an answer: "Use a map" then I'll mark that as the answer. :o – JeromeR Jul 31 '15 at 20:44

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.