Why SitePoint Lost Against Incremental Evil

“All that is necessary for the triumph of evil is that good men do nothing.” — Edmund Burke

As a codebase ages, its Software Brittleness increases, making it more difficult and expensive to adapt to changing market conditions, add new features and fix bugs. At some point, the ROI for almost any change can be negative, leading to a product that can no longer keep up with its market changes. This is its local optimum.

Some systems may get stuck in a rut that requires enormous effort to overcome the initial slump before reaching new heights.

To achieve the global optimum (here meaning best viable product possible), the cost of implementing new features needs to come way down. This can be done by reducing the codebase’s brittleness and inversely increasing its malleability.

One way to get there is by re-writing the system from scratch. And that’s exactly what SitePoint did in 2013: they overhauled the entire website and made not an evolutionary change to their product, but a revolutionary one.

The SitePoint Redesign

Here is a before-and-after shot of SitePoint’s article design from their big announcement post:

It’s easy to see that the old design was stuck in a local optimum and getting from the “before” design to the “after” design would have required the following hurdles to be overcome:

  • Convince the Social Media team to get rid of the Like / Share / Tweet / Email buttons
  • Convince the CEO to make the logo smaller (see: Make The Logo Bigger Cream)
  • Convince the Bookstore Department to remove the “NEW SITEPOINT BOOK. Read Chapter 1 FREE!” ad
  • Convince the SEO team to remove the bright red category links

Since requesting any of these things would generally be met with furrowed brows and rejection, the designers were able to avoid the problem by starting from scratch.

The final writeup says the redesign allowed them to:

  1. Focus the user experience towards the actual article content
  2. Be stylish and sleek
  3. Implement responsive design
  4. Improve site search
  5. Improve page load time
  6. Increase discoverability
  7. Engage in a two-way conversation

These were all admirable features, and the redesign came out quite nice. It had a clear focus on the content and removed distractions. It cleaned up the colour palette and made the UI simpler. It made the pages load faster and the search deliver better results. But there’s one thing it didn’t do: it didn’t stay nice.

“For The Leaves, They Will Wither”

SitePoint has not had a major redesign since then. However, their once clean-and-performant website has devolved into a mess of ads, anti-patterns, bloat, privacy invasion and content obscuring.

Here’s what a user sees when visiting that same page today:

Wow. Take that UI in for a moment. Think of how much it really meets its original goals. Ask yourself:

  • Does this UI focus on the article content?
  • Is this stylish and sleek?
  • Does the page load the main content as fast as possible?

Upon first glance, the answer to all of these questions is no. Here’s an annotated version of what the user gets to experience now:

All the sections highlighted in red are the parts of the UI actively pulling the user’s attention away from the actual content, highlighted in green. That’s an astounding signal-to-noise ratio, and is made worse by the other dark patterns at play:

  • Instantly asking for push notifications permission
  • Obscuring the article with a darkening screen and cold-pushing the ebook (with the mandatory surrender of personal email data)
  • Having a bright-red, full-width banner at the top of the screen (that sticks there when the user scrolls down)
  • Adding a countdown timer that can flicker in the user’s peripheral vision every time the seconds counter ticks down
  • Informing the user that if they click anywhere in the page, they’ll opt-in to cross-site ad tracking
  • Having three sidebar advertisements visible above-the-fold

This user experience when taken as a whole is objectively bad. But clearly nobody set out to turn SitePoint into that mess — it devolved over time, degrading the UX not all at once, but getting slightly worse, bit-by-bit. The term for this is Incremental Evil.

How Incremental Evil Takes Hold

These dark patterns, ads and distractions tend to get added one at a time, usually under the guise of minor conversion improvements, or to coincide with other promotions.

For example, when the ebook was released, the SitePoint marketing team probably asked to add the email nag modal (or even circumvented the ownership of the product and did it themselves using some injectable digital marketing system). With no real evidence for rebuttal, the developers were forced to accept the addition. One single modal was no big deal, right?

Then later, one of the higher-ups hears that many browsers allow sites to send push notifications right onto the users’ device — a lucrative marketing vector too good to pass up. So, the developers add the push notification prompt. Sure, it’s annoying. Sure, it adds another thing standing between the user and the content they came to see, but it’s still just a minor thing, right?

