The User Interface and the Halo Effect

December 4th 2012

If you've been a software developer for even a small time, you've undoubtedly lived this frustrating scenario...

You've been working feverishly to implement a new feature for your customer. There's some crazy complexity in the business logic, and a very simple UI as well. It's a lot of work.

With a herculean effort, you just about meet your deadline. The business logic is bullet-proof, but the UI is still a little rough. No worries though, that's the easiest and least risky part.

You head off to demo it for the customer. They immediately start picking at the UI: "the alignment of this column is off", "this label should be bold", and so on. Before they even get to the actual functionality (the meat of the work!), you can tell they're already a little underwhelmed.

In the end, everything works great, just a few minor UI glitches. You know it's truly a big success that it's even functional, but the customer isn't ecstatic, and you can't help but feel a little dejected.

So is it reasonable to feel this way? Yeah, probably. But it shouldn't be unexpected. As most seasoned developers know, the user interface carries an incommensurate amount of weight in terms of the customer's perception of the quality and completeness of the product. One reason this is true is due to something called the Halo Effect.

In a nutshell, the Halo Effect is a built-in cognitive bias that drives us to believe that if our initial impression of something (or someone) was favorable, the rest will be favorable as well. For example, plenty of studies have shown that we're more likely to confer positive traits (like intelligence, creativity, etc.) to good looking people, even when we know little (or nothing!) about them other than their appearance.

Or consider another example adapted from a famous experiment by Solomon Asch: imagine there are two people vying for a job, and all you know are a few attributes. Person A is...

intelligent, inquisitive, calm, serious, passive, unambitious

...and Person B is...

unambitious, passive, serious, calm, inquisitive, intelligent

Without thinking too deeply, who would you hire? Your intuition probably steered you to Person A, but if you look closely, both A and B have the same exact attributes, just in opposite orders. Why would we perceive them differently?

Well, after reading just one or two characteristics, we already begin to form a general impression of the person. Subsequent characteristics can serve to enrich this view if they are consistent with the initial characteristics, but if they conflict then they get filtered out (or at least carry less weight). In other words, our brains prefer coherence, and disregard dissonance.

Back to the world of software development, it's now more clear why minor user interface peccadillos (a typo in a label, for example) can significantly impact a customer's perception of the overall quality or even value of the software we build, to an extent that seems capricious or unfair. That's just how our brains work.

Essentially, the user interface is the physical appearance of our applications, and as such, customers will use it to form their initial impressions of the application as a whole. Once this impression is formed, it's difficult to undo. If the user interface is organized, clean, and pleasing, the customer will naturally assume the system behind it is too; but the opposite is true as well.

In the end, especially if you're early on with a customer and trust hasn't been completely established, don't focus on the back-end to the exclusion of the front-end, even if the UI is a cinch. That mis-aligned column may only take 15 seconds to fix, but it'll be worth a whole lot more in terms of your customer's perception of quality!

I'm an "old" programmer who has been blogging for almost 20 years now. In 2017, I started Highline Solutions, a consulting company that helps with software architecture and full-stack development. I have two degrees from Carnegie Mellon University, one practical (Information and Decision Systems) and one not so much (Philosophy - thesis here). Pittsburgh, PA is my home where I live with my wife and 3 energetic boys.
I recently released a web app called TechRez, a "better resume for tech". The idea is that instead of sending out the same-old static PDF resume that's jam packed with buzz words and spans multiple pages, you can create a TechRez, which is modern, visual, and interactive. Try it out for free!
Got a Comment?
Comments (23)
John Coleman
December 04, 2012
I've seen this summed up in other places thusly: "The user interface IS the application." It's become a mantra for my development team.
Dr. Shishir S. Urdhwareshe
December 04, 2012
really good observation - completely true - it is ONLY the UI that the client will pay any attention to. Thanks
December 04, 2012
"The customer's not irrational, it's just how our brains work."

Yes they are. Our brains work irrationally.
December 04, 2012
Thanks for the comments, John and Shishir.

@Ursus - You're 100% right! I may rephrase that.
Dr. Michael Scarn
December 04, 2012
Your blog entry made it to the front page of reddit (without a single mention of cats).
Colin Nicholls
December 04, 2012
This explains Windows 8 / Metro: Set the bar so low that no-one need worry about disappointing the user with a crappy UI again.
December 04, 2012
Reminds me of "The Thickness of Napkins" :
December 04, 2012
Perception is reality; Prison, politics, and courtroom all come to mind.
December 04, 2012
This article is right. That's why for us the UI is of highest importance.
December 04, 2012
Another potential take-away: don't present too good of a UI too fast, or the project will seem stalled for months afterwards, since the client might see "no significant progress" will have been made since the initial unveiling.
Slappy White
December 04, 2012
Stupid losers, er, users.
December 04, 2012
I deliberately make my UI look unfinished -- lots of fuchsia, aqua and yellow in large blocks all over a web page, lots of hand-drawn cartoony graphics on buttons and a monospaced font in applications -- so that users will know immediately that they're meant to concentrate on something else. It did backfire one time when my users loved my cartoony buttons so much that they insisted they had to be included...
December 05, 2012
@Colin: You think the UI formerly known as Metro is bad? Check out the Outlook app on Android. Ahahaha!
December 05, 2012
My approach to the user interface portion of software design is to provide users with an interface which they themselves can manipulate and turn into their own design. It really shouldn't be programmers who are responsible for the user interface at all anyway; it should be users who are responsible for the user interface. Programmers should only have to be responsible for giving users some tools which enable users to create their own.
December 05, 2012
ROFLMAO @Colin... If you think so, keep on using whatever crappy OS you want. Future is now.
December 05, 2012
Good UI should be undesigned like Metro:
December 05, 2012
Thanks again for all the comments.

