User Experience: A Psychological Perspective

As the author of this article, I am deeply committed to maintaining the highest standards of integrity and transparency in my work. For that reason, I want to clarify that no part of the below article was generated or written by ChatGPT or any other AI tool.

I believe in the power of human creativity and intellect, and this article is a testament to that belief. Thank you for taking the time to read, and I hope you find the insights provided both informative and thought-provoking.

“You’ve got to start with the customer experience and work backward to the technology. You can’t start with the technology then try to figure out where to sell it.”? – Steve Jobs

?

I love roundabouts, I love the Kroger app, I love Amazon and I love the fact that the cup of coffee I’m drinking was made by inserting a packet into a machine and, in a minute, I’ve got coffee. “User experience” and “user interface,” often called UX/UI, are popular concepts among product development teams. In tech, a product development team is a team comprised of product strategists, technical managers, software engineers, UX/UI designers, DevOps engineers, and quality assurance analysts. ?The look, feel, and overall product workability is ultimately what makes a great product. For this reason, effective communication between a UX designer and software engineer is of the upmost importance. Historically, reaching this point of effective communication between the engineer and designer has been somewhat of a challenge.

?

Engineer vs. Designer

Scott Hanselman, Vice President of the Developer Community at Microsoft, hosts a podcast which explores all aspects and current trends within software engineering. In his episode “Designing with Code,” Scott Hanselman and his guest Dr. Jensen discuss the differing perspectives between software engineers and designers (UX/UI). Both coming from software engineering backgrounds, they discuss the communication difficulties engineers and designers face whilst communicating with each other. Hanselman kind-heartedly says, “I don't mean to talk about [designers] behind their backs, but there's a feeling that [designers] will typically give a software engineer a design and then throw their hands in the air saying, ‘well, I couldn't control what came out on the screen because I gave them the poster and they just weren’t able to replicate it.’”? Many times, Hanselman points out, “[designers] are commonly disappointed when their design comes out and doesn't look the way they want.” Dr. Jensen contributes to Hanselman’s point by pointing out the cause of this disappointment and the main reason, she believes, silos are formed between UX designers and engineers. “It's something that, no matter the size of the organization, I've heard for years and years. ‘Oh, we need to break down the silos.’ You hear that everywhere, all the time.” Dr. Jensen points out that the cause of this isn’t due to a lack of willingness to communicate, but in her belief that engineers and designers are siloed by the very tools they use. She says, “we are siloed with the mediums we work in. There's so much built in that it reinforces the silos and I really wish we could get to a place where I'm not a designer and you're not a developer, but we're product creators, both of us.” She uses an example of how the different tools used between engineers and designers promote siloed environments, explaining that Figma, a common design tool within tech circles, has around 20 different data types that can be worked with. In contrast, programming languages such as TypeScript have somewhere in the ballpark of 360 data types. This means that the designer using Figma has a far more limited capacity to express their thoughts. Both Hanselman and Jensen agree; this is a big reason for the gap. Ultimately, Dr. Jensen has set out to solve this. Her startup, Henosia, aims at developing a “no-code“ solution that enables designers to do what they do best while simultaneously updating the underlying code. In addition, Henosia’s service will also directly pull and push code into repositories. For those unfamiliar with programming, a repository is just a place where software engineers share code with each other. Ultimately, Henosia’s vision has proven to be a monumental undertaking, but their team is making great progress. To truly push the needle, engineers and designers must constantly be on the same wavelength and Henosia brings us one step closer to that realization.?

??

Elon Musk’s Perspective

To further demonstrate the differing fields of software engineering and UX design, I’ll steal a quote out of Elon Musk’s playbook, where he describes the difficulty of manufacturing a car compared to the process of designing a car. He says, “The hard part by far, is manufacturing, not designing the car. In order to make it affordable, you have to make it at volume,” he says. “You have to make everything at high rate, and you have to do it consistently. If you toured the production line, you’d have a sense for it. Manufacturing is somewhere between one-hundred and a thousand times harder than making a prototype. I really cannot emphasize enough how hard manufacturing is relative to design. It is extremely trivial to churn out prototypes and it is extremely difficult to build a factory.” As a software engineer, I’ve come across stories of disgruntled software engineers who complain about the “inability” of UX designers to fully comprehend the challenges and time-constraints associated with the actual development of the designs they create. Based on industry anecdotes, it’s not uncommon for UX designers to “throw” a design on a software engineer’s desk that is 1) unfathomably difficult to code and 2) ridiculously time constrained. In tech, engineering is equivalent to vehicle manufacturing as UX design is to the creation of vehicle prototypes. That’s not to say that both designers and engineers aren’t experts in their field; they are. Each requires an extraordinary amount of knowledge and creativity. While true, I believe it’s important that each side relates to and has a mutual understanding of the challenges that the other side faces. While tools such as Henosia are phenomenal undertakings of the potential and future of product design, I believe that achieving true congruency takes an effort from both designers and engineers. For this to happen, each side much get to know their counterpart’s undertakings on a deeper level. For designers, this means getting their hands dirty with some code. For an engineer, this means learning about the implementations of design.

