8 ms·

UX designer here who has done nothing but design web, mobile and related UI since about 2000, mostly working for or at large consumer brands (and now thinking o

UX designer here who has done nothing but design web, mobile and related UI since about 2000, mostly working for or at large consumer brands (and now thinking of retiring). I'd definitely agree with the idea that change for change's sake is responsible for a lot of usability problems. But a bigger problem is the near extinction of any professional discussion or capable analysis of design by the people who are doing it. Most designers I work with don't have the vocabulary or knowledge about what makes something "usable" in the wider sense, let alone the ability to actually solve subtle interaction design or information display problems. With no knowledge or interest in basic heuristics, they literally don't know where to start. So they just live in Figma playing with colours, shapes and effects, pausing only to show some variations of the same UI for "user testing". It's become a wilfully ignorant, "non-technical" cult of innovation that's completely lost sight of its original purpose. To say I'm ashamed of my profession is no exaggeration. We've failed so badly.

shrimp_emoji 3y ago
Sounds like the syndrome plaguing GNOME. :)
- sillywalk 3y ago
  I've always assumed that GNOME developers don't actually use GNOME. edit - (Not to disparage a ton of work by a ton of people )
cuddlecake 3y ago
As a frontend dev, what are good resources to learn about principles and heuristics that I can apply in my work? I have some knowledge, albeit very primitive, that I picked up from an HCI introduction and some good designers, but nothing too technical / formal yet.
- ProxCoques 3y ago
  It's more about trying to work out what motivates people to do things while using some reasonably simple tools like the N/N web heuristics to guide you. More a way of thinking straight about what qualifies as a good design under a certain condition, and what hypotheses to research and test out of that. So it's contextual. It may seem like there should be a more logical formula, but there's really not a lot of technical/formal things (along the lines of, say, accounting or structural engineering) that lead you to the best approach. My frustration is not that people don't necessarily know about these things (although I bet if I mentioned Bruce Tog to anyone at work they'd give me a blank stare), but that they can't marshal them in their work.
  - lylejantzi3rd 3y ago
    I think it's funny you don't see a connection between "Most designers I work with don't have the vocabulary or knowledge about what makes something "usable" in the wider sense" and your inability to answer the question "how do I improve the usability of my work (in the wider sense)." Maybe that's a place to start.
- toss1 3y ago
  I'm not a UI/UX designer, and am equally frustrated by the failures described in the article and other comments. One item I can bring to the table from the world of designing cockpits for racecars and airplanes is that the primary principle to follow is: Reduce Driver/Pilot Workload. Does whatever you are doing around the workspace increase or decrease the work that the driver or pilot must do? Can the status of [thing] be discovered (read/heard/felt) with minimum time and effort? Does [thing] create an otherwise unnecessary need to take even a quick glance at something? Is something in the way of taking an action, requiring an extra motion? Of course, there are some things that maybe it IS desirable to add an extra bit of work, e.g., a switch that kills critical [thing] maybe should have a cover over it requiring to flip up the cover then hit the switch; an extra moment of thought. This one principle translates well to software interfaces. Screw whether it "looks clean" or not — does it reduce or increase the user's workload? Even a tiny change can make a huge difference, because many actions are repeated. I hope this helps
  - rerdavies 3y ago
    I wish somebody would take that approach with Visual Studio Code, which is -- I think -- a particularly egregious offender. I would dearly love it somebody would take a 21st-century approach to time-and-motion studies for programming in Visual Studio code. I think Visual Studio actual did something along the lines of time-and-motion studies at some point in its long history. But I'm increasingly thinking that Visual Studio Code is having a a 3 or 4x impact on my productivity. Things seem to start out well with blank projects; but eventually, somewhere around the mid-scale 30k+ line point, all the advantages of all those incredibly great features in VS Code seem to be offset by scaling issues. There was a point recently at which I seriously thought I was losing my programming edge. But a recent adventure with a non-VSCode project, and a recent discovery with respect to the VSCode debugger is making me wonder whether it's my tools that have lost their edge. There are a bunch of things going on in that user interface of Visual Studio code that are completely tanking my productivity. A telling example: When using the Visual Studio Code GDB debugger, Visual Studio code fetches the local variables of ALL stack frames on ALL threads every time you single-step. This happens even when the thread views are collapsed. As a consequence, it takes between 10 and 30 seconds (depending on how thread-heavy your app is) to single step once. I was pushed over the edge when I dropped into a new project and Visual Studio Code was take three minutes to single-step. (Not a memory issue, not a disk issue, not an inadequate machine issue). So I did some research. This has been an issue since 2016 in Visual Studio code! The solution (according to message posted in 2016 somewhere on the internet): switch to the CodeLLDB debugger extension. The result: on the 3-minute code base, single steps take distinctly less than a third of second. It's like the frog in a boiling pot of water: you don't realize the toxic effect that kind of latency has on your your debugging productivity until it instantly goes away. 3-minute single-stepping is obviously impossible to work with; but the cumulative effect of taking 10 seconds to single step is definitely large. I can debug things orders of magnitude faster than I could before. I don't lose my train of thought. I can set breakpoints fearlessly, and single-step through dozens of lines of code -- all things I couldn't do with the default Visual Studio debugger. The only peculiar side-effect of CodeLLDB: the debugger expression evaluators use RUST expression syntax even for c++ code. Which isn't actually terrible. It's just very strange. But there are other things as well: the latency on Intellisense updates, where you have to wait 10 or 20 or 30 seconds for the error squigglies to update. Every edit becomes: type a few characters, wait for 30 seconds to see if Intellisense likes its, type a few characters.... And WHATEVER you do, don't unbalance parens or curlies, which will pin all available CPUS for minutes at a time! (Huge recent productivity improvement -- set the number of Intellisense threads to number of CPUs minus 1!). In the old days, on much less capable hardware, a compile would fail in 3 or 4 seconds; so you could just "type a few characters; press F7, wait 4(!) seconds, and see if the squiggly went away. Although typically, you would fix a few things, wait 4(!) seconds and see if the squigglies went away. (More-or-less instantaneous checks were run in the editor to check for paren/brace balancing). Instead, VSCode accumulates rats nests of red squigglies that wont go away until background intellisense completes (which could be 90 seconds or more), or until a compile completes, which runs the constant risk of facing a list of "12,000+"(!) errors in the error window, because you have an unbalanced paren or brace, which can take 10 or 15 minutes to straighten out. And the three or four G++ errors that are legitimate get buried in thousands of Intellisense errors that wont go away (that's a recent regression; you used to be able to temporarily filter out Intellisense errors). I'm increasingly thinking that Intellisense for C++ is dramatically tanking my productivity as well! I mean it does actually work on toolable languages, like C#+Visual Studio, or Java+Android Studio, where the tooling update time is sub-10-seconds. But for C++ it seems to be a disaster. (Wondering whether it actually does work, though). Build turnaround: there is NO obvious point in the Visual Studio UI to indicate that a build has completed. A tiny status message buried in the status bar. For some reason, my build output window always seems to come unglued from auto-scroll. And VSCode auto-tabs away from the Errors Window to the Build Window without un-de-autoscrolling. So you hit the F7 key, your eyes glaze over while a toxicly overlong build runs for a minute past the point where the error occurred, and you snap to 3 minutes later realizing that the build finished with errors, ages ago. Mouse-keyboard context changes. Switching your left hand from mouse to keyboard and back is an expensive operation relatively speaking. By my best estimate, I spend about 40% of my editing time switching between mouse and cursor keys. Whereas... on Visual Studio, major editing operations can be performed entirely from the keyboard. (ctrl+space, cursor cursor, carriage-return is burned into my muscle memory for some reason, even though it's been years since I used Visual Studio -- or is that Android Studio?). There's something seriously wrong there too in the arrangement of short-cut keys, mouse and cursor movements. Ctrl+Left/Right Arrow! There's a simple thing that is bizarely broken, that has a dramatic effect on my productivity. It does something seriously wrong, I'm not sure what, but it's not productive! It consistently takes you to the wrong edge of identifiers and operators, so you end up pounding on unmodified left or right arrow to get to the right place. I'm DEAD certain Visual Studio does it differently; and it's not a problem I've noticed at all in Android Studio. I'm convinced that a little time spent on time and motion studies could increase the productivity of average developers by dramatically large amounts. Something in the order of 2 or 3- or 4-times more productive. Most especially for Visual Studio Code, which -- for reasons I still don't completely understand -- seems to be extra-double-plus toxic for productivity.