@Michael - yeah...front page of Reddit (without cats, bacon, imgurs of iphone texts, etc.)! I'm pretty pumped - glad people enjoyed the post.

@Jeff, Eric - really good points. As some people mentioned in the comments of reddit, there are times when you specifically don't want the customer to focus on the UI (either it's unfinished, still in analysis/design, etc.). In these cases, just showing a low-fi mockup can be helpful (we use Balsamiq, and it works well).

@James - great link. I had not read that before.

In general, I think the Halo Effect is interesting because it suggests that the first thing we put in front of customers they will use to form an initial impression of our work. Most often, this is the user interface, but if the audience is different (an architecture team, etc.), then this might be a diagram, or a requirement spec, etc. Quality matters everywhere, and especially at the surface of our systems.

Anyway, thanks again!
December 05, 2012
This is a difficult thing to get across to programmers that are religious about their application being perfectly OO or MVC or whatever.

The funny thing is these same programmers have some "awesome idea" they are working on, yet never put a wrapper on it and deliver because they are still normalizing their database, or adding more layers of abstraction.

It's very similar (in principle at least) to the college English professor working on a novel of his own for years and years, never releasing it until it is "perfect".

Instead, get the concept down, build the excitement of the stakeholders, and save the boring (in the eyes of the stakeholders anyways) writing of classes and functions and other stuff for after everyone is on board.
Nick Harris
December 05, 2012
My only goal is to boost productivity. Software needs to be useful, usable and beautiful in that order of priority. Aesthetics aid comprehensibility which improves usability. An ergonomic layout not only feels nicer, but looks confident and reassuring of its quality.

Yet, an interface could not achieve such elegance without underlying sophistication. A programmer has to shift the burden of work away from human beings and onto our silicon slaves.

Why are forms wanting to know our name and address, over and over again? Credit card details need to be entered on each and every purchase. Security codes and user identification that could live on a biometric USB memory stick that lives on your key fob could ease online shopping even on someone else's computer. We need desktops, laptops, tablets and phones to know where they are and how they are oriented. The altitude and temperature too, with internal clocks that never need to be set. Volatile RAM should not hold our data hostage, we should have persistent documents within zero friction computing environments not an uncoordinated mess of applications that each compete to host a subset of media types underpinned by an intrusive operating system that is continually begging to be updated, inoculated or reinstalled.

The more the hardware and software do to automate all inconsequential choices the better our intellectual stamina can be put to work on directing it to our will. Custom UIs should be supported for this reason as advanced users may want a different set of capabilities foregrounded than a total neophyte. We shouldn't know or care what the name of our word processor or photo editor is, nor should we care what version of OS we are running as this should automatically be updated to the latest without ceremony or fanfare. If the majority of what we do involves manipulating multimedia documents either for, or with, the benefit of others via the Internet then should we care if we are running Windows, or some version of UNIX. We seem capable of making a telephone call from a landline without even being aware of who manufactured the device, yet all mobile telephones and computers force us to be aware of who made them as if aspect ultimately mattered in the long run.

Eventually, in time all of this will go away and we will be left with computing.

Not computers.
December 05, 2012
This is a very interesting read. Something to tuck in my back pocket and bring up at my next dev meet-up. Good work!
December 05, 2012
Especially if the UI takes about 15 minutes to fix and we didn't fix it, possibly the user would think if those quick fix items are not fix, then what about the others?

Kinda if you buy a car and the door handle is imperfect. If the manufacturer cut corners on simple things like that, what else do they cut corners on?
Avery P
December 06, 2012

I agree that developers shouldn't be designing the interface (with few exceptions). I've met spectacular software engineers that are terrible designers, and excellent UI designers that couldn't write code to save their life. I believe the point of the article was "don't skimp on the interface, because that's the face of your application." The best solution in my opinion is to have a dedicated UI designer working with a dedicated software engineer.

With that said, I strongly disagree that user's should be responsible for the interface design. There are some fields that having the ability to customize the interface is extremely valuable, but for the most part, the interface should be good enough that the user doesn't need to go through the effort of designing their own interface. There is a fine line between "giving the user freedom to choose" and "forcing the user to make a decision."

Take the iPhone for instance -- you can rearrange the order of apps on your home screen, but you're still stuck with the "left-to-right, top-to-bottom" layout. In your music app, you can choose whether you want Artists, Albums, Songs, Playlists, Composers, or Genres in the toolbar, but you can't move the toolbar around. Yet, despite these shortcomings in customizability, the iPhone has been a huge success.
July 26, 2013
Great article!
The idea is exactly like in the experiment with person A's and person B's characteristics, as well as real-life first impression.
Even though people shouldn't judge a book by it's cover, this is generally the case, even if it is unconsciously.
The bad thing about this approach is that the customer may get the idea that the functionality is no good, even though making the functionality perfect is the reason why the UI is maybe faulty.
That's why, when working with customers that are not programmers as well, that don't know the background of an application, just wants it done, great attention should be paid for the user interface, since it is the cover of the book that is to be judged.