?

Daniel Ek’s Obsession

I recently watched Netflix’s new docuseries, “The Playlist.” For some, this docuseries simply told the story of Spotify. For me, it was a powerful illumination of what happens when an obsession over user experience and the power of technology meet. Before making billions, Daniel Ek, CEO of Spotify, sold his first company for $1.25 million. Shortly after, Ek bought a red Ferarri and invested the rest into Spotify. The entire Netflix series was great, but I was most impacted by the episode “The Coder,” which explored the technical development of Spotify’s music player. This episode, featuring Spotify’s first CTO Andreas Ehn, portrayed the insane technical aptitude that went into Spotify’s development. In addition, the episode portrayed the constant battle between Daniel Ek and Andreas Ehn as Ek demonstrated his maniacal obsession over Spotify’s user experience. In the process, Ek made requests of the CTO that were, at the time, technological impossible. The development team was forced to come up with a solution that would break technological laws. This caused friction within the team, but Ek’s obsession over the user experience ultimately pushed the development team to not only create the world’s greatest music player, but also invented a new form of computer architecture in the process. While Ek’s requests were, at the time, deservingly perceived as “unfathomably hard to code,” the development team’s resilience and buy-in resulted in a piece of computer science history. So, while a UX/UI designer’s requests may seem ridiculous, I believe it’s important to put their requests into perspective. Instead of criticizing a designer, we should be thanking them, and view the challenge as an opportunity to expand our skillset. Truly great things happen only at the doorstep of ridiculous requests, and when both sides are on the same page, I believe truly amazing things can happen.

?

Staying true to my belief that “true congruency takes an effort from both designers and engineers,” I recently dove into Jon Yablonski’s book, Laws of UX, to gain a deeper understanding into the world of design. Below, we’ll explore the nine laws described in the Laws of UX. For context, these laws are all based on psychological principles. Ultimately, Yablonski wrote the book because of the need to explain his own designs in the absence of quantitative data. Without the backing of quantitative data, design interpretations can be somewhat subjective. For example, whether the color of a certain border should be “Turquoise Blue” or “Aqua” is predominantly subjective. Mitigating this subjectivity, the nine laws enable a designer to make logical decisions without quantitative data. Real-time data is basically gold in today’s world, but the laws don’t take a backseat as they are extremely relevant and backed by decades of research. Whether were whipping a Tesla, binging The Office, or dining at our favorite restaurant, human phycology doesn’t change, and the elements that effect user experience don’t either. This is what Laws of UX is all about. Whether using Twitter, PayPal, LinkedIn, Amazon, or any other great tool, all these laws are present, and they have a monumental effect on our user experience.

?

The Network Effect

The first law revolves around the fact that a typical web user will spend more time on all other sites than on just one individual site. This is important because, in our daily lives, there are certain things we’ve come expect from the tools we use. For example, we expect the steering wheel of a car to be round, not square. We expect the laces of our shoes to come up to the top instead of the bottom. There are certain things we expect. Websites are no different. For example, we expect a website’s navigational tabs to be at the top. This helps us move throughout each website because we understand the main premise of how a website should work. In turn, a website should provide the tools (navigation tabs, search functionality, etc.) to make this happen. An individual website’s core functionality should behave like that of other websites because we spend most of our time on those other websites. This is the idea behind Jakob’s Law.

?

While ubiquitous functionality is crucial, this doesn’t mean that websites must look the same. Today, many do. In another design-focused podcast, Scott Hanselman sat down with Kathryn Grayson Nanz, author of Foundations of Design for Developers, as they discussed the benefit of having a solid understanding for both engineer and design principles. Based on the state of current web trends, Hanselman feels that we're heading towards, if not already in, a homogenous internet landscape. He says, “We've all found our colors, we've all found our rounded buttons. Most websites have a big ‘hero’ image, eight boxes, and pictures of people who've got quotes.” The reason for the homogenous landscape of websites unlikely stems from a lack of creativity – the world has plenty of that. Nanz, author of Foundations of Design for Developers, thinks the trend of similar-looking websites is due to the fact that development teams don’t necessarily need a designer on their staff to make a website that doesn't “look terrible.” Today, we have no-code solutions such as Wix, GoDaddy, and SquareSpace which allow virtually anybody to create a website. If not Wix, GoDaddy, or SquareSpace, then we have many software development frameworks, such as .NET Core, which allow for rapid website deployment. This empowers everyday people to showcase their ideas. While the ability for everyday people to create their own website is wonderful, this ability has also resulted in a sea of websites that, frankly, “don’t look terrible,” as Nanz put it.