Even later, the SEO team wants to try an optimisation experiment to see if users want to find related tutorials by topic. Thus, once again, the developers are asked re-implement the big list of category links that were so boldly removed in the redesign. They do it anyway because the SEO budget is very large and it’s really just one small thing, right?

Defending Against Incremental Evil

As the old saying goes, the water heats imperceptibly until the frog boils to death. In SitePoint’s case, it was the usability, simplicity and performance of the UI that was slowly eroded until site visitors were treated to an all-out assault on their attention, bandwidth and tolerance.

But why did this happen to SitePoint, and why do so many other software products experience this quality rot? I think the answer lies in the incremental nature of these changes and the lack of fundamental strategic principles.

If SitePoint’s designers and developers had a set of fundamental strategic principles, they could have been more effective user champions in the face of well-meaning but incrementally-evil changes.

I submit that a user champion need not be a person, but perhaps a written document. Such a document could define (in whatever detail) the framework and ground rules that a project or system must adhere to. With the right authority, such a document could assist in the prevention of quality rot and ensure that great products stay great.

A written artefact that underscores the fundamental guiding principles of a system, product or project can take many forms. There are several recognisable analogs throughout the history of society and business.


For centuries, nation states would write a Constitution; a document outlining the rights and rules by which all of its citizens must abide. The contents of these documents could be purposefully high-level and concerned with holistic governing practices, usually concerning citizenship, liberty and justice.

This mandated that legislators write laws which fell within the legal boundaries set out within the supreme authority of the higher-ruling constitution. Any single actor (such as a malevolent local governing body) who attempted to pass through legislation that would erode the rights of the citizenry would find that their laws were unconstitutional and would therefore be unenforced.

Thus, the constitution was the written artefact that functioned as a written user champion, surviving successive governments and social revolutions to protect the citizenship and keep the nation aligned with its ideals.

User Stories

In Agile software development, a user story is a tool used “to capture a description of a software feature from an end-user perspective. The user story describes the type of user, what they want and why”.

The rest of a feature’s requirements and subsequent implementation are subject to the fulfilment of the original user story’s expectations. No matter what is built, if it doesn’t meet the expectations of the user story’s hypothetical persona, the work must not pass QA.

Performance Budgets

The digital design and UX movements are slowly coming around to the idea that performant, responsive interfaces are a worthwhile UX endeavour[15]. Some even go so far to say performance is a feature. Some case studies show a financial benefit to increasing the speed of webpage load times[17].

Instituting a performance budget for a cloud product will force web designers and developers to consider the bandwidth, latency and operational performance of their product. This manifests itself in things like compressed assets, reducing download and parse times, minimising the use of font faces and ensuring the UI is never blocked by some expensive task.

All these things together ensure the user is delighted with their experience using the product, in addition to the features of the product itself.


There is a great case study to be found in SitePoint’s relapse of quality rot. If you notice a product, system or interface being slowly degraded by ads, dark patterns or other stepwise degradations, communicate your frustrations to the vendor. Ensure that products you or your colleagues are building may not fall victim to incremental evil, and always advocate for the customer — they’re the ones who matter the most.

For more information about what should go into a user-champion document, keep an eye out for Part 2 of this post; coming soon.

How Usable Is Your Brand Name?

Imagine you’ve got a flight to catch in an hour.

You jump in a taxi and say “take me to JFK.” The driver approves with a nod and 40 minutes later he pulls into the parking lot of what appears to be an industrial estate instead of an airport.

With only twenty minutes until takeoff, you read the sign on the factory facade with dread:

Jaffa Cakes Factory

“No, I said JFK, not Jaffa Cake. We’re supposed to be at the airport!”

Your shoulders drop. It’s too late now to get there on time; and the non-refundable ticket in your wallet now serves as a costly reminder of the price of miscommunication.

Natural Language Errors in Aural UI Systems

Most people in that situation would probably blame the taxi driver for incorrectly interpreting your command and causing you to miss the flight.

These kinds of errors would appear to be incompatible with successful business dealings. However, as technology-savvy folk will testify, this can actually be a common occurrence, like asking Siri “take me to Tumblr” but ending up at “tumbler.com”.

