User Interfaces: When and Who should be designing them and why?

     I am striving to move over from blogs to subscription Substack newsletters. If you have interest in my meanderings please feel free to get a free subscription to the newsletter (go to the end of the newsletter). You will get a copy of each newsletter in your emailbox.

     Get the newsletter.

     As is true of all of us, I get new apps. I sign up for new services via websites. Some interfaces work well. Others make me want to tear out my hair (and I don’t have that much remaining). What is the difference?

     First, I may — eventually — want to fine-tune my interactions with the app/site. I may — eventually — want to go through every exciting and fantastic feature that is available. I do NOT want to have to go through five menus and three submenus to set my address.

     Consider it like a layered cake. On that bottom layer, we have all of the basics. Open a file, save a file, add basic profile information, add a financial source. All of this should be so easy that someone who has never used the interface can do it without having to dig into the interface. Perhaps the app/site can keep track (I know — cookies — love them/hate them) of what is your status. First time user? Experienced user? It may provide a very friendly question/answer interface to let you get started. There may also be video and/or text tutorials to get you past that first level — but NOT for that first level. If you don’t present an easy enough interface to a first-time user for them to get started, go back to GO, do NOT collect $200.

     So, what are those basics? If you wrote the app/website, you don’t really know. For you, everything is obvious and beautiful and why doesn’t everyone just immediately love it for what it is? Ask your grandfather to sit down with the app. Answer questions as they go — but record every question. Observe every “false” movement — why did they do that? Isn’t it obvious that they should have done this other thing — well, no, it apparently isn’t obvious. Obvious for you is not obvious for everyone.

     Back in older days (not quite back to the “once upon a time” days), programs (not even apps/applications at that point) would have a command line interface. (Of course, underlying operating systems usually still do — but most users will never see it.) The goal was to make it easier for more people. Visual user interfaces, and (little “w”) windows were created — but there were usually “escape modes” for experienced users to access the basic commands and their options. These are still often used during scripting for batch (large sets of users for which you want the same set of actions done) situations.

     My Master’s thesis (this WAS in “once upon a time” regions) was for a “Human-oriented User SHell interface (or “HUSH”). It was command line based but you could enter a “?” at any time and it would give help as to what was possible, and what options did, at any point in the command. (Never actually implemented due to bureaucratic reasons.) Did you have to use the help? No. It gave you help only when you wanted it. That made it better for experienced users and the help was good for first, or early, users.

     As is true for many situations, we have a spectrum of users — from first-time users to highly experienced. Each level has different needs and expectations. The basic premise holds, however. Very inexperienced users should NOT need help to do basic things. Experienced, highly advanced, users should not be slowed down in their use with anything that they might know already.

     The interface for highly experience users can be done by the developers. The interface for first-time users should NEVER be designed by the developers.

Simplicity: the benefits of lack of complexity

 

     I have been around computers a long time. Long enough to remember when 64K of memory (in total -- not RAM) was considered a large system. Long enough to have to toggle in a boot program for the paper tape reader to allow the main program to be run. Long enough that, between queuing up for the card punch, waiting for your program to be executed by the mainframe, and then getting the printouts from the run -- you might be only able to run your program three times in an eight hour period.

    (Not as long as the true pioneers like Ada Lovelace, Alan Turing, Kathleen Booth, Wang An, Grace Hopper and such. Please forgive me if I left out your own favorites.)

     Now, I'm not going to say those days were "better". I like getting streaming videos (though I will never be in favor of the many meetings that could have been done with a few memos and emails). I like reliable email networks, transmission, and reception. I like online shopping. I like having much of the transcribable data of the world available with searches and networked museums, libraries, and academies.

     But there were some advantages arising from the lack of options and complex systems.

• With very limited memory, it was necessary to write efficient code.
  
  
• With slow turnaround, it was necessary to try to anticipate every problem, and edge condition, that your program might encounter -- in advance as part of the design.
  
  
• It was relatively easy -- and usually necessary -- to understand the basics of the entire system from the power that entered the hardware to the hardware components to the initial boot program, the peripherals, and the way the operating system works.

     I am a generalist because I WANT to continue to be a generalist. There are rarely paid positions posted for generalists. So, it was necessary to focus on some area. I became a telecom/datacom specialist. As I continued my career, I found that people interactions became more and more interesting and so I started to try to become the best servant leader that I could be -- a goal that I will never reach but which will continue to be out there as a target.

     But, at heart, I am still a generalist -- now extended to include the people (people's actions and interactions, UI, UX, etc.) Being such is conceptually very useful -- but job listings are virtually non-existent. Creation of new types of products usually requires knowledge of multiple areas (and, often, sciences) brought together. Generalists can be of great use in such.

     Nevertheless, the economy continues to move towards complexity and specialization.

     Within a computer app that faces a human user, a goal is to present a simple, intuitive, interface. Complexity of possibilities makes that much harder and, in part because of legal issues, every version of a particular program (word processing, spreadsheets, voice apps, video apps, ...) has to have a different interface (sometimes just a bit of a diversion, sometimes completely different).

     The goal is still to make it simple for the user to use without sacrificing flexibility and functionality. When that is achieved, it is almost definitely a balancing act with extreme complexity "under the hood". One could say the complexity is of the system as a whole. When the user-side becomes simpler, the provider-side becomes more complex. This often applies to mechanical objects, and other systems, as well.

     But what about those advantages of a simple program? They move from necessities to desirabilities. I would say that it is STILL useful to write efficient code. It is DEFINITELY (especially in terms of security in our current world) useful to anticipate problems, edge conditions, and vulnerabilities as part of the design. And, in order to create new types of programs, I am of the opinion that knowledge of the complete system is of considerable usefulness.

     Most examples have been concerning computer systems since that is my field. But such can be applied to civil engineering, mechanical engineering, business structuring, and so forth. There will be advantages with simple systems and complexity will involve trade-offs between various components.