- peterth3 3y ago
  The Design of Everyday Things, by Don Norman is a good place to start. https://www.amazon.com/Design-Everyday-Things-Revised-Expanded/dp/0465050654 https://www.amazon.com/Design-Everyday-Things-Revised-Expand...
incongruity 3y ago
As someone who works as a service designer and design strategist, I agree, 100%. I’ve seen a general decline in rigor in the field. Many are back to making things “pretty” with poorly done research (if that) asking small-minded questions rather than thinking about context, ecosystem and systemic effects of their design decisions.
- ProxCoques 3y ago
  I recently took part in a panel discussion about design strategy. I kept on being dragged into discussions about project management and process. In the end, I just gave up trying to explain and they all triumphantly celebrated a "good design strategy" as being how you intend to build the thing. The question of why, or on what basis, just seemed irrelevant.
  - incongruity 3y ago
    So, that kills a small part of me to hear - but also, I think it reflects this larger pattern of the UI/UX world’s seeming need to not just reinvent the wheel but large chunks of the history of the discipline of design rather than building off of thinking about systems and systems of systems by people like Jay Doblin and others.
abandonliberty 3y ago
>the near extinction of any professional discussion or capable analysis of design by the people who are doing it. People don't think through the designs then launch a poorly designed test that can't produce meaningful results. Copy the competition, latest designs, or hope the customer can do it. It's easier to do and defend. Put in the minimal amount of mental labor required to get paid. Not assigning blame here. These folks all work in an oversubscribed field subject to the whims and opinions of execs focused more on delivering visual appeal or feelings than usability. It's marketing. It doesn't really matter how usable your product is if people don't want to use it. Many industries make very usable things. Notably the military. They're just ugly.
joenot443 3y ago
> Most designers I work with don't have the vocabulary or knowledge about what makes something "usable" in the wider sense, let alone the ability to actually solve subtle interaction design or information display problems. That's wild. We _had_ to read Design of Everyday Things as part of an HCI course in my Software Engineering curriculum. You couldn't get your degree without having some working knowledge of affordances and signifiers. I was under the impression, at the time, that we were dipping our toes into a world which UI/UX designers were intimately familiar with. Perhaps not.

