Why keep scrolling if all the names are arbitrary? Why read one random trail report from one random person? No one has actual needs that are afforded by the original design. What’s the user story behind this? “As a sheep, I want to maximize my engagement with your application, in order to meet your KPIs?”
They write, “See, I'd made the information so readily available that it left the user no desire to dive deeper.” This is baloney. The first design presented no information at all; at best it presented a small amount of data, and data entirely abstract from any human use case.
The map design allows people to easily pay attention, on a familiar substrate, to things that are important to them. It gives users agency and confidence in the future.
You don’t need to present users with a puzzle or a journey, or to manipulate them at all. If they’re not using the UX surface you put in front of them it’s not working hard enough to show that it affords their goals. Get to know your users better, and quit falling in love with your own designs.
Basically, I have no idea what I'm looking at.
Unordered data always gives me pause, because from a UX perspective, "unordered" today means "reordered" tomorrow. People will eventually learn to cope with your gonzo UI via muscle memory. If you can't put what they need to click on where they can find it, you're just inconsiderate. But if you keep moving it, now you're a monster.
Mountains, I'm lead to understand, have a tendency to stay exactly where you found them, as do the ski resorts that are so often built upon them. A pin on a map representing a snow covered hill is not going to move. And if it does move, you will have bigger priorities than skiing.
As for the title, there are situations where certain activities should be a little bit inconvenient, and the fact they are inconvenient gives your brain time to talk your reflexes out of doing something truly horrible, like setting off the Halon system, or pushing the emergency stop button, shutting off an entire server room, backup power be damned.
We separate things by workflow, and by subject matter, but sometimes we additionally segregate by consequence. "Wrong lever! Why do we even have that lever?"
Or worse, you'll have some spammer posting "Fresh powder at Mt. Perfect" when it's bare ground with ice patches.
Just a large list of reports only MAY give me a faster access to the info I want. If the trail I'd like to go to today is not at the top of the list / on the first page, it would likely take objectively longer to check the conditions for the place that I want to see.
What would be best would be a map that not only provides locations of the listed trails, but also a coarse indicator of conditions — just Excellent/OK/Marginal/Closed, and maybe a number of trails/km/miles open. Click to that, and NOW the list of reports by recency will give me the detail I wanted. This would be all WAY faster (presuming a properly responsive app) than scrolling through multiple reports that aren't relevant.
So, it seems we have different ideas about what counts as "complexity". I see a map as simpler than a list with the order that I don't want; the author apparently sees it as more complex (perhaps because coding the map and the selected lists is more complex than just the one big list?).
In any case, it is an improvement.
He says himself: "When surveyed, 76% of users reported that they only skied at trails within 30 minutes of their home. This was a huge breakthrough. It indicates that people place the highest priority on nearby trails". And so the users are happier with an interface that shows location. The idea that this is explained by users wanting their interface to be an unsolved Rubik's cube and users liking to hunt for information rather than having it be presented to them ... I can only hope that he's joking.
Incidentally, he could also have taken the original UX and added some "Sort by: [date | proximity | ...]" tooling, plus a field saying "X miles away", which would probably be more efficient all around.
People prefer trails within 30 minutes of their home as opposed to what? Within 72 hours of their home? I am not sure if a user survey was needed to determine this obvious fact.
Nobody cares about your “top picks” or “latest report”. When I look for a hiking trail I prefer to look for one pinned on a map instead of being curated on an endless scrolling list. Same goes for when I’m looking for a hotel in a city.
It would have been more interesting to compare "straightforward" vs "less straightforward" on the map view. E.g. show markers for all trails nearby vs show markers for your favorite trails (similarly to what the "card" view attempted to do).
No, in the original UI, the information that the users was looking for was not discoverable instantly, and it would have taken much longer than 30 seconds.
I suspect that the author originally wrote a UI that was convenient for them to write, and is going through mental gymnastics to try and justify to themselves why their original UI was better.
> So, despite it taking objectively longer for users to get their answers, they loved it.
Objectively? If a user wants to know what the conditions are at a particular resort, the map-based UI is objectively better. A UI that shows them data that they are not interested in is objectively worse.
I think this article is an example of how, when writing an application, it's easy to throw together a UI that matches our data model. It's much harder to make a UI useful.
For an app that is heavily reliant on geographical location, showing things on a map is way more intuitive than just showing whatever random location was last reviewed
> This is similar to having a list of the most popular book by each artist sorted by the book's release date. It's just a complicated set of relationships to think about.
Sometimes I want to do that. It just depends on the context.
Then the idea that "we added complexity to solve the user's problem" seems like the wrong takeaway. It's hard to tell how they came up with their initial UX. In my experience, you try a few different things, test them on real users, then adjust what a final UX could look like. I'm not sure if it has to be expensive to do that, but I think showing users an interactive mockup in a design tool and getting feedback from live users is a very important part of design.
That was the entirety of the author’s point. That was what the whole article was about. That’s why they wrote it, so that you the reader would understand the very concept you believe they missed.
This is their current understanding of what happened:
> So, despite it taking objectively longer for users to get their answers, they loved it.
What they completely fail to understand is that it doesn't take longer for users to get their answers. The map is faster, objectively faster, at solving the problem that the user actually has. The designer here missed that point.
They already described their app's use-case perfectly: it's "weather" for ski conditions.
So what does the Weather app's UX look like?
On first launch, it lets you add locations you care about by searching for them (maybe a map is involved temporarily.)
And from then on, whenever you open the app, you get a dashboard of weather conditions in those places you care about.
Sounds like exactly what they should be doing!
The first design assumes that if I open the app I must be interested in a random trail from my unsorted favorites set that happens to have good conditions. The second design does better not just because it helps find close trails—that's just one factor in my preference—it does better because it helps me to find reports on a specific trail. If those aren't favorable I can go to my backup trail and then on down my list.
As others have said, this isn't a failure to match the user's mental models or to provide enough of a "puzzle". It's a failure to understand the user's goal, the job they need your app to do. I would bet that a design that allowed users to pin trails to a dashboard (similar to a home screen) would perform similarly well or better than the map.
I don't think it was hard for them to conceptualize that. I think it was hard to guess that from the very emphatically not straightforward UI.
Start with the user and then figure out how to utilize your data to support your UI.
Dumping database records to a list view on the screen, no matter how pretty you make each entry, is rarely useful.
By this I mean regardless of how much work has to go into getting the information on screen, if it's just an information screen that does not allow much further interaction then the experience is finished after the first look. If you have to dig a little to find the information you are after, then the experience is extended which along with the feeling of discovery results in more satisfaction.
It's a problem I encounter when developing tools system support. I try for the simplest UI, but when presenting the tool inevitably get people asking how it took so long to develop something so simple?
As long they had already favorited the trail they wanted to know about.
original home screen offer trails by names you don't know so they are pretty meaningless, while on new screen you can easily find trails on map
not exactly sure how is this less straightforward UX, for me it's more straightforward than meaningless names I have no idea about vs clear display on map, 12 options instead 3 is also for me more straightforward
I would guess that many/most users would check things out first from home, maybe hundreds of miles away. They might use the results to decide which field to go to.
* Where any of these trails are. Are they even in the same area? State? Country? No idea.
* If any of the trails are any good
* Who those people are and why you should care.
* Whether those reports deserve your attention (no difference between "it was nice" and "this is closed due to a landslide yesterday")
Honestly the map UI is pretty terrible too. It still doesn't tell you anything useful about the trails. What does the duration even mean? Is that how far away they are from you? How long it takes to ski them? How long ago the most recent report was? No idea.
It feels like the UX was built by someone who's never tried to actually find a place to go skiing in a new area. I mean, this isn't even a new problem... just copy an existing app:
Trailforks already does it pretty well: https://www.trailforks.com/region/bend/?activitytype=1&z=9.3... (most popular mountain bike routes near a place)
Alltrails too, for hiking: https://www.alltrails.com/ shows you local favorites, super straightforward but tells you all the essentials (these are closeby, they're favorites because they're highly reviewed, here's how long they are, and a pretty picture) or the map view: https://www.alltrails.com/explore?b_tl_lat=44.16336969078622...
Not only were those the wrong lessons to draw from the two UIs, I think the bigger underlying issue is that the designer doesn't know how users actually look for places to go. Even when eventually given that insight, the conclusion shouldn't be "show a map instead of a list" but "I need to better understand what criteria are important for finding a place to go." Hint: It's not the recency of trail reports.
Maybe the trail reports view is just one screen out of many, and if so this would make more sense, but still... just look at how data-rich and useful the trailforks trail report view is: https://www.trailforks.com/region/bend/reports/ You can instantly pick a trail, or an area, or an activity/difficulty/whatever and see whether it's OK to go there. Much more useful than combing through a bunch of individual reports from anonymous internet people on a timeline. It's the aggregate data that's helpful.
