Machine Interaction - Instruction vs Intention

Intention is often better than instruction

We interact with machines in either of two ways:

  1. By giving instructions
  2. Or by giving (our) intention

For example, we interact with elevators by specifying our intention. If we are to go down, we press the down button (our intention) to call the elevator, regardless of where the elevator is, and then, when the elevator shows up, we indicate the floor we want to go to (again, our intention). We don't tell the elevator to go up 2 floors, then down 5 floors. That would be really messy if we had 10 people in the elevator.

In other cases, we give instructions. For example: cars. We don't tell the car to take us from point A to point B in 15 minutes -perhaps one day we will be able to. We have to press the pedal, shift gears, maneuver the wheel, etc.

These cases are clear. Switching how we interact with these machines will likely have a very undesirable effect and could even be fatal in some cases. 

But there are cases where things aren't as clear as the above example.

The line blurs when interacting with computers and software applications - web apps, mobile apps, and desktop apps alike. As users, should we specify our intentions or give instructions? It becomes hard for users with multiple teams and vendors creating apps, even on the same platform. No two apps behave the same.

As an app developer or product designer (even for non-software products), being aware of these modes of human-machine interaction and choosing the right one is a key part of user experience design and, by extension, the product's success.

Specifying intention is easier for the user. Taking instructions is easier for the developer. Which one would you choose if you were a developer?

In the early days, computing platforms were used by those who created them. Giving instructions was not a problem for them -it's natural, in fact. These days, computers have become consumer devices, household names, and something most of us carry in our pockets.

Giving instructions is not natural to an end user- specifying intention is. Therefore, designing products that can take user intention into account rather than instructions is that much more important. 

Let us consider building a store app for a shoe store.
You can have a "browse & filter" functionality, which is the typical design. User browses the available products, narrows them down to a few by selecting various attributes of the shoes, such as size, color, material, brand, and so on. Sure, this gets the job done.

Now consider an alternate design.
User is presented with questions and given a few options to choose from. Say,
What would you like to shop for today?
→ Girls’ shoes
→ Boys’ shoes
→ Women's shoes
→ Men's shoes

Here, we ask the user about their intention.

Say the user picks “Girls’ shoes”, then is presented with:
How old is she?
-- not "what is the age" or worse "please specify the age of the girl"

The user picks, or types in the age, and then a list of shoes matching the selection is shown, pre-sorted and/or pre-grouped by intelligent defaults, with the ability for the user to easily change the sorting or grouping.

Think about the second approach for a moment. If you were in the user's shoes (pun intended), which approach would delight you?

Both cases do the job, and in both cases, we work with and show the same inventory. The second approach seems more intuitive and quicker, won't you agree? 

It is best for the developer as well. 

When the user makes one selection, "Girls' shoes," you already know 2 things: kids' shoes and the gender is female. That saved you at least 2 round-trip calls to the server and the processing and bandwidth associated with them. In a mobile app environment, even if the payload is a stripped-down JSON, one server round-trip is still better than two. In cases where users are on cellular data and are on a limited data plan, you are saving them money as well. Sure, you can't promote the optimized server round-trip time as a benefit of your app to consumers, but you should still consider it and design it accordingly. 

Every user interaction that does not frustrate the user, and every interaction, however small, that delights the user and makes them quip - ”ha! that was neat”- is an unspoken USP for your product.

It is a win-win design.

Next time you are designing a product, keep this in mind.

backAll posts