shrimp_emoji 3y ago

Sounds like the syndrome plaguing GNOME. :)

sillywalk 3y ago
I've always assumed that GNOME developers don't actually use GNOME. edit - (Not to disparage a ton of work by a ton of people )

cuddlecake 3y ago

As a frontend dev, what are good resources to learn about principles and heuristics that I can apply in my work? I have some knowledge, albeit very primitive, that I picked up from an HCI introduction and some good designers, but nothing too technical / formal yet.

ProxCoques 3y ago
It's more about trying to work out what motivates people to do things while using some reasonably simple tools like the N/N web heuristics to guide you. More a way of thinking straight about what qualifies as a good design under a certain condition, and what hypotheses to research and test out of that. So it's contextual. It may seem like there should be a more logical formula, but there's really not a lot of technical/formal things (along the lines of, say, accounting or structural engineering) that lead you to the best approach. My frustration is not that people don't necessarily know about these things (although I bet if I mentioned Bruce Tog to anyone at work they'd give me a blank stare), but that they can't marshal them in their work.
- lylejantzi3rd 3y ago
  I think it's funny you don't see a connection between "Most designers I work with don't have the vocabulary or knowledge about what makes something "usable" in the wider sense" and your inability to answer the question "how do I improve the usability of my work (in the wider sense)." Maybe that's a place to start.
toss1 3y ago
I'm not a UI/UX designer, and am equally frustrated by the failures described in the article and other comments. One item I can bring to the table from the world of designing cockpits for racecars and airplanes is that the primary principle to follow is: Reduce Driver/Pilot Workload. Does whatever you are doing around the workspace increase or decrease the work that the driver or pilot must do? Can the status of [thing] be discovered (read/heard/felt) with minimum time and effort? Does [thing] create an otherwise unnecessary need to take even a quick glance at something? Is something in the way of taking an action, requiring an extra motion? Of course, there are some things that maybe it IS desirable to add an extra bit of work, e.g., a switch that kills critical [thing] maybe should have a cover over it requiring to flip up the cover then hit the switch; an extra moment of thought. This one principle translates well to software interfaces. Screw whether it "looks clean" or not — does it reduce or increase the user's workload? Even a tiny change can make a huge difference, because many actions are repeated. I hope this helps
- rerdavies 3y ago
  I wish somebody would take that approach with Visual Studio Code, which is -- I think -- a particularly egregious offender. I would dearly love it somebody would take a 21st-century approach to time-and-motion studies for programming in Visual Studio code. I think Visual Studio actual did something along the lines of time-and-motion studies at some point in its long history. But I'm increasingly thinking that Visual Studio Code is having a a 3 or 4x impact on my productivity. Things seem to start out well with blank projects; but eventually, somewhere around the mid-scale 30k+ line point, all the advantages of all those incredibly great features in VS Code seem to be offset by scaling issues. There was a point recently at which I seriously thought I was losing my programming edge. But a recent adventure with a non-VSCode project, and a recent discovery with respect to the VSCode debugger is making me wonder whether it's my tools that have lost their edge. There are a bunch of things going on in that user interface of Visual Studio code that are completely tanking my productivity. A telling example: When using the Visual Studio Code GDB debugger, Visual Studio code fetches the local variables of ALL stack frames on ALL threads every time you single-step. This happens even when the thread views are collapsed. As a consequence, it takes between 10 and 30 seconds (depending on how thread-heavy your app is) to single step once. I was pushed over the edge when I dropped into a new project and Visual Studio Code was take three minutes to single-step. (Not a memory issue, not a disk issue, not an inadequate machine issue). So I did some research. This has been an issue since 2016 in Visual Studio code! The solution (according to message posted in 2016 somewhere on the internet): switch to the CodeLLDB debugger extension. The result: on the 3-minute code base, single steps take distinctly less than a third of second. It's like the frog in a boiling pot of water: you don't realize the toxic effect that kind of latency has on your your debugging productivity until it instantly goes away. 3-minute single-stepping is obviously impossible to work with; but the cumulative effect of taking 10 seconds to single step is definitely large. I can debug things orders of magnitude faster than I could before. I don't lose my train of thought. I can set breakpoints fearlessly, and single-step through dozens of lines of code -- all things I couldn't do with the default Visual Studio debugger. The only peculiar side-effect of CodeLLDB: the debugger expression evaluators use RUST expression syntax even for c++ code. Which isn't actually terrible. It's just very strange. But there are other things as well: the latency on Intellisense updates, where you have to wait 10 or 20 or 30 seconds for the error squigglies to update. Every edit becomes: type a few characters, wait for 30 seconds to see if Intellisense likes its, type a few characters.... And WHATEVER you do, don't unbalance parens or curlies, which will pin all available CPUS for minutes at a time! (Huge recent productivity improvement -- set the number of Intellisense threads to number of CPUs minus 1!). In the old days, on much less capable hardware, a compile would fail in 3 or 4 seconds; so you could just "type a few characters; press F7, wait 4(!) seconds, and see if the squiggly went away. Although typically, you would fix a few things, wait 4(!) seconds and see if the squigglies went away. (More-or-less instantaneous checks were run in the editor to check for paren/brace balancing). Instead, VSCode accumulates rats nests of red squigglies that wont go away until background intellisense completes (which could be 90 seconds or more), or until a compile completes, which runs the constant risk of facing a list of "12,000+"(!) errors in the error window, because you have an unbalanced paren or brace, which can take 10 or 15 minutes to straighten out. And the three or four G++ errors that are legitimate get buried in thousands of Intellisense errors that wont go away (that's a recent regression; you used to be able to temporarily filter out Intellisense errors). I'm increasingly thinking that Intellisense for C++ is dramatically tanking my productivity as well! I mean it does actually work on toolable languages, like C#+Visual Studio, or Java+Android Studio, where the tooling update time is sub-10-seconds. But for C++ it seems to be a disaster. (Wondering whether it actually does work, though). Build turnaround: there is NO obvious point in the Visual Studio UI to indicate that a build has completed. A tiny status message buried in the status bar. For some reason, my build output window always seems to come unglued from auto-scroll. And VSCode auto-tabs away from the Errors Window to the Build Window without un-de-autoscrolling. So you hit the F7 key, your eyes glaze over while a toxicly overlong build runs for a minute past the point where the error occurred, and you snap to 3 minutes later realizing that the build finished with errors, ages ago. Mouse-keyboard context changes. Switching your left hand from mouse to keyboard and back is an expensive operation relatively speaking. By my best estimate, I spend about 40% of my editing time switching between mouse and cursor keys. Whereas... on Visual Studio, major editing operations can be performed entirely from the keyboard. (ctrl+space, cursor cursor, carriage-return is burned into my muscle memory for some reason, even though it's been years since I used Visual Studio -- or is that Android Studio?). There's something seriously wrong there too in the arrangement of short-cut keys, mouse and cursor movements. Ctrl+Left/Right Arrow! There's a simple thing that is bizarely broken, that has a dramatic effect on my productivity. It does something seriously wrong, I'm not sure what, but it's not productive! It consistently takes you to the wrong edge of identifiers and operators, so you end up pounding on unmodified left or right arrow to get to the right place. I'm DEAD certain Visual Studio does it differently; and it's not a problem I've noticed at all in Android Studio. I'm convinced that a little time spent on time and motion studies could increase the productivity of average developers by dramatically large amounts. Something in the order of 2 or 3- or 4-times more productive. Most especially for Visual Studio Code, which -- for reasons I still don't completely understand -- seems to be extra-double-plus toxic for productivity.
