The Obvious UI Is Often the Best UI
medium.com
medium.com
Google Analytics was also full of strange decisions and unnecessary complexity.
I guess they don't get the good designers on their B2B stuff either.
If I was in charge of the gmail team my first goal would be making it faster. It always feels clunky when you need to open gmail.
Presumably, Google Analytics would be big on dogfooding… which is probably a sign that analytics-driven development isn't quite as useful as it's been touted to be. It's probably got great engagement metrics though!
They have this highly data-driven process which optimizes for usage and engagement . The problem is I don't wake up in the morning and go "gee I really want to up my engagement with google maps today". The ideal information retrieval app consists of me retrieving information and closing it. This is antithetical to Google's monetization model, and thus Google Consumer design is not for my benefit.
That said each Google Product is like a different company and they do do good work here and there. Specifically the Google Cloud Console has improved tremendously over the years (no doubt due to massive investment). Is it perfect? Hell no. But I prefer it to AWS and Azure tremendously.
Might explain parts of my experience with Android ;-)
You're right about the GCP console which is well designed (although still slower to load than AWS or Azure). Clearly they have different metrics there.
Seriously, having to hunt for the features I actually need would seem to increase usage and engagement. Is that really the metric employed?
What other opinion are they supposed to "lean towards"? Their boss' opinion is the only one that actually carries any sort of authority -- you implement it whether you agree with it or not.
We need to stop accepting that we are the guilty party and trying to get our house in order while the one next door is engulfed in flames.
The problem is not in how we track our time. In how we organize tasks, in how we deal with technical debt, long-term maintenance, engineering disputes. Documentation.
Our problem is in being ill-informed consumers of requirements information. In accepting it instead of sending it back to be done over and refusing to start on anything other than basic R&D until it's sorted. If people aren't told in a clear manner why what they've done is wrong how will they ever improve? And if they know we'll do it anyway, why would they bother changing?
She replied that we weren't gonna do waterfall and that the data supported agile as the company wide prerogative.
I replied that what I was asking for wasn't necessarily waterfall, but I also had no other term to describe it, and so she shut down the conversation completely by going, "I'm sorry, but the data supports agile. This conversation is over."
It struck me at first as "What the fuck, seriously!?" but then I considered she probably wasn't the one who made that decision or pushed it, but also that I wasn't maybe being clear.
So it's helpful to hear that this a bigger issue throughout the industry from a vet Ave not just local to the company I started my career at and so have no other frame of reference
If you ask a user what they want, their answer depends on how their current system has developed. Maybe there's a good idea that they hate because in the current system it would require too great a compromise. Maybe there's a terrible idea that they love, because they haven't understood the horrible corner-cases.
The real strength of the agile approach is to help the customer figure out their requirements through experimentation, instead of asking them to deduce everything from first principles. Once everybody understands the actual requirements, the actual implementation should be fairly straight-forward, engineers can comfortably make design trade-offs, etc.
Of course, there's a lot of cargo-cult Agile, and buzzword-compliant Agile, and that might be more trouble than it's worth, so it's not a guaranteed cure-all. Even good agile can be ruined if the customer or management doesn't see the value, or doesn't understand the core "refine requirements through iteration" rule. Your mileage may vary, but that core idea is still a good an important one.
It still works a bit that way, but the parts you can really see are all of the metric dysfunction. And I blame Schwaber for setting this avalanche off. Of all of the Agile processes, Scrum seems to have the most surface area for attack by metric dysfunction.
I didn't think I'd end up missing Jeff de Luca so much. He banished story size estimates a long time ago, making Scrum feel like a step back to me. I've only recently heard of people rediscovering that you only have to split up stories that are 'too big' and you can still do fairly accurate estimates and projections based on the aggregate behavior of 100's of stories.
What I see missing or unstated in virtually every discussion is that time isn't the constrained resource. It's energy. There are lots of tasks I could complete in half an hour, but the strain of doing so would still mean I'd only get 2 things done that day. There are also things I can do in 4 hours that still leave me spent for the day. And plenty of managers who will try to make you question your self worth for not volunteering to do 2 of those things in one day because 4+4=8.
Think about that the next time you catch yourself on Hacker News and you scold yourself for wasting time. I'd lay even odds you're either recuperating from something you just finished, or frustrated by something (or being blocked by something) and taking a break.
Think about it when you're trying to articulate why you accepted 60 hours of work this week because they're trivial stories with a lot of wait time built in. They're trivial because they're intellectually and emotionally 'cheap' tasks. There are boring tasks that take every fiber of your attention and you will refuse to double up on those.
Because it's energy, not hours. Always has been.
And you know what else takes a ton of energy and social capital? Arguing with some fucknut about whether a story is 3 points or 4.
https://chrome.google.com/webstore/detail/simplify-gmail/pbm...
Similar experience with using Google Docs. Literally cannot figure out how to go to back to the document folder. I moved to Heap Analytics because the Google Analytics experience was so confusing and nested - I'm much happier now.
Take your example:
- Forward is in the lowest toolbar in the hierarchy, since it applies to a single e-mail.
- Archive is in the top toolbar in the hierarchy, since it applies to a whole conversation.
Does this mean there are no improvements possible? Of course not, but I think the UI choices in Gmail are mostly sensible.
If you want an actual map with useful map features like showing street names then OSM is a far better product.
I don't get me started on how gmail has been filtering the content of emails. I wonder how many services have been spam blocked because google decided to hide the unsubscribe links.
iOS 13 has moved even further away from Obvious UI (and more broadly, iOS since 7).
The problem is that each new generation of managers/ designers have to try to change shit around just to lesve their mark. "Lead the redesign and modernization of XYZ" looks much better in the CV than "maintained status quo" even if it means just coming up with total shite.
This was in contrast to lots of software at the time which was all hot-key based such that the only way to know what options there were was to look in a paper manual.
The only way to actually see full track names or artist lists is to wait for it to scroll by in the 'currently playing' view - you can't see the full name of the song before you play it.
There's no way to see label or release year. There's no way to see a readable version of the cover art.
I could go on.
This thread I think highlights the absolute dumpster fire that is the insane design choices they've made: https://community.spotify.com/t5/Desktop-Linux/adding-an-alb...
On the plus side, their metrics will show them I now visited the web site two times as I intend to go back and continue reading. That’s engagement for ya!
Edit: there was only one reply left :(
https://blog.codinghorror.com/sometimes-a-word-is-worth-a-th...
The Microsoft Word example is terrible too. The ribbon didn't fix anything, there's still too much to fit on screen at once. The old menus and toolbars were at least scannable, since everything lined up; the ribbon requires much more hunting to find what you need.
Is the Ribbon a panacea? Absolutely not. But I'd respectful disagree with anyone who claims it is "just as bad" as the old toolbars. They made a lot of accessibility improvements and reduce the training curve substantially.
I had a relative who ran a mailmerge to print some address labels once a month, which apart from the odd letter was all he did with Word. Without fail after Word 2007 (IIRC the one the Ribbon arrived in) I'd get a monthly call, that usually became long and painful, trying to let him print his labels. Few months later, I visited and put back his old copy of 2003. :)
Meaning with the graph design toolbar, it would be visible, but do absolutely nothing until a graph is selected. With the Ribben it appears when the graph is selected.
I don't see how a disabled toolbar, with no clue how to enable it, helps with user training or clarity.
'This is what I want...hmm...how do I make it work?' is a far easier process than 'I can't find what I want...where on earth is it?..does it even exist?'
And that late 90's advice still holds true. Though I am seeing a lot of it lately.
That would be fine, if gestures where complementary to on screen navigation, but often the gestures are the primary "UI".
Maybe one day they can get the camera to do some creepy eye scanning and pop up tooltips based on what we are staring at.
I find it mind-boggling that more than a decade into the smartphone revolution there are a zillion fart apps and (AFAICT) zero tutorial apps teaching a user what the verbs and affordances and conventions are.
I'm hoping I can find a better solution because I really hate it but at least it's "obvious" now.
https://uglyduck.ca/hamburger-menu-alternative/
(Sorry for what might look like self-promotion)
> Upon first launch of your app, introduce the user to the navigation drawer by automatically opening it. This ensures that users know about the navigation drawer and prompts them to learn about the structure of your app by exploring its content. Continue showing the drawer upon subsequent launches until the user actively expands the navigation drawer manually. Once you know that the user understands how to open the drawer, launch the app with the navigation drawer closed.
From http://www.androiddocs.com/design/patterns/navigation-drawer... (older versions of the docs, I can't find it on the current site)
They never argue for why increase of session time is seeing like something good. For the user, if they can do something quickly, they can spend less time with the software. The "65 percent increase in daily active users " something that happened as a effect to making the application more difficult to use.
"Increased usage" does not automatically mean the thing you are building is actually useful. A really good tool does it job and then gets out of your way.
Also, looking at the "Polar app" screenshot, not only has the top part of the application changed, but the lower menu is completely gone? Seems like a bigger change than the one on the top.
At this point, I think the UX of the application is way more important and worth doing user testing with, seeing the nitty-gritty of what's happening with the user and the application. Maybe Google did this, but judging by their UX in their products, they are all about those metrics instead.
And in that it's not even just about icon vs icon + text, but two very different kind of icons... One is a snake (?) and the other one a pen.
Edit: Also, want to answer directly to "the increase in use of features ": that also doesn't necessary means it's good for the user. Maybe they don't actually have any use of it, and what they could see before on the main page, they now try to find.
Point being, designing UX after metrics is a bit pointless, as it doesn't show anything that you should really care about when solving someones problem.
Gimme back a simple 90s design with a menubar and a folder tree on the left. Or a command line. Those UX were genius. These new ones ... i dunno
https://en.wikipedia.org/wiki/The_Humane_Interface
> Jef Raskin ... was an American human–computer interface expert best known for conceiving and starting the Macintosh project at Apple in the late 1970s.
It amused me to note that the manuscript came in the form of double-spaced Courier with hand-drawn illustrations. That seemed odd from a key designer of the Macintosh, which introduced the notion of fonts and page design to regular users. But he didn't have to do page design for this; that would be done by actual designers at the publisher. He picked the interface that did what he needed and left the rest of the job to somebody else.
It links to RITE. https://en.wikipedia.org/wiki/RITE_Method Sure, sounds reasonable.
TLDR: There is no obvious UI. There is only validated UI.
--
Bad management is bigger challenge than good design.
Too many times I've had drive-by management (pointy haired bosses) offhandedly override finely crafted user interfaces, tested and refined over months with real end users, forged by trained, experienced professionals.
Designing user interfaces is even more fun and rewarding than architecture. Which is why I gave up.
Trying to replay the previous episode of a show is one of the most frustrating interactions I have with any piece of software. They fill the entire screen with pilot episodes for a half dozen other shows, but can't find anywhere to put a "back" button?