Embracing simplicity
I had the honour of speaking at Enhanceconf 2016 — a conference dedicated to Progressive Enhancement. It was a pleasure speaking about a subject close to my heart and I was really chuffed with peoples feedback. Here are my slides and below is the video along with the transcript:
I want to start by using our imagination.
I want you to imagine your life with less.
Less tooling. Less libraries. Less frameworks. Less debugging. Less noise. Less debates.
Less bullshit.
The kind of bullshit Brad Frost talks about. Less of the superfluous. Less of the unnecessary. Less of the unnecessarily complex.
All of this while browsers get better and connections get faster, with no effort on your part whatsoever.
What you might be imagining is a more straightforward tech stack, particularly on the front-end side. And maybe a better experience — one that embraces the web and its conventions, rather than one that tries to trample all over it or enhance it too much.
With all of this complexity out of the way we would be able to focus on the basics which might just make the biggest difference to our product and make our lives as designers and developers a little easier too.
I’ve always been obsessed with simplicity, I think as designers and developers we have simplicity somewhat baked into us. We just need to unlock it.
One early memory I have of this was when I was 15 or 16 years old revising for my maths GCSE.
When it was time to revise I would find the quietest place in our house which was our dining room. We had this large dining table — it could seat 10 or so people.
I would go in there with just my essentials: my calculator, pencil case and mock exam paper. Even though I only needed a small part of this table, I would declutter the physical space so that I could declutter my mental space.
Today, this is what my desktop looks like…
Clutter free. I am an Alfred keystroke away from my favourite application.
And, this is what my home screen looks like…
Clutter free again, and my most used apps in close proximity to my thumb.
And when I am at work, I meticulously close down program after program after I have finished using it which gives me two benefits on the same theme. The first is that I only have open what I need allowing me to focus. The second is that the computer works better when it’s doing less.
So when we’re both doing less, we both work better.
Now, web design and development is hard. How can we make it simpler for ourselves and for our users?
It’s true that simple is complicated but sometimes simple is simple.
And it’s this latter variety of simple that I want to focus on today because I think that’s what we’re missing. I think there is a huge opportunity to do the simple things and get big results.
Now, you might be wondering about what all this has to do with Progressive Enhancement?
Well, Progressive Enhancement revolves around people. People consuming an experience or people designing and building an experience to be consumed. And if there is one thing I know about people it’s that we love complicated.
We hone in on complicated and skip the basics and I recently came across a story with the same theme that I want to share with you…
This is Atul Gawande. He is the professor of surgery at Harvard Medical School.
The World Health Organisation asked him to help reduce the number of deaths during surgery.
Did we need more training or more technology?
Gawande found they were looking in the wrong place.
He talked to experts in other high-risk professions, such as aviation.
What he discovered was that there are usually three main problems.
1) Problems of ignorance;
2) Problems of technology;
3) Problems of ineptitude.
All surgical attention had been focused on the first two.
They had solved the problem of ignorance: the average surgeon now had ten to 15 years of training.
They had solved the problem of technology: surgeons performed up to 4,000 different procedures and prescribed up to 6,000 drugs.
But, unlike the aviation industry, they had ignored the third problem.
The problem that highly skilled people often make basic mistakes.
In the airline industry, this was covered by checklists.
Before any pilot takes off, he and his co-pilot run through a checklist.
“Brakes — set. Autopilot — disconnected. Fuel level — set”
Double-checking the absolute basics don’t get overlooked.
Gawande recommended checklists before surgical procedures.
Reading aloud and checking off the basics:
“Patient’s identity. Name and area for procedure. Known allergies”
At first, surgical staff resisted because it felt demeaning.
But then the results came in.
At the end of the trial, death rates across the hospitals tested had fallen by 47 per cent.
If they had seen that result from any drug or technology, it would have been hailed as a miracle cure.
But, here, the result came by checking the most basic things.
Because the basics were actually the most important of all.
It’s a normal human reaction to forget the importance of getting the basic things right.
Human beings get seduced by complexity.
Which is exactly what’s happening in our industry. We’re so hypnotised by complexity, we forget the basics.
We’re so busy worrying about the Javascript this, the framework that, the AJAX, the carousel etc.
We’re often just rebuilding the same thing we did last year, this year in a new technology or architecture, and I am not sure this is adding value.
Now, there are many reasons we do complicated. I want to share two interesting ones with you today.
The first reason is contribution. We feel that if we put a lot of effort in, then we get a lot of value out but this is often not the case.
And to demonstrate, I want to share with you a portion of an article I read recently by my friend Mark Jenkins, a designer here in London. It’s entitled “Contribution” and it’s a tale of two designers — Designer A and Designer B.
Designer A spends an hour of their time making 5 screens because they know they need to design 5 screens. They’re not trying to change the world, they achieve what they set out to do.
Designer B takes an entire day to make one screen because they are obsessed with moving pixels, but they are stuck. They can’t let go.
They end up doing less because of their own insecurities about their contribution.
They create the same thing over and over, they end up with unfinished design(s) or they go right back to the beginning.
Designer A understands that there’s no ‘perfect’.
Designer B believes ‘perfection’ exists, their belief of perfect is jaded by their own inability to understand the solution to the problem. In some cases, they are making a solution for a non existent problem.
Designer A thinks (differently).
Designer B overthinks.
Designer A’s contribution is greater because they think about the necessary.
Designer B’s contribution is lower because they think about the unnecessary.
Designer B is a blocker. To themselves (and the rest of their team).
Designer B relies on what they know.
Designer A relies on what they don’t know.
Designer A releases early to learn.
Then goes back to improve.
Designer B releases late.
They learn less because they believe they have perfected something, without testing.
Designer A works with context.
Designer B has no context.
Designer A learns.
Designer B thinks they don’t have to learn.
Both A and B are designers. However, there is a HUGE difference between the two of them.
And I guess if I wanted to sum this up nicely for you it would be that value only has a value when it’s value is valued.
And in the case of enhancements, I am not so sure all the enhancements we go about adding are creating better experiences.
One example I have of this was when I was working on Boots.com back in 2008, in particular their checkout flow. It was designed as a single page checkout. It had all the enhancements including Accordions, AJAX, client-side validation, no page refreshes. As you go through each step the accordions would expand and collapse.
We put in so much effort upfront in order to design, build, test, release and finally user test. When we did, we found out that it didn’t work well at all. The effort we put in was far greater than the value we got out.
So we ended up reverting to the basics. Each accordion step became it’s own page with very few enhancements. And the results were extremely positive.
And as history repeats itself, almost 6 years later I was working at Just Eat. We had a single page checkout too and we were tasked with improving conversion within the checkout flow.
So we did the same thing. We put each step onto its own page. Each page had plenty of white-space. Each page had a page refresh. And there was a very clear single focus per page. There was a sprinkling of client-side form validation to save a server round-trip.
All of this resulted in almost 2 million extra orders per year. That’s orders, not revenue.
And this is what 2 million people look like.
Everyone benefited. The business and the users clearly benefited.
You could say that I became less marketable because my CV was far less “wow” — instead of “Built rich single page checkout with all the fancies”, it became “Built 4 web pages with a form on each”.
But it’s a little but like how the surgeons found it demeaning to do the most basic things and we saw what results they achieved. And afterall, it’s not about me or my CV, it’s about the results and the human being at the end of them.
Then comes technology…
Technology is easy to complicate. One very simple example of this is the use of Jekyll. For those unaware, Jekyll is a static website generator written in Ruby. It’s geared towards blogs so it basically produces a bunch of articles where each article is made of some simple HTML.
It’s great because it is just static, has no moving parts. No need for an application server and to note I use it myself.
The problem comes when we want to add dynamic content such as comments.
What I typically see is the use of Disqus, a Javascript library that asynchronously loads and injects comments in as an enhancement.
And of course this type of enhancement has many failure points and when it does fail there are no comments. Now, you could say that this is an acceptable degradation point in that at least everyone gets the article.
But if you think about it, comments can be really valuable and a comment is just text like the article itself. So ultimately this type of enhancement is completely unnecessary and detrimental to the user experience.
So why do we do this?
We do this because it makes our lives as developers easier — it’s so easy to throw a piece of Javascript at it.
But ultimately we have put our needs before the needs of the user which as Jeremy Keith says…
If I had to choose between making something my problem and making something the users problem, I would make it mine every time.
And this for me is bang on.
So what can we do with just the basics?
Well I have already alluded to this somewhat with the Boots and Just Eat case studies. But I am thinking about text, links, forms, pages, headings, paragraphs etc.
And if we hone in on just text for a moment…
Is the copy legible? Are we choosing the right font? The right font-size, letter spacing, line height? Are we humanising our copy, making it appropriate for the audience? Have we got too much or too little text? Are we showing it at the right time.
You see, there is so much to explore with just the basics.
I am also thinking mobile first, which to me just means small screen first, which to me just really means essential first, which to me just really really means essential only.
And this has been a real boon for the industry because it has forced us to cater for small screens and picking what is truly essential to the experience which scales up easily to big screens.
We must stop fearing the page refresh and stop fearing white space.
When we trim the fat for all, and when we build these things in the right way the page refresh, something we have always had, goes unnoticed and can be responsible for some amazingly simple experiences.
And I am not saying that we should oversimplify, nor that there isn’t a place for complicated. But if “ten” is complicated, and “one” is simple, we spend way to much time near the ten mark and I think we need to bring it closer to one at least by default.
With regards to Progressive Enhancement…
Progressive Enhancement is not a prescription to enhance. It’s a wonderful strategy should we determine that an enhancement is going to add value. We don’t actually have to enhance — we can choose not to.
So how might we get this into our everyday processes?
We all know the benefits of iterative development and user-testing and I think Progressive Enhancement lends itself perfectly to this.
I suggest we design and develop the core experience. Then release and test with users. At this point, you might find that this core experience is all that is needed. Great — move on to the next feature.
If it doesn’t work well enough the we can iterate. I suggest we practice thoughtful reduction rather than mindless addition by exploring the basics a little deeper. If that works — great.
If this still doesn’t work you have my permission to enhance.
But the great thing here is that you have delivered little and often, learnt little often which is great for team morale and momentum. And of course we know along the way that our effort is adding value in terms of team knowledge and product user experience.
It is also great because it can reduce the emotional attachment we are prone to. As designers and developers if we put a lot of upfront effort in then we get more attached to our work. If we let the results do the talking then we remove this problem which again is great for morale and momentum.
And small steps can result in small wins, and small wins are worth celebrating.
But small steps can result in big wins, which are again well worth celebrating.
Ultimately, this is what I want for us, this is what I want for the industry, and this is what I want for our users.
It was a pleasure to speak and share my knowledge and experiences alongside the others who were there: Nat Buckley, Anna Debenham, Stefan Tilkov, Forbes Lindesay, Oliver Joseph Ash, Stu Cox, Phil Hawksworth, Stephen Waller, Jen Simmons, Robin Christopherson, Stephanie Morillo, Aaron Gustafson and Jeremy Keith.
Finally I want to thank Simon McManus for inviting me to talk and a brilliantly organised conference — thank you!
If you enjoyed this, please hit the ♥ button to help spread the word.