?

Nanz goes on to say that the default templates provided by Wix, GoDaddy, and SquareSpace are all perceived as being “good enough.” We have a bunch of sites that are “80%” fine, says Nanz. In addition to our reliance of no-code web-building templates, many developers also rely on ChatGPT, which has been shown to dramatically improve a developer’s productivity with auto generated code. While true, the quality of that code, many times, is just fine. It works and functions, but Nanz wants it to be known that websites can be amazing. She says, “We could go way beyond and it’s a bummer we don’t.” Nanz believes this is because people don’t think they’re good enough to create a “90%” website and thus, we settle for a “60%” template that’s “good enough.” When you see a website that feels unique, it sticks out and you remember it. At the end of the day, the challenge of creating a functional and unique website is the dilemma we face with Jakob’s Law.

??

Click Here

In plain words: big and near objects are easy to click while small and far objects are hard to click. The law states that buttons should be easily selectable. We do this by making them large enough for users to discern and select them. Secondarily, we should provide enough space between buttons to avoid accidental selection of a wrong button. You’ve probably never given much thought to it, but the application icons on your iPhone follow Fitt’s Law. How many times have you pressed the wrong application icon? Unless you got bratwurst fingers, probably never. The icons are perfectly positioned. This is the main idea behind Fitt’s Law which, like other laws, applies to tablets, PCs, and smartphones. In a future article, we’ll explore in-depth examples of Fitt’s Law.

??

Too Many Choices

Hick’s Law states that the more options given to a user, the longer it will take them to choose. The focus of this law is to reduce cognitive load. Ultimately, Hick’s Law is modeled by the mathematical formula RT = a + b log2 (n), where ‘RT’ is response time, ‘a’ and ‘b’ are both regression coefficients, and ‘n’ is the number of choices. Ultimately, more choices lead to longer selection periods which lead to lower conversion rates. An example of Hick’s Law was demonstrated in a study showing customers were more likely to purchase a jar of jam when there were six displayed flavors rather than 24. In the end, too many flavors deterred potential buyers. In a future article, we’ll explore examples where real-world UX designers have come face-to-face with this law.

??

Information Overload

Miller’s law states that the average person can only keep 7 (plus or minus 2) items in their working memory. In the world of web development, the historical status quo has been to limit navigational links (links at the top of the website) to a maximum of seven. If you’ve dabbled in web development, odds are you’ve heard about the “magic number seven,” but the actual number is anywhere from 5 to 9 items. On any great website, Miller’s law will be there in the form of “chunking.” Stated simply, chunking breaks big things down into smaller chunks, which ultimately allows for easier content-management.

?

It's my belief that Amazon uses Miller’s Law on both sides of the coin. For example, we see Miller’s Law in places where they want you to act, such as making a purchase. On the same coin, they remove the law where they don’t want you to feel comfortable, such as finding the link for account cancellation. In this case, Miller’s Law is used to attract and derail, both for Amazon’s benefit. I’m not “calling out” Amazon or attempting to exploit their potential use of “dark patterns,” but only emphasizing the importance of Miller’s Law. Ultimately, the law has a huge impact on a user’s psychology. In a future article, we’ll explore in-depth examples of Miller’s Law.

?

Errors Aren’t Allowed

Postel’s Law, also known as the “robustness principle,” presents a unique challenge to software engineers as the law primarily centers around data collection. All in all, the premise of this law is to anticipate anything in terms of input from the user. As a team, both engineers and designers must be empathetic to the mind of the user. Have you ever tried to enter your phone number (or a date) in an online form, only to get an error? You entered mm/dd/yyyy but you get an error stating that “Date must be in the format of mm-dd-yyyy.” According to Postel’s Law, both should be accepted. This is the software engineer’s job – to write software that interprets both inputs as a date. Ultimately, the underlying software should format the data, regardless of the original format, to reflect the format of the date as it’s formatted in the underlying database. All of this happens without user intervention. The user never encounters an error, and they move onward.

