from Hacker News

Sometimes users prefer the less straightforward UX

by dispencer on 6/22/22, 11:41 PM with 62 comments

by sonofhans on 6/23/22, 12:26 AM
IMHO 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.
by waterhouse on 6/23/22, 12:35 AM
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.
by davidhyde on 6/23/22, 12:31 AM
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.
by finfinfin on 6/23/22, 12:39 AM
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).
by gwbas1c on 6/23/22, 1:03 AM
> 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.
by athorax on 6/23/22, 12:32 AM
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
by LudwigNagasena on 6/23/22, 12:37 AM
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.
by tomger on 6/23/22, 12:56 AM
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.
by csours on 6/23/22, 1:27 AM
HN users prefer commenting on articles that are incorrect.
by Yhippa on 6/23/22, 1:57 AM
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.
by II2II on 6/23/22, 1:26 AM
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.
by derefr on 6/23/22, 1:23 AM
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!
by lolinder on 6/23/22, 2:12 AM
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.
by golergka on 6/23/22, 12:57 AM
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?
by turnsout on 6/23/22, 1:15 AM
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
by torstenvl on 6/23/22, 1:57 AM
> 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.
by michaeljbishop on 6/23/22, 12:42 AM
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.
by dragonsky67 on 6/23/22, 12:22 AM
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?
by dwighttk on 6/23/22, 1:10 AM
>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.
by patrick451 on 6/24/22, 2:26 AM
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.
by Timwi on 6/23/22, 12:20 AM
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.
by listenallyall on 6/23/22, 5:41 AM
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.
by bigcat12345678 on 6/23/22, 1:06 AM
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?
by Markoff on 6/23/22, 6:26 AM
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
by layer8 on 6/23/22, 12:31 AM
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.
by pabs3 on 6/23/22, 2:20 AM
Please also make available the raw data, so people can make their own UX that is better than yours for their personal use-cases.
by SubiculumCode on 6/23/22, 1:03 AM
What if you had sorted the first version by distance from location?
by solardev on 6/23/22, 1:05 AM
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.
by JoshTko on 6/23/22, 2:59 AM
TLDR: I made a bad design and users did not like it.