peterth3 3y ago
The Design of Everyday Things, by Don Norman is a good place to start. https://www.amazon.com/Design-Everyday-Things-Revised-Expanded/dp/0465050654 https://www.amazon.com/Design-Everyday-Things-Revised-Expand...

incongruity 3y ago

As someone who works as a service designer and design strategist, I agree, 100%. I’ve seen a general decline in rigor in the field. Many are back to making things “pretty” with poorly done research (if that) asking small-minded questions rather than thinking about context, ecosystem and systemic effects of their design decisions.

ProxCoques 3y ago
I recently took part in a panel discussion about design strategy. I kept on being dragged into discussions about project management and process. In the end, I just gave up trying to explain and they all triumphantly celebrated a "good design strategy" as being how you intend to build the thing. The question of why, or on what basis, just seemed irrelevant.
- incongruity 3y ago
  So, that kills a small part of me to hear - but also, I think it reflects this larger pattern of the UI/UX world’s seeming need to not just reinvent the wheel but large chunks of the history of the discipline of design rather than building off of thinking about systems and systems of systems by people like Jay Doblin and others.

abandonliberty 3y ago

>the near extinction of any professional discussion or capable analysis of design by the people who are doing it. People don't think through the designs then launch a poorly designed test that can't produce meaningful results. Copy the competition, latest designs, or hope the customer can do it. It's easier to do and defend. Put in the minimal amount of mental labor required to get paid. Not assigning blame here. These folks all work in an oversubscribed field subject to the whims and opinions of execs focused more on delivering visual appeal or feelings than usability. It's marketing. It doesn't really matter how usable your product is if people don't want to use it. Many industries make very usable things. Notably the military. They're just ugly.

joenot443 3y ago

> Most designers I work with don't have the vocabulary or knowledge about what makes something "usable" in the wider sense, let alone the ability to actually solve subtle interaction design or information display problems. That's wild. We _had_ to read Design of Everyday Things as part of an HCI course in my Software Engineering curriculum. You couldn't get your degree without having some working knowledge of affordances and signifiers. I was under the impression, at the time, that we were dipping our toes into a world which UI/UX designers were intimately familiar with. Perhaps not.