?

The second pillar of Postel’s Law is to be conservative in how much information we ask users to provide as studies have shown that too many form fields reduce the likelihood that users will complete a form.

?

The third pillar of Postel’s Law of Postel’s Law is to provide clear feedback. Ultimately, this law emphasizes the need to point users in the right direction, especially following errors. In a future article, we’ll explore in-depth examples of Postel’s Law and its impact on user-experience.

??

Hawaiian Rollercoaster Ride

The Peak-End rule states that people judge an overall experience based on how they felt at its peak and how they felt at the very end. This contrasts with gauging the experience based on the total sum of all moments within an experience. An example of the Peak-End Rule was seen in an experiment where people submerged their hands in cold water. The first trial involved participants submerging a hand in 14°C water (roughly 57°F) for 60 seconds. The second trial involved participants submerging the other hand in 14°C water for 60 seconds and then keeping it submerged for an additional 30 seconds as the water was warmed to 15°C. When given the choice of which experience they would repeat, participants were more willing to repeat the second trial, despite them having a longer exposure to the uncomfortable water temperatures. The participants chose the longer trial simply because they preferred the memory of it.

?

The Peak-End Rule can be applied to various components of web design. This includes our most favorite, exhilarating moments while browsing - loading times. Instead of a blank loading screen, we can make the loading screen entertaining and informative. Interesting facts, tips, or animations can enhance this moment. In a future article, we’ll explore in-depth examples of the Peak-End Rule, exploring how companies create great interactions throughout the user journey and at the very end.

?

Don’t Judge a Book by It-

As human beings, we do and should judge a book by its cover. It takes seven seconds for us to judge another person upon first meeting them. Linda Blair, clinical psychologist and author of Straight Talking says, “It’s not a conscious process, and we don’t even realize we’re doing it – but it goes back to our primitive roots when we couldn’t afford to make wrong decisions.

?

Whether a product or service is more useful or not, users ultimately see a product with an aesthetically pleasing design as product that’s more useful. This can be seen in Apple’s product line. Considering Apple, the beauty and sleek design is ultimately why we gravitate. Contrary to what we’ve been taught not to do, we do, in fact, judge books by their covers. Automatic cognitive processing is helpful because it fosters quick reactions, which is vital to our survival. Beauty and organization give the impression of serenity, which is why, according to Stanford University, 94% of first impressions of a website are design related. In addition, studies have shown that people form an opinion about a website within a mere 50 milliseconds of seeing it. The pace at which we make this first-impression is astonishing and the opinion formed during this brief period rarely changes as users move throughout a site.

?

What’s Over There?

In the presence of multiple objects, the one that differs from the rest is most likely to be remembered. Ultimately, this effect is used to draw users to a certain product, service, or section. There are many ways a designer can implement the Von Restorff Effect. One of which is color, which can nudge a user in a certain direction using contrast. In addition, scale, shape, negative space, and motion also play important roles.

?

While contrasting colors have an impact, the sole reliance on its effect is less than ideal as 7% of the population is color blind. For this reason, it’s important to prioritize effects such as scale, shape, negative space, and motion. Obviously, a website must have a good balance. Too much of the Von Restorff Effect and people will tune out the noise, much like a coach that gives too many compliments. After a while, an athlete becomes numb to “Great Job” just like a user becomes numb to “Only 1 Left in Stock!” Ultimately, balance is key. In a future article, we’ll explore common “attention-grabbing” methods on the web and hopefully, find out if they work and to what degree of an effect their implementation has.

?

Tesler’s Law

Tesler’s Law states that, for any system, there is a certain amount of complexity that can’t be reduced. That’s it.

?

Speed Kills

The last law is the Doherty Threshold, which is one that puts the challenge on the engineer. There are many components that contribute to the speed of an application, which is why the Doherty Threshold creates a fascinating challenge. Ultimately, the Doherty Threshold states that productivity soars when a computer and its users interact at a pace of less than 400 milliseconds. A 100-millisecond response time feels instantaneous. Between 100 and 300 milliseconds, people begin to feel “less in control.” Once the delay extends beyond one second, the human mind begins to wander. In the process, information pertaining to a user’s task begins to fade, leading to an inevitable reduction in performance. Countless studies reinforce the fact that the longer the wait time, the more likely a user will grow frustrated and abandon a task. According to Google, as page load time increases from one second to 10 seconds, the “bounce” probability increases by 123% on a mobile site.

?

