Unless you are impossibly lucky, all software at some point will be consumed by humans, for sure during its development, but also for the years after it was delivered, as it will be maintained and may continue to be used by humans.
Kathy Sierra Minutes 13:28-20:19
If you have the time watch the entire thing. This is one of the best talks around design and humans from someone who was a core influencer of the Java ecosystem at its inception.
An article about ground breaking research into how Self-Control can be depleted and used up.
What consequences does this have for the programs we are creating, and what does it do to us as developers?
What does this insight do for our users? An article about ground breaking research into how Self-Control can be depleted and used up.
The more you make your users think and be patient the worse they will be at what you are asking them do. Cognitive friction is the bane of you and your users existence, and removing that from each of your workflows will pay huge dividends.
What feedback do you give to your users? Do you give them an error message, where they are expected to think like you, with your years of experience with the various interfaces (APIs as Code, APIs as Services, GUIs), or do you give them a message about what specifically went wrong, along with a clear resolution to help resolve the issue? Feedback does not always need to be on the negative side, what are you doing to confirm that the user is going along the correct path? Do you give the user feedback that they are in step 4, and they should expect 5 steps in total? How are you using Behavioral Economics and Captology to motivate them to continue with the experience?
Is anything that does not compute in the wetware ie the brain. Are you using unique iconify that is not standard either in your application or industry can increase user friction? Making a user wait without any status that indeed something is happening in the background can make people wonder what they should do, if anything? Warning users not to click the back button, and failing to handle the incremental nature of networking can drive end users crazy. This can lead to duplicate orders or entries that have to be resolved with expensive human backend processes. From the aforementioned Feedback challenges above, to any number of things that make a user question what they should do next, all of these are a form of Cognitive Friction that will slow down your users and impact their enjoyment of your product or service negatively.
Toil is all the things that could be removed from the user’s experience that can either be designed away or removed from the basic workflow, flows that are not core to the experience, or via some clever optimization, and do not need to be delivered at all. Many examples exist for toil, including cutting and pasting magic strings from one part of an experience to another, not exposing core capabilities and delivered features for unknown reasons, and then expecting users to magically discover them, or expecting a user to create their positive journey around using your product or service without clear curations and thus ensuring they will be successful. Toil can take so many forms, but you will know it when you see it on your user’s face.
This is a form of toil, but is even more insidious for your users. This takes the form of unexpected and demanding work that can not be planned for. This unplanned work can take many forms, but can include:
- The implied training required of your users to use your tool, training that only can be earned by the blood, sweat, and tears of your product or service.
- The expectation that a user will be a power user, even if they only use the tool once a week, month, quarter, or year. Humans are busy, and increasingly expect to be able to figure out an interface as they are dealing with it, as they easily use 100s of unique interfaces per day. How many computers per day does the average person interact with, easily 100s if your include automobiles and the appliances in their house and in their pocket all with their unique interface?
- Forced upgrades or updates that require relearning how to use the tool, and in the worst cases immediately invalidates the user-generated videos on YouTube that help others, and/or invalidates your own documentation either delivered as specific documentation or sources such as StackOverflow and user forums.
With these four categories, Feedback, Friction, Toil, and Invisible work, combined with the Kathy Sierra video above, the more patience and work you expect of them, the harder it will be for them to be the power users and advocates you desire. More importantly, asking too much of your users will violate the trust they have put into your product or service.
How do you assess where your software exists in the context of Feedback, Friction, Toil, and Invisible Work?
The UX Assessment, easy as A, B, C, D, E, and F.
Let me introduce you to:
The UX Assessment Easy as A, B, C, D, E and F. Before you Do Anything(Design, Develop, Deploy, Defend, and Determine your Software) You must deliver:
- Advantages - Does the offering do what it must do in the context of a competitive marketplace over and above anything existing?
- Basics - Does the offering do what it promises to do?
- Complete Curations - Does the offering deliver easy to use curated complete experiences for normal edge cases and typical, possible error states?
- Delights- Does the offering satisfy and excite humans that use it?
- Enlightenment - Does the offering make the user a better person and more engaged with what they do?
- Flow - Does the offering enable and empower the user to enter the flow state. The state whereby time and space are altered as they perform at the highest of levels.
Use the assessment to writeup something you are thinking of working on or have delivered?
This can be something you are doing, or a tool you are using from the marketplace. Pick a specific feature flow, hopefully, something you don’t work on every day, and use the below spreadsheet to score it. Feel free to “Make a copy” of this worksheet and make changes.