Live data from Hacker News

Sometimes users prefer the less straightforward UX

blog.pwego.com

41–50 of 67 posts

Re: Sometimes users prefer the less straightforward UX

#41

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…

[deleted]

Re: Sometimes users prefer the less straightforward UX

#42

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 th…

"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...

Re: Sometimes users prefer the less straightforward UX

#44

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…

Yep exactly, maybe they just want to be provocative with their title so they framed it that way...

Re: Sometimes users prefer the less straightforward UX

#45
> 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.

Re: Sometimes users prefer the less straightforward UX

#46
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.

Re: Sometimes users prefer the less straightforward UX

#47

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…

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.

Re: Sometimes users prefer the less straightforward UX

#48

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…

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.

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?

Re: Sometimes users prefer the less straightforward UX

#49

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 th…

"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.

Apparently he assumed that people prefer trails they've selected to "follow" in the app. ¯\_(ツ)_/¯

Re: Sometimes users prefer the less straightforward UX

#50

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…

> 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?"

Post reply on HN