Sometimes users prefer the less straightforward UX
blog.pwego.comIMHO they’re taking the wrong lesson from this. Users don’t want complexity and they don’t want to hunt, but they desperately want not to waste time — they want some confidence that the action they’re about to take will further their goals. Showing an unordered list of unfamiliar names doesn’t further anyone’s goals, and it gives no confidence that further action will help, either.
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.
I was about to make a similar comment. The author even states this at the end "user's prioritize trails close to them, so the best way to show that is with a map". --- The first UX was NOT the most efficient way to show the information but the second one was. Therefore, users do in fact want the most efficient UX. He was just wrong about what that was.
This, calling the first design the most efficient UX shows how little empathy he has for his users. He built a UX for himself and faulted users for being "inefficient"
+1. "As simple as possible but no simpler" -- the takeaway is that the first UI was in fact "simpler than possible" to accomplish user goals, not that users prefer things to be less simple or less efficient!
I’m wondering what will happen if the first UX is ordered by proximity with distance to it and also a way to open it on the map. I think it’s worth trying it. Is a common use case for my searching for gas stations on Google maps
It annoys me that Apple Maps enroute will let me "see gas stations" nearby but can't do a simple "find the closest McDonalds to my current route" - I have no desire to turn around and back track even if that's currently the closest one, I'd rather have it say "in fifteen minutes there is one a mile from the freeway".
How would you make it clear to the user that they are sorted by proximity?
Showing the distance at the right of the list:
First place 1.4km Second place 3.6km third place 9.0kmStrangely, Google maps doesn't do this and just presents us with a list without any context
I agree with this. The initial design presents trail names and a report with no context. I would immediately wonder what the list was..is this all trails within 30 minutes, 100 miles, or something else? Why is this trail sorted at the top...because it's the closest or the best, or most recently reported on? And why this particular report? Is it just the most recent, or the most upvoted? And those tags...is that the tags from this recent report, or the most popular tags from all reports, or ?
Basically, I have no idea what I'm looking at.
Yeah, I totally agree — lack of context. Even a little context would help the original list, e.g., “Most reviewed trails in the last 7 days.”
> unordered list of unfamiliar names
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?"
Not to justify author's UX choices, but he does mention that the feed shows reports from the trails the user follows. It's not a list of random trail reports, there is some logic behind it.
That means zero discoverability.
I don't disagree, just noticed that many comments missed this detail about the feed showing reports for user's favorite trails, not some random irrelevant content.
He mentions it, but fails to make the UI show that. It just says "Trail Reports", and he says it's the main screen. And there's a search box at the top. Does that only search trails I've followed?
Google has trained people that the top search results are all ads, and that you have to scroll past them to get to the good stuff. If you make a UI which replicates that, people will have the same assumption.
Or worse, you'll have some spammer posting "Fresh powder at Mt. Perfect" when it's bare ground with ice patches.
I agree with what you're saying. Particular when you start using the app for the first time you have no idea what those reports actually mean. I suspect if he had an option for a widget or homescreen at a later point which shows users this list screen (with selectable favorites), it might find very significant use, but it is something the users have customised and now understand the meaning of.
Yes definitely seems like the wrong lesson but right changes
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.
I think you're right. The expected value of a result is generally low in these fundamentally geographical applications that try to avoid displaying a map. There tends to be both inclusion and exclusion error, and viewing things on a map helps for most applications of this type.
As a designer, this is absolutely spot on. I’d add that first time users benefit from the map, whereas experienced users might actually prefer the list view of favorites. It sounds like the app designer only tested with first-time users though.
Yep exactly, maybe they just want to be provocative with their title so they framed it that way...
The title is really a stretch. The "less straightforward UX" presented new information that the original UX did not—viz., where the locations were on a map—and made it easy for people to find the most recent report from a given location. I guess if you have memorized the names of all the trails you're interested in, and know their locations, then technically the original UX can be used in the same way by typing in those names; but if that's not the case, and if your approach is "look at the locations in approximate order of how nearby they are and view the most recent report for each", then the new UX is more straightforward. (Maybe it was less straightforward for the author to implement, but that is not what "straightforward UX" means.)
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.
"This was a huge breakthrough" caught me off-guard.
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.
Maybe they expected more users were the type to live in warm places and travel to where the snow was rather than live in cold places where snow happens? That's all I can think of anyway. That'd probably make more sense for downhill skiers though...
People who live in SF but are trying to decide if they want to drive up to Tahoe on the weekend aren't going to care about trails within 30 minutes of their home since the closest ones are 3 hours away. The author appears not to live in SF, but I assume they live in a city that similarly doesn't have ski resorts locally but does have them within day trip distance and were simply too focused on their personal usecase.
Apparently he assumed that people prefer trails they've selected to "follow" in the app. ¯\_(ツ)_/¯
The author of the app replaced a endless scrolling feed of snow condition reports for random locations sorted by date with a map of snow reports with the same information but more taps away. The insight was that users want more interactivity and discoverability but this is misplaced. The actual insight should have been that maps appeal to our spacial awareness more than names of places in random order.
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.
The post is missing the key point entirely. The issue here is not about a "straightforward" vs "less straightforward" UX. The "card" view likely did not work because users primarily wanted to check reports for a specific trail located in a specific area, and not browse through a feed of reports for pleasure. The UX wasn't just not straightforward—it basically did not work for the primary use case.
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).
> Now, instead of the info being discoverable instantly, it takes about 30 seconds
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.
I don't think the 2nd UX was in any way less "straightforward"
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
The first UI is just bad. It doesn't tell you how far the trail is from you, it doesn't tell you how many other reviews of the trail there are, it doesn't tell you the average rating of the trail, it can't be sorted or filtered.
Title is clickbait close to trolling. The Original UX was not optimized for the top use case and then OP came up with a better solution.
HN users prefer commenting on articles that are incorrect.
I would say that many of them like to make articles out of their comments... I usually skip to the third page of comments... sometimes I even start reading from the bottom.
This explanation was offputting for some reason. The author seems to insinuate that the original UX was "correct" and in fact it was too correct because users didn't want to use the app beyond that initial interaction.
> 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.
The author missed the point: it is a less straightforward UX if it doesn't meet the user's needs. When I choose a trail while riding, the first thing I look at is a map. It answers a tonne of questions, ranging from how am I going to get there. to how much time am I going to enjoy on the trails, to what I can expect to see on the trails. Lists mean that I am wading through walls of text to find the same information, which is a less straightforward UX for the task at hand.
> The author missed the point: it is a less straightforward UX if it doesn't meet the user's needs.
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.
If that was the author's point, then they totally failed to convey it. The title is "users prefer less straightforward ux", and the transition point in the article is the author coming to the startling conclusion that users like a "puzzle".
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.
> If that was the author's point, then they totally failed to convey it.
No, they conveyed it fine—because you understood it. You just thought the author didn't.
That's... a really weird take. If I listen to someone rave about a conspiracy theory and I can see the flaws in their reasoning, does that mean that they meant all along for me to come to the opposite conclusion of what they said?
Neither a feed nor a map is good UX here.
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 big problem with the first design was that people don't have a set of "favorite" trails that are all weighted equally. People have a favorite trail, and a backup trail, and a backup trail for that one, and so on. It's a list, not a set.
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.
May be finding a spot on the map may be much more intuitive, faster and comfortable to a lot of people than typing the name in a search box?
Just imagine how many engineering hours could be saved by spending 6 hours observing how 6 users interact with a prototype… I’ve worked with companies who spent millions of dollars without doing the basics to de-risk their product for the tiniest research spend. Yet they think research “slows them down.” smdh
> It was hard for people to conceptualize that the feed was showing the most recent report for favorite trails in order of report date.
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.
I think the lesson is to not think first about your data and how to put it on a screen.
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.
I wonder how much of this is also people wanting to see value for money?
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?
>So, despite it taking objectively longer for users to get their answers, they loved it.
As long they had already favorited the trail they wanted to know about.
This is such a bizarre article. Listing trails by the most recent report is almost totally useless. Who chooses where to go hiking based on a criteria like? It's really hard to understand what variable the author is trying to optimize if they think this efficient in any way.
I hope you will still include the faster, more straightforward mode for those who want it. Otherwise this is another example of catering for the common denominator and giving techies the increased impression that all software is dumbed down for the masses.
Some of these articles, the "before" is so absurd and unintuitive, that it is hard to believe the author actually built that app this way, as opposed to making up an example on which to base an article.
I guess the author try to blame a low value app's lack of user engagement onto the UI design. Then the excuse to apply dark pattern of UI design would be to increase user engagement. Sounds about right? No?
I wouldn't describe a map as a dark pattern. They're definitely approaching it as though it's a dark pattern (it's a "puzzle"!), but the second design actually respects my time much better than the first. The author is completely wrong that it takes longer to use the second design than the first.
from what I see original home screen offered 3 options and new screen offers 12 options to user
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
TLDR: Despite the title, users don’t want a less straightforward UX, they want a UX that fits their needs and mental model. In addition, the UI should reflect the app’s conceptual model such that the user will intuitively learn it.
Please also make available the raw data, so people can make their own UX that is better than yours for their personal use-cases.
What if you had sorted the first version by distance from location?
That would only be relevant if you were already in the vicinty.
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.
that's still quite useless if you are looking for particular trail or if you have no idea about geographic names around you
The first design did not tell you:
* 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.
TLDR: I made a bad design and users did not like it.