Why is building a website so hard?

I’ve been working in technology startups for several years now and I’ve been up close and personal with what it takes to get something designed, built and onto the internet.

During the consulting parts of my career, I helped build plenty websites for clients. But it’s a whole different ball-game when you are in-house and personally responsible for whether or not the site is delivering results. I’ve found that as soon as you’re responsible for the actual business results, your whole mindset towards building digital products changes. For example, I’ve found that all of a sudden usability and simplicity become more important than how things look for their own sake.

I’ve always been fascinated by how things that seem like a nice easy website project can gradually become complex, stressful and expensive. It’s not just the normal “things take longer than you’d expect” effect from all types of project management. Something more profound is going on when building digital products. There are several interesting issues that cause website projects to be harder than you’d expect:

1. Unknowable scope

You never really know in advance what it is that you actually need a website to do. Even the best planning, user experience mapping and project scoping won’t capture all the possible things that users may want to do on your site or all the features that you may want to put in front of your users. In the world of construction and engineering they have a concept called a “change order” these are supposed to track changes to the scope of a project, but in software development, it’s possible that the scope isn’t even known in the first place.

These gremlins usually take the form of functional requirements. For example: “We always needed the system to capture mobile phone numbers as well as email address. It’s always been that way.”

Mitigation: Taking an iterative approach based on lean startup, agile development and design thinking can help bite off small chucks to work on. The key is to not go too far down any given path and get attached to a particular solution.

Code

2. Hidden dead-ends

A dead-end gremlin is when you get 90% of the way down the path with implementing a part of a system, only to find that there is an absolute block based on a requirement that the tool or module can’t deliver. Often these gremlins show up as hidden internal systems that depend on each other to do something seemingly simple like send an automated email.

Email marketing and payment processing are the worst areas for dead-ends because everything sounds simple from the outside, but the reality of actually making it work can be very hard with multiple systems depending on each other.

These gremlins usually take the form of hidden software dependencies. For example, “Our billing software needs a physical address and the rapid prototype e-commerce tool doesn’t capture addresses in the default forms.”

Mitigation: Being as clear as possible about the mandatory requirements in advance can help, but the best solution is to find ways to prototype the idea so that you can test whether everything hangs together properly.

3. A beautiful unique snowflake

In the world of marketing and branding, it’s tempting to want to make everything unique, different and beautiful. This is a great way to create a unique brand, but it can be a terrible way to create a website. Good web design prioritises functionality and effectiveness over looks. The founder of Trademe Sam Morgan told a great story at one of the early Better by Design conferences about functionality and unspoken ‘standards’ in web deisgn…

Ford Model T Dash

Before the 1940s, every car dashboard looked different and had different levers, dials and displays all over the place. After the 1940s, almost every dashboard from every manufacturer conformed to the same basic layout with a speedometer, rev counter and fuel gauge, which meant that any driver could drive any car without having to relearn everything from scratch. The basic design interface has pretty much stayed the same ever since because usability is more important than uniqueness. Even modern cars with digital screens often use the same basic speedo, rev counter and fuel gauge layout.

Ford Deluxe DashStandardisation makes everything simpler for the end-user. The same is true in web design. We expect links to be blue and underlined, the scroll bar to be on the right, and the menu to be on the top (or maybe the left-hand side). Websites that break the basic navigation conventions just to be different are making the medium more important than the message. It’s nice to be unique, but it’s better to be effective.

These gremlins often show up as a ‘wild idea’ from a non-designer wanting to make something ‘out there’.

Mitigation: Using standard web development frameworks and content platforms can help make sure that a website is consistent and easy to use.

4. Testing and compatibility

Every website project that I’ve worked on started with great promises about compatibility and great intentions to test everything. In practice, too many websites don’t work on mobile phones or the wide range of web browsers that are out there in the real world. Personally, I’m a fan of minimalism in web design. The less distracting fonts, animation and noise there is, then the more that the content can shine through. Ironically enough, simple and minimal design is also more likely to work on a wide range of devices and browsers.

These gremlins show up as pages that kind of work on your phone but not really. The worst offenders are usually large tables of data that mean you have to scroll across, as well as down, to see everything.

Mitigation: Make designs and code as simple as possible and don’t assume that every single person in the world uses Chrome on a desktop. These days I usually design the mobile view first for each page because forces me to focus on what matters most.