It is up to us to build highly intuitive applications

August 25, 2020

Subscribe and stay up to date

No spam, we promise! You will only 
receive essential emails.
layer 8 issue
Ezequiel Salas
Written By
Ezequiel Salas
Topic
Engineering

No buddy, it's not a layer 8 issue

 

I learned a lot as a software developer in 2010. At the time, I was working at Ikea implementing large projects, and there I had the opportunity to use frameworks and libraries that I had only read about.

 

Everything was new and surprising to me, but the most astonishing was the culture. The company, among many things, used an open office concept. Each department was made up of elegant, stylized tables for the sake of cross-communication between departments. My workplace was next to the IT department — strategically positioned to help us with user support, and sometimes even blame us for bugs when the root cause was some bug of ours.

 

One afternoon, when it was time to go home, after an urgent support call, I heard something that I did not expect: a fellow IT member said, "It was not a system error, it was a layer 8 issue." It was the first time that I had heard that joke, but curiously it was not funny to me. I went home thinking about how much responsibility we have for the errors that users make with our systems.

 

Wait a minute, I just said errors made by users… although "a layer 8 issue" is a common joke, it requires some explanation.

 

(Note: If you are a sysadmin ninja skip this part 😉 )

 

The Open Systems Interconnection model (OSI model) is a reference model for network protocols and aims to interconnect systems from different sources. It is divided into several layers or levels:

 

  1. Physical Layer: physical structure (wireless, coax cable, repeaters, hubs)
  2. Data Link Layer: Frames (ethernet, switches, bridges)
  3. Network Layer: Packets (IP, IPSec, IGMP)
  4. Transport Layer: End-to-end connections (TCP, UDP)
  5. Session Layer: Sync and send to port (APIs, Sockets)
  6. Presentation Layer: Syntax layer (SSL, SSH, FTP)
  7. Application Layer: End-user layer (HTTP, FTP, IRC)

 

You have noticed that there are only 7 layers... the 8th layer that the IT guy mentioned was the user. An error in the 8th layer means that it is the user's fault. (I know, I could just say this last part, but think about it, now you know about the OSI model as well.)

 

Let me put it this way… let’s say that a doctor in medicine spends more than 10 years at a university to learn to perform their job; by the time that they are working in a hospital, they probably missed most of a decade’s worth of technology changes. Since they don't have much time for anything else while they study medicine, how can we expect that they would know how to use your (lazily built) user interface? The same interface that you built with the mantra, "I'm going to put this anywhere, I’m not a designer!” I know, it wasn’t done intentionally; part of the problem is that we tend to compare ourselves to the user; we use ourselves as a prototype of the user. But guess what? You and the user are far from the same.

Part of the problem is that we tend to compare ourselves to the user; we use ourselves as a prototype of the user.

 

You need to have real conversations or interaction with your actual users. Don't wait until the final phase of the project to add a bit of UX to it; that usually doesn’t work. UX is very important, and as competition evolves, each company must work harder to build something all users can interact with.

 

As I said before, you can say, “I'm not a designer, I don't have to take care of that.” But you can find cases like "The $300 Million Button," where a company made a change in one label in their e-commerce website and they saw an increase of $15 million in revenue the first month and an extra $300,000,000 by the end of the year. Think about it — it is wildly impressive that such a “minuscule” change can bring about such a massive impact on revenue. Each case is different. Maybe you are focused on reducing the number of support calls by leaning more towards self-service: for example, McAfee’s engineers designed a process that cut-off 90% of the calls from users to get support. Sounds amazing, doesn't it?

 

It's our responsibility as engineers to facilitate the user and customer journey.

 

We’ve all heard someone say, "Oh my little son is so smart, he knows how to use an iPad and he is only 3 years old." The truth of the matter is that some very clever engineers strived to build an incredibly user-friendly interface. We could test it by giving that same child an old Palm Treo to see how long they spend trying to use that.

 

Now I'm going to give you 3 points to keep in mind when it comes to building applications.

 

1. Become user-centered.

Stop making decisions based on things like ego, hot topics, or something that your favorite tech influencer just tweeted. Your decision should be guided by the user's needs, goals, expectations, and motivations rather than yours.

 

Whenever you have the opportunity to build something, you should build it with the user in mind. Usability is better than beauty, and users will thank you when they find out how to use a new feature without spending too much time reading instructions. They're going to be happier and more productive if you put just the options that they may need instead of all those that you with your superpowers are able to come up with.

 

2. Avoid lazy behavior with the UX.

 

I know, we have to keep several things in mind when we are building, such as: interpret functional requirements well, consider non-functional requirements that weren't listed in the requirements, and also maybe use some awesome programming language or library. All of those things to "Show an incremental number in a label." Carrying out all those things may consume too much of your energy, so when it comes to caring about how the user is going to use it, maybe you are not paying too much attention to that.

 

You should be using self-constraint to avoid makes some basic UX errors; here are some don'ts:

 

  1. Don't throw tons of data on the screen: I don't know your user, but they probably don't need the whole database on their screen at once.
  2. Don't expose the tech to the user: even as a technical person consuming an external API we expect to receive a well-formed message for an error code.
  3. Don't be inconsistent: if you already decided to move the close button to the bottom of the window, make sure it’s the same in all your windows.

 

3. Be aware of cognitive bias.

Cognitive biases are “bugs” that the human mind has. You can find a very extensive list out there and see how they may affect how people perceive reality. It's very important to know that you may be affected by one of them when you are creating something, so here are some common ones to keep in mind:

 

  1. Bias blind spot is the cognitive bias of recognizing the impact of biases on the judgment of others, while failing to see the impact of biases on one's own judgment.
  2. Déformation professionnelle (“nerdview”) is a tendency to look at things from the point of view of one's own profession or special expertise, rather than from a broader or more humane perspective.
  3. Semmelweis reflex is a metaphor for the reflex-like tendency to reject new evidence or new knowledge because it contradicts established norms, beliefs, or paradigms.
  4. The bandwagon effect is a phenomenon whereby the rate of uptake of beliefs, ideas, fads, and trends increases with respect to the proportion of others who have already done so. As more people come to believe in something, others also "hop on the bandwagon," regardless of the underlying evidence.
  5. Confirmation bias is the tendency to search for, interpret, favor, and recall information that confirms or supports one's prior beliefs or values.

 

Finally, I want to let you go with the thought that taking responsibility for how users are going to use the application that you are building is the fairest way to think about it, because, in the end, you are the professional in software construction. Think a little bit about the users no matter what task they are performing. It is your duty to help them with your applications instead of bringing them more problems.

 

Whenever you find yourself thinking something like "They ask for a form, here is a form," remember all the frustration that you feel when you're using any awful software in your daily life, maybe because there is no other option. Think that you have the opportunity to make someone happy, every time they use that form you are about to craft.

 

If you like this type of content, feel free to follow us in our social network accounts.

View all posts

Recommended Reading

Subscribe and stay up to date

No spam, we promise! You will only 
receive essential emails.

Speak Your Mind

book a free demo

Subscribe and stay up to date