shuttle1987
commented
5 years ago I did a bit of an update on the old post I had:
What is "User friendly"?
######################################
:date: 2014-05-17 19:00
:tags: ui/ux
:category: Misc
:slug: what_is_user_friendly
:author: Janis Lesinskis
:summary: User-friendliness is deeply context dependent. Here are some factors regarding how that works.
:status: draft
Many years ago, I was talking to someone and they were saying that programs
such as Vim were not "user-friendly". Interestingly enough, I shared that opinion
about Vim a long time ago but recently I have a different opinion. Vim happens to not have changed much in the intervening time, so what happened to change my perspective? [#]_
** User-friendly depends on the skill set of the user**
I think a lot of people confuse the learning curve with "user-friendly". [#]_
Some things take a lot of time to learn efficiently but are a lot easier when you get used to them.
There are a couple of important aspects to making decisions about matters of
"user-friendliness". Questions such as, "Should we invest the time to learn how to use XYZ better?"
are intimately connected with the concepts around "user-friendliness".
The notion of "user-friendliness" is task-dependent and trying to extrapolate this into some sort of general notion is a mistake. I want to focus on factors that are relevant to professional teams trying to determine which
tooling they wish to use.
Frequency of task
------------------
How often you perform a task has a huge impact on your relationship with that task.
There's a great article about `frequent vs infrequent developers`_
that talks about how the *frequency* with which you interact with a system changes the most
effective strategy for how to interact with that system.
.. _frequent vs infrequent developers: https://utcc.utoronto.ca/~cks/space/blog/programming/FrequentVsInfrequentDevs
That article also references an informative XKCD comic that features a table explaining how much time you can spend on process improvement for various tasks of various durations (assuming a five-year window for efficiency gains) before you spend more time on the process improvement than the time you'd be saving:
.. image:: https://imgs.xkcd.com/comics/is_it_worth_the_time.png
With the Vim example, basically, my skill set and requirements changed. I'd learned a lot about the other tools and once I was past the learning stage the extra power from those tools was making my life much easier. Suddenly the simplicity of the other software was getting in my way.
Another critical factor is that the time I had to spend using the tool also changed, because I was
working on some different projects.
Different users have different preferences regarding what they consider to be user-friendly.
How often someone uses something will have a big impact on what makes that user-friendly/unfriendly for them.
Difficulty of task
-------------------
With the Vim example, I started to need to do things that weren't supported with a more basic package.
When you start to run into tasks that you can't accomplish at all with a system, it's hard for that
to not have an impact on your assessment of the "user-friendliness" of that system.
A good example of this is writing up a printable document and the use of WYSIWYG_
word processors vs more professional typesetting tools.
.. _WYSIWYG: http://en.wikipedia.org/wiki/WYSIWYG
Say you need to quickly write a one-page letter to send to someone. You would probably
just write it in something like `LibreOffice`_ writer and then print it out.
The software takes care of most of the formatting and - generally speaking - makes the
page formatting look something similar to what you want for a relatively small time
investment.
.. _libre office: http://www.libreoffice.org/
Now, what if you need to write a professional quality typesetting book that has a ton of code, formulae
and figures? [book]_ Doing that in a WYSIWYG_ office suite program would be brutal.
Getting the formatting for the formulae would be a massive pain in the ass. Once you start getting beyond some number of pages, most of the WYSIWYG word processors start having problems with page breaks and page layout - problems that aren't that big of a deal in small documents but start becoming an issue in larger documents.
For something like a technical book, using `LaTeX`_ or similar would be a clearly better choice.
In this case, I would say that the more "user-friendly" software is `LaTeX`_ despite it
having the clearly steeper learning curve.
.. _LaTeX: http://www.latex-project.org/
Somewhere between these extremes is the breakeven point between those two approaches. [#]_
Where this point lies is going to be very much specific to who is embarking on the
project and what their skill set is.
It's important to note that difficulty is distinct from time in a very important and fundamental way.
At some point, if the tasks get too difficult it's no longer a matter of just trading off time due to low efficiency.
You'll hit a point where if the difficulty keeps growing, you start to not be able to complete the tasks at all.
A team that understands their domain well can spot these situations in which the tooling starts to make
the tasks impossible. If you run into this situation, it is worthwhile to step back and reconsider tooling.
The most dangerous zone, however, is when the difficulty is high enough to allow the task to be completed but not high enough to be a complete show-stopper.
Weighing the factors
------------------------
Any decision about what direction to go with tooling will require weighing up a few factors carefully.
An important thing is that some programs are definitively more user-friendly than others in a way that
doesn't depend on user skill level *or* frequency of use.
Say you have tool `A` and tool `B` that do the same task but `B` is just a defective version
of `A`. It makes sense for all users of all skill levels to use tool `A`. (This is just an example of the `Pareto Efficiency` concept.)
A good example is the choice of text editor when you are developing code. A lot of beginners will just use something like Notepad at first because it is simple, installed everywhere and has minimal complexity.
This will allow you on the most basic level to write some code that your compiler/interpreter/whatever
can use. However it has specific deficiencies that make it unsuitable for editing code. For example, it will not handle large files properly and has a variety of other issues with character encodings that can outright prevent you from doing your work.
.. _Pareto Efficiency: https://en.wikipedia.org/wiki/Pareto_efficiency
But these deficiencies aside, you get a better experience with something like `gedit`_ or
`Notepad++`_ just due to `syntax highlighting`_ .
Syntax highlighting is a big productivity booster because it reduces cognitive load when writing code.
For people who write code, these factors drive user-friendliness when the user is a coder.
.. _gedit: http://en.wikipedia.org/wiki/Gedit
.. _notepad++: http://notepad-plus-plus.org/
.. _syntax highlighting: http://en.wikipedia.org/wiki/Syntax_highlighting
From here, though, it's more of an issue of personal preference. Editors such as Vim and Emacs
are extremely powerful but have a much steeper learning curve.
Implications for teams
-----------------------
Good teams strongly tend to have good tools or create good tools if they don't have them.
Having bad tools will impact the morale of a team hugely, and matters of user-friendliness
will impact peoples satisfaction.
Some software is clearly aimed at professionals, yet UI/UX decisions are made based on dealing with new users.
With software that's meant to be used by professionals on a daily basis, the UI/UX decisions should be made assuming that the user has competence with the system.
If you are creating a user interface, try to keep the notions of familiarity and competence
with the system as distinct considerations.
A common mistake I see is trying to make the software as easy as possible for complete
beginners (as in people with no familiarity with the system) to use with no consideration
paid to more frequent users. If you spend all your efforts focusing on occasional users
with a product that's really only useful to regular users, it makes the overall experience
much worse for the people that need to use the software all the time.
If you are in a position to procure software or any other system, take into account who will
be working with it and how often. Missing either of these considerations is usually a costly mistake.
Likewise, if you are making software or any other system, take into account the patterns
of usage that the users will use.
.. [#] It's also worth noting that on at least this factor I personally haven't changed much either.
I still don't use Vim as my go-to for text editing, although I can use Vim at a somewhat proficient level.
Even at the timeI thought Vim wasn't "user-friendly", I saw the benefit of using a good editor, things like syntax highlighting and code-aware tooling were of clear benefit. I just didn't happen to understand the Vim ecosystem and the factors of why it was so useful. I also wasn't developing much in a terminal window setting, something that Vim happens to be *very* good for.
.. [#] A classic example of something that's annoying to learn but is amazingly valuable is touch typing. Perceptions of how difficult something is to learn will have a large impact on how people judge the difficulty of doing something, even if in reality it's not that hard to learn.
.. [#] This is like the http://en.wikipedia.org/wiki/Intermediate_value_theorem with one end point being using the simple WYSIWYG and the other end point being the professional typesetting software. At some point the difficulty of a task must be equal using either software if we assume that the difficulty of using a particular piece of software is continuous with the size of the task.
.. [book] I did write a book like this, and this was the source of many of the posts I wrote about
LaTeX.
aesmithwriting
Beginner vs professional friendliness.
Link to article about frequent vs infrequent developers.
I think I started drafting something over on the drupal site, hopefully I can extract that.