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.

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.

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.

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.

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?

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