It goes without saying that speed kills. On the same token, delays and unexpectedly long load times will happen. Speed is a priority, but handling situations when delays happen is also important. Ultimately, there are a couple main ways to handle this. The first is using front-end technologies like JavaScript, TypeScript, or Blazor (for C#) that give the appearance of a screen that is “loading.” For example, we’ve all experienced blurred images on a website. This isn’t the actual image in a “loading state.” Instead, this is an extremely small version (one that will inevitably load faster) of the larger, higher quality image that will eventually load. This gives the appearance that the image is loading faster than it actually is. This pseudo-image is somewhat like a progress bar. Research has shown the progress bars make wait times more tolerable, regardless of accuracy. Ultimately, progress bars let the user know that their request is, in fact, processing. In addition, this provides visual interest while they wait, which reduces the perception of waiting by shifting focus to the animation as opposed to the actual process of waiting.

In addition to image loading, another example of “pseudo-loading” is seen on Instagram. Here, Instagram displays comments before they’re actually posted (updated in a database). This makes the app’s response time seem faster than it is, which immediately provides visual feedback. The required processing still happens in the background, but the user’s perception of the app’s performance is improved.

?

Ultimately, the idea behind a progress bar or pre-loaded images is about keeping people “in the loop.” This leads to another important consideration. It’s important to let people know that they are, in fact, waiting, but it’s equally important to keep people in the loop of what is specifically happening while they wait. People appreciate transparency. Web design is no different.

?

Tech Learns a Lesson for Healthcare

About a year ago, as an intern at Norton Healthcare, I dove into the book Transforming Healthcare: Virginia Mason Medical Center’s Pursuit of the Perfect Patient Experience. Ultimately, the book describes Dr. Gary Kaplan’s journey, who became CEO of Virginia Mason in 2000, and the transformation he led at the hospital. At the time of becoming CEO, Dr. Kaplan inherited a hospital that was losing millions and millions of dollars each year. The first thing he did as CEO was gather around 30 of the company’s top executives and took them all on a vacation to Japan. Keep in mind that, at this point, the company’s bottom line was in terrible condition. As you can image, this raised eyebrows, but Dr. Kaplan had his eyes set not on Sukiyabashi Jiro (Japan’s most famous sushi house), but rather on the Toyota Production System. On this “vacation,” the Virginia Mason team learned alongside some of the world’s greatest manufacturing minds, working alongside and learning about the system (TPS) that made Toyota one of the most efficient companies in the world. Ultimately, Dr. Kaplan and his group of executives brought their knowledge back to The United States and, over the course of a decade, transformed Viriginia Mason into one of the most efficient hospitals in the world. Soon after, other Hospitals sought advice and began making trips to Virginia Mason’s headquarters, just as Virginia Mason took a trip to Toyota’s headquarters a decade earlier. While customer wait times aren’t necessarily a part of the Toyota Production System, Virginia Mason brought the principles of lean manufacturing to the problem of wait times within their hospitals. In the end, the principles behind lean manufacturing and TPS helped Virginia Mason reduce wait times that their patients faced. In addition, Virginia Mason made it a priority to keep their patients in the loop, informing them of what was happening behind the scenes while they waited. In the process, patients were informed about the status of their appointments in real time, which involved communicating delays and providing estimates on when a patient would be seen. This helped manage patient expectations and reduced frustrations associated with uncertainty. Ultimately, as users or patients, we want to know what’s going on. Transparency plays a huge role in fostering customer and brand loyalty through trust.

?

In a future article, we’ll explore the details of the Doherty Threshold, including diving into how, technically speaking, we can make a product faster. In addition, we’ll dive into details as to how Spotify created to world’s fastest music player and, lastly, look at other quantitative metrics that reveal the impact that speed has on user experience.

?

Closing Shop

The psychological principles demonstrated by the Laws of UX are the tip of the iceberg. In future articles, we’ll explore the laws more in-depth as we look at real-world examples and explore various tools we can utilize to demonstrate these laws. We’ll dive deeper into individual laws, such as the Doherty Threshold, to become familiar with the tools and knowledge we need to make a website, in this case, faster. While the psychological laws presented may be obvious after reading, a user is often, and should be, unaware of their presence. This is especially true for great products. For this reason, it’s important that engineers and designers understand the laws so we can ensure they are all present in a product. Ultimately, the combination of design and engineering expertise is what makes a product great. Whether we’re talking about Spotify, Amazon, or Apple, each company serves as a representation of the power behind a combination of design and engineering. Ultimately, when the two paths cross, the potential for creating a world-altering product gets that much greater.? ?

I hope you enjoyed the read and were able to get something from it. As always, thanks for reading, and good luck.