Without being told that ‘Tumblr’ is a real word, Siri goes with the most reasonable match in her dictionary – how was she to know it wasn’t what the user was really looking for?

Unlike the taxi driver analogy, it seems the burden of disambiguating the query is placed upon us, the users. This flies in the face of the goals of natural language processing systems: the user shouldn’t have to think about how to phrase what they want, they need only ask naturally.

It’s Not Our Fault

If we want to go to the website for Tumblr (or Flickr, or Svbtle) somehow we must determine how to phrase our queries, lest we get led off to somewhere else.

So do we spell out the brand name, letter by letter? Or perhaps say it phonetically, altering the original pronunciation into some grotesque malformation of its original self?

See if you can phonetically pronounce the following brand names, and think about what it would take to get a computer to recognize them:

When the only way to begin interacting with a brand is to speak their name into a microphone, it better be simple enough to parse correctly by natural language processing systems.

All the usability testing in the world won’t mean a thing if users can’t even access the website.

Choose A Usable Brand Name

Now that the UX community has recognised the concerns of designing great URLs, let’s continue to make our customers’ lives easier. Instead of forcing them to jump through hoops to engage with your brand, make it easy. Here’s how:


Pick One Standard Spelling

If 50% of your users are searching Google for CodeAcademy and the other half are (correctly) searching CodeCademy, then you know you’ve got a problem.

Aside from having to buy two domain names to catch the incorrect spellings, you’re fragmenting your audience into two separate crowds, one of which will be incorrect forever.

Beware Of International Differences

Users from Australia, New Zealand, the UK and Canada would all instinctively navigate to Technicolour.com. While only one letter different from the actual brand name, the results can be disastrous:

Usable brand names don't suffer from geo-cultural differences, like the strictly American spelling of 'Technicolor'
Usable brand names don’t suffer from geo-cultural differences, like the strictly American spelling of ‘Technicolor’

Don’t Be ‘Clever’

While Flickr and Tumblr are seen as hip and trendy brand names now, it’s easy to see how problematic it will be to interact with them via aural UI systems in the long term. Be sure to pick a name that both people and machines can assume the spelling.

Just like how all men named Sean have to introduce themselves as ‘my name’s Sean; that’s S-E-A-N, not S-H-A-U-N,’ you don’t want to have to introduce your company, then immediately append its spelling to your sentence.


A usable brand name is one that people can find and recognise, however they come across it.

Only Use Standard Characters

Until Unicode URLs become a thing, URLs are limited to 26 Latin letter symbols, ten numbers and some other silly things like dashes.

If you use anything other than these characters, your location on the internet will essentially be different to your name. That hurts both your credibility and discoverability.

If you have to drop the accents from your letters to fit in a standard ASCII URL, you don’t have a usable brand name. Additionally, suppose a user copies your name (special characters and all) into their browser and adding ‘.com’ to it, guess what’s going to happen?

Using special characters in your brand name can lead to bad things in your URL
Using special characters in your brand name can lead to bad things in your URL

Don’t Require Dashes

The best brands are simple and unambiguous. If you’re fighting a war against URL readability (businessshop.com vs business-shop.com) then adding a dash in your web location might seem like an easy fix.

Experts Exchange did this, but it hasn’t stemmed the mocking.

Additionally, just like having to spell your name out, necessitating the pronunciation of ‘dash’ in he middle of your brand name instantly destroys its flow.

Consider the difference between ‘A 1 dot com’ and ‘A dash one dot com.’ No longer are you a proper brand, you’ve just relinquished yourselves to the likes of ‘face-book.com’ and ‘cheap-guitars.net.’

Not to mention, a dash in your URL might get you penalised on Google.

Add these three things together and it would appear that needing a dash in your URL is a symptom of a less-than-usable brand name, and something should probably be done about it.

Summary: What Is A Usable Brand Name?

Usable brand names are strong, unique and memorable.

  • They are easily pronounceable and are spelled just they way you think they are.
  • They have no special characters or awkward spelling, and follow basic language rules that are consistent around the globe.
  • They aren’t chosen just because the ‘normally-spelled’ URL was already taken.
  • They are timeless and aren’t following a trend.

If you can meet these criteria, your brand will be accessible to all users, regardless of how they connect to you.