Why Beauty Matters: Unexpected Learnings from a Refugee Camp
Sometimes it feels as though functionality is all that matters in software design. But a focus on aesthetics shows people that we care about their whole experience.
In the Fall of 2013, Raul Pantaleo, Co-founder of the architectural firm TamAssociati, accepted the Curry Stone Humanitarian Design Prize for the work his firm had done designing and building healthcare facilities in war-torn areas, such as refugee camps in the Sudan and Sierra Leone.
His designs are functional and sustainable, but they are also extraordinarily beautiful. People might not expect to find this kind of beauty in such extreme, harsh conditions, and some may even question whether it is a priority. When asked why a focus on aesthetics was important for these projects, he explained:
“Beauty is the first message you give the patient, that you consider them as equal.”
I was so moved by this notion. It put into words something that had been hard for me to articulate over the years I had spent working on highly utilitarian designs for Google, YouTube, and now Facebook. Great design solves a real problem and improves people’s lives. It can also be accessed and used with a minimum of confusion and strife. But companies, especially high tech companies, have struggled with whether or not beauty really matters. If you get the two first parts right, won’t people be satisfied?
The answer is yes. And no. Certainly, no matter how beautiful a piece of software is, if it’s not useful and usable, it won’t make a meaningful impact in the long run. Sure, it may give people a fleeting sense of aesthetic satisfaction, but like a diet of high fructose corn syrup, it doesn’t satisfy you for long. You eventually realize the need for something more substantial, something more valuable and meaningful.
For decades, the user interfaces of most software were fundamentally so badly designed that the bar for usability was tragi-comically low. While there were some interesting ideas for products that could add value, like word processing and spreadsheet software, they were so difficult to use that most people couldn’t access or realize that value. Lotus Notes, various Microsoft products, and the first generation of search engines are all excellent examples of this. Products that weren’t focused enough on their raison d’être. They succumbed to feature-bloat, rendering them either unusable or so complicated that people only utilized a small percentage of the functionality. Of course, most people didn’t know to ask for anything better, and given the market share these products had at the time, they didn’t have much of a choice anyway.
Years ago when I worked at Google, I remember conversations where the design team was dissuaded from making anything too polished or “designerly”. This urging seemed to stem from three motivations. First, there was a fear that getting to a high level of polish would take too long to develop and launch. Back in the day, that was more true than untrue, given how early and underdeveloped browser technology was. Second, there was a concern that by improving visual design, the product would be — and equally importantly — would appear to be slower. Lastly, there was also a sense of pride in the fact that Google didn’t want to appear to value beauty over functionality. By maintaining an austere aesthetic, like some kind of Amish tech movement, we could show ourselves to be more serious about power and functionality. We kept the Google homepage Doodles to ensure that we maintained a sense of levity and didn’t look like we were taking ourselves too seriously, but the product experience itself was to be kept as free as possible from what some might describe unnecessary ornamentation.
And people were so happy. Because compared to the other search engines at the time, Google worked SO MUCH BETTER. In fact, people who grew up after Google made its way into the world completely take for granted how high the bar is now for search experience, relative to where it was back in the late 90s. The clarity of purpose and reliability of the Google search engine (you come to a page, there’s only one thing you can do, and you type in what you are looking for, and the damn thing finds it almost every time!) was so amazing, so revolutionary, that for a time, people didn’t want more, or more precisely, they didn’t know what to ask for.
And then the iPhone came along. And we had to wrap our heads around something that solved real problems (minicomputer, camera and phone, all wrapped up in one device!), worked really well (way more intuitive than any other phone on the market at the time, by a long shot), and by God it was beautiful. Sexy. Delightful. Covetable. All of a sudden, the software we had been using, even the decent stuff, seemed, well, ugly. Soulless. Less than we all deserve. If Google Search tried to launch today with 1998 aesthetics, it would have a very different reception.
There has been a fundamental shift in people’s expectations of quality. We are now accustomed to a higher bar of craft and are transferring those expectations to other areas of software.
To be fair, the technology that we work with, which both empowers and constrains us, has improved a lot in the last two decades. The browsers and mobile phones of today provide a much more nuanced toolkit for designers and developers to play with. So we shouldn’t judge the interfaces of 15 years ago by what we are able and expected to create today. At the same time, we are at a crossroads for the next phase of digital product design. How do we meet and exceed the expectations people are starting to have for quality software in all aspects of their lives? How do we get software fully past the age of ugly into the age of delight?
We must invest in higher quality design systems and standards for visual design. Efforts like Google’s Material Design show that companies can prioritize the value of beauty in software design. We must partner with our engineering colleagues to ensure that we make the fit and finish of interfaces something that can be done reasonably fast so it doesn’t fall on the editing floor. And we must understand that beauty is going to mean different things to different people, depending on the problems a given product is looking to address.
In the industry I am currently focused on, the design of business software, standards for quality and beauty are particularly low, and the cost of not attending to craft can be very high. Beyond lost productivity, if products look “janky” — our industry’s favorite term for poorly crafted — then perhaps our customers might start doubting the validity of our data or the reliability of our back end systems. We want the craft of what we do to reinforce a sense of quality; that the product is well made, is reliable, and can be trusted. Like a profound essay littered with typos, poor craftsmanship can erode confidence in the quality of the ideas, even though in reality those things can be quite separate.
Ultimately, we need to put our products in service of people, and not just in a functional way. We need to surprise and delight them with the small details that show that we really care. If we work to make what we build valuable, usable and beautiful, we can create a virtuous cycle of raised expectations.
This is what the architectural designs of TamAssociati are trying to teach us: that beauty is the first message we give the people for whom we are designing: they are our equals, and we care deeply about their experience.
Design icon Paul Rand once said, “The public is more familiar with bad design than good design. It is, in effect, conditioned to prefer bad design, because that is what it lives with.” It’s audacious to claim we are going to prove Paul Rand wrong, but let’s give it a go, shall we?
Originally published at www.fountly.com.
Thanks to http://magdeleine.co/ for the lovely cover photo.
