Kind of funny that this is written by Google, responsible for some of the strangest UX decisions. Just look at Gmail. In the single email view there are 5 different toolbars, at different levels of hierarchy. Why is forward at one level, but archive at another? Why are there two sets of drop down menus? Maps is another disaster. Watching my relatively non-technical partner attempt to navigate Maps is quite eye-opening - different panes sliding in and out, Navigation, Places and Maps often conceptually colliding with each other leading to all sorts of confusion (unless you're very familiar with the Google suite of products).
In all fairness, our UX/UI design studio [1] has worked with engineering teams of big companies. Be it Google engineers or others. The problem, almost always, is that the designers try to design simple UX logic - Engineers try to implement that logic - but someone higher up urges those engineers to add ABC and XYZ. All resulting in an unclear direction, where the engineering teams usually lean towards their boss' opinion. And, unintentionally, remove any logic that was initially part of the design process. To design better products, there should be a better balance between designers & engineers. Adding one guy to your team to 'make this crappy looking prototype pop' isn't going to be very helpful for your users.
We have known for over twenty years that most problems with software come from the requirements phase.
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?
Holy Christ, I'm like a Junior Dev and once got into an argument with the CEO of the conglomerate I work for after a town hall meeting about how agile was basically only gonna accelerate how poorly we research "the problem space" as I called it.
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
No offense, but this doesn’t read as a situation you should feel vindicated about. Engineering management is a complicated beast that the average junior dev doesn’t see all the dimensions, let alone the nuances of. Town hall meeting or not, the “CEO of a conglomerate” probably doesn’t want an admittedly inarticulate opinion on what project management style not to use, especially without a clear alternative being suggested.
I don't, and my coworkers laughed at me when I relayed that conversation to them, I feel vindicated the issue around requirements gathering, and the effect that has on development, isn't unique to my company.
The best justification I've heard for the success of approaches like Agile is that they slow the software development process down and give stakeholders a chance to adjust to changes.
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.
Yeah that was always how it was sold to me too. But then the Dark Times came.
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.
I've found that ideally all product changes should be developed in close collaboration between a product owner, a UI/UX-person, and a developer. The design shouldn't be made upfront and handed to the developer, it should be made iteratively with the developer providing feedback. And the same goes for the product owner, giving input about user needs and their mental model. The developer should provide feedback about what is feasible and easy instead of just being expected to code up a design that's thrown over the wall. If you allow any of these parties to do most of their work before the others, then you'll get a local optimization that will either constrain the others to do sub-optimal solutions for their areas, or force the final result to break out of the optimum from the first area. The best result comes by having each side provide input in each iteration. Getting a team to work like this is rare though, in my experience - I guess that's part of what makes unicorns so valuable, since they'll integrate several of these roles in one person.
> All resulting in an unclear direction, where the engineering teams usually lean towards their boss' opinion.
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.
> After analyzing the user engagement statistics of apps that switched from semi-hidden navigation within hamburger menus to more visible bottom navigation bars, and apps that switched from more exposed to semi-hidden navigation, Wroblewski saw a trend. “Navigation is the manifestation of what is possible in an app and when people can’t see what’s possible, they likely won’t know what they can/should do in that app,” he told me in an interview about this idea. Increasing visibility boosts usage.
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.
Gmail and the consumer apps seem to be too data-driven to the point where the numbers are a self-fulling prophecy. Of course engagement goes up when confusion and bloat are added and users struggle to get things done.
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.
> 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".
Might explain parts of my experience with Android ;-)
> They have this highly data-driven process which optimizes for usage and engagement. [...] The ideal information retrieval app consists of me retrieving information and closing it.
Seriously, having to hunt for the features I actually need would seem to increase usage and engagement. Is that really the metric employed?
Not only that, but they've way over-simplified their UI in other areas where they actually sell services to the point where I can't even find basic setting menus because they've been eliminated from the main page and it takes me 10+ minutes as a highly technical user to try to find a simple thing like current billing prices or invoice records. Just awful.
> Google Analytics was also full of strange decisions and unnecessary complexity.
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!
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.
This is especially funny given that the "basic HTML view" is clear and relatively clutter free. I find it superior in almost every way, yet it's posed as the lesser alternative you have to cope with if you don't have JS or a fast connection.
Maps isn't about maps anymore, it's a location database that happens to show a map sometimes.
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.
It's like modern developers are slowly rediscovering things we knew when the Macintosh was released in 1984. Maybe in a few decades we can have computers that don't suck again.
Totally agree. Who thought that hiding regular menus is a good idea or using flat styles without any hint about what is a UI element you can click/interact with.
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.
The Macintosh had most commands hidden in menus. The lucky thing was that there wasn't space for a lot of commands. The writer of this article would probably recommend toolbars, which were introduced much later, possibly by Microsoft in one of their Windows applications.
Hidden is an interesting way to descibe menus. The UX people at the time called that making all options visible since you could click on the menus and look at all the options. They also recommended the menus not remove options but just gray them out if they weren't available.
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.
One of the motivations for toolbars (and the ribbon) is that there is a large group of users who never look inside any menu. Many users do not know about Undo. Many word processing users are unaware of things like tab stops, automatic indentation, line spacing, and styles. I have known an otherwise intelligent user who did not know that the shift key could be held down to get a capital letter - they used the caps lock key to get a capital and turned it back off after typing it. It's pretty amazing what is not obvious.
The original 1984 Mac used toolbars in MacPaint and MacWrite, just that I can recall. I wouldn't be surprised if they dated back further to Xerox PARC's GUI research in the '70s.
So true. So many designers try to be too clever, and bad UI is the end-result. Non-obvious design is excusable proportional to how-often I'm going to use something AND how many steps it takes away from me. Non-obvious design is really only good when it saves people time, but people will only put up with time-saving UI when they are going to be using a UI often. For example, Spotify's UI is a little counter-intuitive at first, but I use it so frequently that it's okay and I know how it works now.
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.
As I was reading this wonderful thread on mobile, I got a hilarious popup asking me to rate my experience and scrolling my page all the way to the top. Hilarious!
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!
I remember when I was first thinking about designing good pages, I picked up a book called something like "Ugly Websites" and it was drilled into my head that "mystery meat navigation" is always a bad idea.
And that late 90's advice still holds true. Though I am seeing a lot of it lately.
When I saw your comment my first thought was "Bluetooth" but in the context of the article, I can't figure it out either.
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.
The Ribbon is context aware, unlike the old toolbars. So if you're in a graph, you'll see the graph design Ribbon, if you're not then you won't. This gives users less they need to scan and or ignore.
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'll go along with saying it's not "just as bad"; it's far, far worse, especially when training. Disappearing things are incredibly disorienting to non-expert users.
It is worth stating that in neither case does it function without a relevant item selected.
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.
The disabled toolbar is easier because it still gives context and confidence you are looking in the right place.
'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?'
Maybe it's much better for someone using Office daily. Having seen quite a few who are occasional users struggle with the Ribbon it sure seems like they find it worse. With an old static toolbar they could at least hunt and (eventually) click. With the intermittent context awareness they were searching something that was often simply not there at the moment.
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. :)
Somewhat related: I often say that CLIs are GUIs. Letters are pictures to which we've assigned meaning, just like icons. They are just simpler and less ambiguous, and we're all taught a standardized usage from a very early age to the point that it becomes embedded in our brains for highly efficient processing.
This is exactly my problem with gesture based interaction, especially on the iPhone (I don't know if it's better on Android). The gestures are almost always not obvious. There's simply no hints that their are available or what swiping the screen in circles and flicking the home button might do. It may get you one step back in your browser history, it may do nothing.
That would be fine, if gestures where complementary to on screen navigation, but often the gestures are the primary "UI".
Even for on-screen controls, we're missing tooltips on hover which I think are a crucial part of discoverability for programs on a desktop PC. You don't get that on mobile (at best you get a 'new user tour', and have to remember every button up front, or pity you).
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.
The most non-obvious thing I've seen in modern software is the hamburger menu. Now that I'm used to it it's OK, but for a long time I didn't realize that the hamburger icon would bring up a menu and there's a lot I missed.
Our app is used by quite a few non-technical people. And we are in the process of figuring out something to make the hamburger menu more obvious. Lots of people still don't know that it's a menu.
Smartphones are full of this. Even if you've been using computers for decades, when you pick one up for the first time there's nothing to suggest, for example, that "swipe" is a verb, or what it does, or whether the direction matters and if so how.
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've been struggling with this, too. I was particularly frustrated by it last night and knew I needed to change the hamburger menu but hadn't really decided how so I put a grey placeholder button that said "START" a la Windows 95. Super ugly so I wouldn't forget to fix it. Except I totally forgot to fix it and pushed it to production. First comment I got this morning was how great it was.
I'm hoping I can find a better solution because I really hate it but at least it's "obvious" now.
I'm hoping a toolbar along the bottom does not work for your app, because I think the Start menu thing is brilliant. Your users have trouble with the hamburger menu that's common in newer UIs, so give them an older UI!
Well I waited all day for someone to tell me how awful it is and... I’m still waiting. So as much as I hate it, the BUB (big ugly button) does indeed live on!
Add text to the icon [0]
(the example is in spanish, but it's not much different)
That also helps to convey the meaning of the icon and educate peopple
Android used to recommend to open the hamburger menu when people open the app automatically, until they have opened it once themselves.
> 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.
It's not their fault. It really doesnt make sense. Three bars mean nothing except the greek letter Ξ. At least an arrow would indicate that there is something below.
> session time increased 70 percent, and daily active users increased by 65 percent nearly overnight
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.
Good that they are learning , because their designs are awful. I m struggling to understand why they consider their new adwords and adsense and search console an "upgrade". For example, I was searching the button to add a new campaign for 2 minutes between endless spinners, progressbars and "cards". There is absolutely no hierarchy in the page, even though the concepts campaign > ad group > ad are there. I don't even fathom how they manage to make such bluders on something simple
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
> Jef Raskin ... was an American human–computer interface expert best known for conceiving and starting the Macintosh project at Apple in the late 1970s.
Good suggestion. I got to review The Humane Interface in its later stages and it hugely influenced the way I design.
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.
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.
YES. And usability testing doesn't have to be anything fancy — DO USER INTERVIEWS! Even a handful of 30-minute sessions watching them use the application will have tremendous ROI!
I am all for using text in place of icons almost always. I read text fast. I have memorized the match between these symbols and their meaning and would like to capitalize on that learning.
Does anyone else find Hulu's new(ish) UI nearly impossible to navigate? Especially on smart TV apps, but also web and mobile.
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?
What’s funny about the bottom navigation menu is that’s how iOS was designed from the start. All the first apps (pre-App Store) and the first wave of App Store apps all used it. Then apps started to get busy, so the bottom menu was removed. Now people have realised if you make your app do 25 things rather than 5, it’s just too complicated, and we’re back full circle.
Interesting that iOS has had bottom navigation all along and Apple gets criticized for never changing things. Meanwhile Google adopts it after ditching their own terrible UX design and gets lauded for innovation.
I don't see that implication. I mean, the article is basically Google taking credit for going back to user interface design principles that Apple pioneered 12 years ago; whether Apple got its kudos back then has no bearing on whether Google's disingenuously backtracking on some of the major design features of Android's HIG and much of what makes the Material design … well, Material.
Seems this whole concept is also obvious. UI remains as a problem simply because it's a problem pertaining and invented by nerds. People with common sense don't recognize the existence of UI.
