I'd like to add one: using consistent metaphors. A user of software is constantly trying to form a mental model of how this ethereal, formless thing behaves. A state machine. What can and cannot happen, what will and will not happen after a given action, what can and cannot happen once we're in a different state. The shakier and less scrutable and/or reliable this mental model, the more anxiety is felt.
As programmers we're partly insulated from this effect. We may not know the exact inner-workings of a piece of software we didn't write, but we know some general things about software and the way it does and doesn't behave that soften the huge void of scary unknowns. This helps us form our mental model.
Physical metaphors of objects, continuity, permanence, locality, persistence, independence, are often used in GUIs for this reason. If I click a tab and then click back to the previous one, I expect to return to the same state I was in. If I change the text in one field, I expect that unrelated fields won't be impacted by that. Etc. This is a good starting point. Desktop platforms and then mobile platforms have built additional semi-consistent UX expectations on top of those largely physical intuitions. This helps too. But your application needs to go beyond that: it needs to present a simplified model of its internal state-machine to the user, and then it needs to hold to that. That mental model, once formed by the user, needs to have predictive power about the way the system behaves under different circumstances.
This is such a huge fucking deal. I could not hope to overstate the importance of UI flow & proper state management.
It took us 7 years of mistakes & learning to figure out how to do this correctly. We had to learn to listen to the customer and not give in to our inner lazy developer.
We now have total confidence in our ability to back-navigate through complex workflows, or arbitrarily switch between instances of them. Without breaking things. It is so intuitive to our users to be able to think "oh wait no i need to go back and change XYZ" or "I need to put this on hold so I can help this customer real quick". In our target market, the work is very complex and error-prone, so you are usually editing your previous inputs and double checking the new output. Every screen in our application has a back button & next button in exactly the same spots on the screen. I watch some of our users go back by muscle memory 3-4 screens within a second or 2. Mapping the users' brains to your UI is crucial. Really helps if you don't play RNG with the coordinates.
It's really easy to paper over these things, especially if you are doubling down on a sub-par solution. Getting your users to want to use your app is really important in most situations. Even in a B2B setting, we hear our customers complain about bad UX in some of their other solutions and how this causes trouble for training & adoption. Even if you are getting paid for it, you still don't want to use trashy software. I have used software that you literally could not pay me to suffer with on a daily basis.
How else will designers justify their jobs?
I wonder if designer should be reworked to be a seasonal or consultancy job only, to only hire them when you're making a new product/big feature or there's a drastic need to change things but never otherwise. Having them as permanent staff leads to our present usability and accessability nightmare of everything constantly being redesigned and completely changed around for no good reason other than padding designers' resumes.
For anyone interested in up-leveling their own understanding of design I recommend the articles, videos, courses and other materials available from the Nielsen Norman Group
> I have observed that designers are less interested in educating the world about their practices than perhaps they need to be in order to change this situation.
She has found her job has become mostly informing and teaching others how to go about these practices, and if she has spare time does the work herself. But it was such an ordeal when they hired her because they didn't even know what she was supposed to do. She has acted very much like a consultant in this regard, but also does the work involved.
Human-centered design professionals who went to school for/taught themselves from the field of Human Computer Interaction, which involves a multitude of qualitative and quantitative research methodologies for assessing usability and bringing the voice of the user early into the development lifecycle on the otherhand... now that is sorely lacking and is historically underinvested in. Their job makes your job as a developer easier, not having to redo work and waste time if they are plugged into your dev team and focusing on your users.
Ask yourself, as a developer, do you feel you have the specialist skillset and expertise to truly validate designs with real people (users)? Is this something you would want to do, if only those pesky UX "design" professionals didn't take them over to justify their jobs?
Let's put you in front of 10 different users of your product for an hour each, give you a facilitator guide, and have you guide them through a task-based usability review of your product. Make sure you aren't asking leading questions or biasing their responses, then synthesize the essence of all the interviews into insights to improve the product design. Finally create a read out report that you have to present to senior leadership for another hour on what you learned and how to improve the product design. Oh yeah, you now have 0 hours to code in your fulltime 9-5 job. Good luck!
Note: I acknowledge a UX researcher is a full-time specialist role, however any UX designer worth a damn should be T-shaped and able to use qualitative research methods to interview users and evaluate their designs.. otherwise they are a UI designer and guessing at best.
This is how you get death by a thousand A/B tests a la Google, Facebook, and other ultimately user-hostile interfaces that optimize for ad engagement.
Give me a compassionate, thoughtful, designer who isn't an ass hole any day of the week.
The field of HCI (and Human Factors before it) pioneered the application of qualitative research methods from adjacent fields e.g. anthropology, cognitive/social sciences, etc. towards computers and information technology. Optimizing for 'ad engagement' seems to be a recent phenomenon in the timeline of HCI and arguably is being written by the likes of Google, Facebook, Amazon, etc. and the people on their payroll who sold their soul to make this their life's work.
If anything, the problem in this scenario is that culturally we need everyone to be contributing all of the time, even for positions that may experience occasional downtime. Let's not assign blame to a particular group when they're simply responding to the pressures put on them.
"Hey, we're paying a guy to dig holes and fill them back up with no value whatsoever, why are we doing that?"
"Hey, man, stop attacking hole-diggers, they're just trying to make a living."
The justification isn't "It helps users" or anything like that. It's "This is not a new idea either — pretty much everyone else is doing it, e.g. macOS, Windows, iOS, Android, elementary OS, KDE.". Reducing usability and breaking habits to follow trends is a bad thing.
"Following trends" is a good thing because users appreciate when a piece of software looks like software they're already familiar with. It is maybe slightly annoying to people who already are used to the software, but every new user benefits from it.
Yes, because there are no buttons anymore, just icons. Icons are not button. Icons are icons, buttons are buttons
> which lets you draw attention to buttons the user might not already know about using the same technique while staying within a certain 'visual noise budget'.
That "visual noice" is the zone where you can click on a button. I also don't believe that "visual noise budget" thing at all. Maybe it helps a bit first time users, but most software shouldn't optimize for first time users. I'll add that not everyone has a perfect eyesight or perfect mouse control. That new style is bound to be frustrating for a few people.
> Users expect that icons on the header bar are buttons (what else would they be?), so there's no need to call attention to that fact with an extra visual indicator.
Actually, having fallbacks and multiple ways to signal something is a great thing. For example, if you only use color to indicate something, colorblind users may have a hard time using it. Icons and tooltips when you hover over it is also a good way to achieve that.
> "Following trends" is a good thing because users appreciate when a piece of software looks like software they're already familiar with. It is maybe slightly annoying to people who already are used to the software, but every new user benefits from it.
So they're focusing on new users instead of people that actually use their software. I don't see how that is a good thing. If this was just one change, I may agree with you, but this is a sign of a larger trend of constantly changing interfaces for absolutely no benefit to the user.
This sort of wrong (or more precisely easily falsifiable) statement perfectly exemplifies why I have so little respect for "design" as it currently exists.
You shouldn't just be able to say things like this that are nearly provably wrong on their face (e.g. I certain I can find 5, or 20, or more people who will definitely get slowed down by this)
Add on top of this the sheer stupidity of not being able to keep the old way if you like, an increasingly common thing.
In my opinion, "design" does two things at the same time that are presently fundamentally incompatible without being honest about it -- namely "usability" and "fashion."
It's absolutely possible to do both, but you can't pretend you're doing one when you're doing the other. Architecture comes to mind. They do this right, most often by putting usability "first." You can make your design as pretty as you want, but if the damn wheelchair ramp doesn't work as intended, the whole design is broken and if that means your pretty thing must die because of it, then kill it and start over.
The same applies for software engineering.
So in that sense, design can and should be fluid. Where I work, designers often meet with customers (some external, some not) and continually get feedback, which the developers act on. IMO stopping design as soon as development starts increases the chance of having a poor design, forever.
Sometimes it's not known that a design has flaws until things start coming together during a project and some workflows become more prominent (and painful) than others.
Fighting for 20 years to educate programmers and investors on the importance of Human Centered Design and Function over Form approach, is hard. And I and everybody in the Design Industry have failed miserably.
Now when every startup has a boilerplate, templates and libraries in hand and "that's enough".
Designers (or I may say - Decorators) are "thousands a dime", they are racing themselves to the bottom of the pit. But I am cool with it. After all SaaS design software is here to collect and label enough data for big Neural Model to emerge and remove design from the picture.
So your dream will come true, and you will be next in line of removal from production pipeline.
Having programmers as permanent staff when you need the same CRUD paradigm is unnecessary, and you can hire as a consultants when you're making a new product/feature but never otherwise.
I don't think you want to be benching that knowledge very often.
Having extended research phases or personal development would be great to cycle in between major releases.
In the interim they might develop better tooling or A/B a subset of features, or strategize with the analytics dept.
We really all should have a designer mindset, but truly professional designers are product gurus.
I think a lot of this depends on the target audience. If it is a wide-distribution consumer application, then I like the "swimming duck" analogy, where it looks smooth and calm, above water, but is paddling like hell, underneath. That's what I strive for, myself, in my standard consumer-level apps. Many of my apps look quite "boring," but actually have a lot of moving parts, invisible to the user. Selecting a screen may result in multiple server transactions, and the user only sees a throbber for a half second. No progress report.
The other side, is that, if you are marketing to engineers, or specific types of professionals (not all "pros," though. That's a wide net), you may want to present a very complex and "raw" UI. I have done this for admin dashboards.
I am most familiar with Windows, so I will speak from that perspective.
Because software was an application, and the path of least resistance was to use the OS provided controls and menus, there was a sense of uniformity in how you accessed features. Keyboard shortcuts just worked and were pretty much the save (Ctrl-S, saved the document, etc).
OLE provided a uniform way to embed documents into other applications. Cut and paste worked consistently.
There were also a limited amount of frameworks (bare Win32, MFC, OWL, Visual Basic, and Delphi probably covered 95%+ of apps).
It seemed that most user interfaces at the time were actually made by programmers and not graphic designers. In addition, for the most part there was a lot of continuity from version to version in how a program looked.
Now it seems that every web app wants to look different for the sake of looking different. People want to change how an app looks on a regular basis, often for no other reason than that it needs to look "fresh.". There are a myriad of every changing front-end JS frameworks.
It seems that UI is driven by graphic designers looking to make something unique and standout and not programmers that just want to make a standard, low friction way the user can access the functionality and be done with it.
Also, all you data is siloed a lot more because it is stored in the "cloud". Whereas before you could easily have access to the raw output from all your programs (and if they supported OLE embed documents from one program in a completely different one), now it is somewhat of a pain if you want to get raw access to your data.
Web based apps do have a lot of advantages, but I feel we have given up a lot when we went from native desktops apps to web based.
Yes, things are not perfect but claiming that designers are making everything difficult while programmers would have just made everything better albeit not as pretty looking is really not a fair assessment. I mean, preference and general nostalgia, I get it, but it's a bit much.
Getting raw access to your data also wasn't a breeze in the past with program often having their own binary formats and not exposing any programmatic interface at all to get data in or out. Not sure how this relates to the cloud.
I agree with most of the opinions in this article, but I don't like the idea that all software should convey calm, or the conflation between a simplified intuitive interface and calm. Video games are a great example of simplified, intuitive interfaces which are often the polar opposite of calm.
Elements like calm and intuitive are also extremely subjective. I find emacs calm, intuitive and extremely accessible. People with different context will have a comically different response. Humans need interfaces that cater to their different experiences.
Video games are interesting in terms of usability. I thought a lot about this the past couple years after a UX course. A lot of UX principles are about making things easier, like large clickable areas, not moving clickable areas, contrasting colors, proving plenty of time to react or undo, and making things obvious and as easy as possible. But in a game, many of those principles are flipped. In a shooter, the enemies are smaller and move. They may be difficult to see. Solutions are not always obvious, especially if they are extras or hidden power ups.
But at the same time, a lot of the UX principles are very important. An enemy about to attack should telegraph that attack so you have time to react. Menus should be very clear and obvious. Inventory management should not be a chore, the map and HUD should be easy to use.
I've also heard about of platformers giving a couple pixels after walking off a platform to jump, like Celeste. It is very small thing to give better feel to the controls and make up lack of precise timing.
[EDIT] incidentally, here (many) games have an advantage over other software, because they play linearly rather than presenting a large space of possible actions all at once. Games that are more similar to productivity software (city builders, say, or grand strategy games) have trouble doing this without it being obvious that you're in a tutorial.
The goal of usability is to be able to accomplish your goal. In a lot of games, the feeling of getting better or overcoming an obstacle is part of the goal. So the UX is not surprising, it's following the goal of the product.
A game UI might be wacky and as twitchy as a rodent dosed with recreational stimulants, but the user feels calm, capable of navigating through it and never doubting they can accomplish what they set out to do.
Calm Technology is "that which informs but doesn't demand our focus or attention."
for those unfamiliar with Weiser/"Calm Technology":
Fantastic nugget of wisdom here. Saying that you want a product to be "intuitive" or "simple" is as useful as saying that you want it to be "good, not bad."
These are all things that affect whether a product could be perceived as good vs. bad.
Importantly, intuitiveness is not relevant for some products, or not what makes it good or bad. The tradeoffs between other aspects of your product could be such that trying to achieve intuitiveness would actively reduce value.
Identifying intuitiveness as something you can optimize for or not is not pointless. I'd also argue that intuitiveness can be measured and strategies for more intuitive designs/patterns can be formed.
Yes, and it is actually useful to say "I need this product to be inexpensive", rather than "I want this product to be good."
That's what the author is getting at. Just saying "I want the product to be intuitive and simple" is worthless. You have to actually define what that means and what properties the product has to be considered "intuitive". But too often, "I want it to be intuitive" is about as far as they get.
If you're trying to make a useful tool these principles apply, but if you're trying to farm users for ad money they don't.
People will say they want the former, but in practice they often choose the latter (and then grumble about it not being more like the former).
There are secondary effects like the ad-ridden product may have more money for development and deliver better features. But at this point we're all wondering if there isn't a better funding model that can deliver both good experience and sufficient development funds.
There's also the Calmtech movement, somewhat related to the post: https://calmtech.com/
And this applies to desktop, web, mobile and commandline applications as well.
A tool needs a strong focus of it's maintainers and the courage to say 'No!' to things which are out of scope or not user friendly. This seems to be quite rare.
So the way you structure and write your code has very much to do with wanting to reduce the mental taxation of the reader (you included).
In the UI, UX and HCI world the concept has obviously a lot to say as well.
HTTP is a relatively easy thing, let's replace it by an overengineered clusterfuck called HTTPS. Good luck implementing THAT on your homebrew OS. (don't get me wrong, it's good thing that it exists, I just don't see why all the sites have to use it)
Well, git+github seems to work nicely, lets disable logins using your password! Took me about an hour to take care of this (there is a nice guide for it, but that doesn't mention what your 'github email' is -- there is no such thing, and it doesn't mention that you have to change your remote to an ssh connection, and it also teaches you to copy-paste commands from the browser to your terminal).
Because regular users don't know how to distinguish between the level of trust they need for visiting "Justin's travel blog" vs. their online banking website. If we don't display red error messages if a site they visit has an invalid certificate, they don't know how to tell it's not safe to enter their credentials there.
The web was once mainly used by academics, programmers and other geeks, now it's used by marketers, scammers, hackers, and a bunch of other malicious actors. I wish we could go back but that ship has sailed.
In festina lente
Software should meet its design goals.
A ground proximity warning software system should absolutely not “convey a sense of calm”. An online PvP battle arena game should not convey “a sense of calm”. I’m not sure a sense of calm is necessarily appropriate for a chat app, an ad blocker, or a to do list.
Do you even want a sense of calm from your compiler?
> calmc main.calm
Compiling… please relax…
Okay, now, are you sitting down?
Okay, I have some bad news about line 27, but I don’t want you to panic
OK, so interpret the title as "the design goals should include conveying a sense of calm".
> A ground proximity warning software system should absolutely not “convey a sense of calm”.
In the sense of "convey a sense of calm" described in the article, it absolutely should. The user shouldn't be freaking out because of the software, thinking "oh shit did I click the right thing?" or being confused about what is being indicated. If they're going to freak out, it should be because of the aircraft's situation, not because of the software. Moreover, in an emergency situation it is important to stay calm; the software should not make that harder to do; it should convey urgency, but not a sense of panic.
> I’m not sure a sense of calm is necessarily appropriate for a chat app, an ad blocker, or a to do list.
Again, you seem to be ascribing a different meaning to what the author describes. In the first paragraph, they describe calm as "I, as a user, should know what I can do with it and what I can’t do. I always know what’s happening, where I am and what is next. Everything comes easily to me. I don’t get stuck, never feel lost or stressed out." Regardless of what's said in the chat app, the app itself shouldn't convey non-calm; you wouldn't say that the user should be confused about what the app is doing, or that the chat app should be hard to use, or that they should feel lost navigating the app. Conveying a sense of calm absolutely is appropriate for each of those apps.
"I, as a user, should know what I can do with it and what I can’t do. I always know what’s happening, where I am and what is next. Everything comes easily to me. I don’t get stuck, never feel lost or stressed out."
This is clearly not a reasonable design goal for a puzzle game. It’s not a good goal for a call center queue management system. It’s not even a reasonable design goal for a search engine!
Oh, but you’ll say the author only means within the bounds of the tool’s interface the user should understand what options they have, not be burdened with additional stress of trying to figure out how to interact with it, etc.
Which is just.. yes, obviously, you shouldn’t build software to just screw with people (oh, but… puzzle game?). But overall, taking responsibility for a user’s stress/calm and placing the burden on all software to try to “exude calm” into any situation is… it’s an opinion, but it’s not a particularly interesting one?