KISS: Keep It Simple Stupid
I’m sure you’ve heard the term, “Keep It Stupid Simple.” I had to look up where it actually came from.
It’s a design principle noted by the U.S. Navy in 1960, and it basically stated that most systems work best if they are made to be simple rather than complicated. Seems like good enough advice, right?
Well, as a web developer and especially one that specializes in website support (i.e., I am working on sites I didn’t build), I can tell you that it seems to be human nature to do the exact opposite. We like to complicate the hell out of things!
KISS Web Development, Who’s to Blame?
When talking about KISS web development, there are two obvious sources for the propensity to make the simple complicated:
- The developer
- The client (the person or persons running the organization the website belongs to).
I’m going to argue that web developers don’t make things complicated because we want to, but instead, I see two very common reasons for how websites become more complicated than they have to be:
1. An Inexperienced Web Developer
An inexperienced developer who coded the site or feature the long/hard way because they didn’t know any better.
In code, this means a function that can be done in a few lines might be done in many lines, not follow best practices, be hard to follow, and could potentially introduce complexities to future development.
The Inexperienced Web Developer and WordPress
WordPress sees this a lot as more junior developers (or non-coders) load up websites with too many plugins trying to achieve the desired features requested.
So instead of working with the source code and writing a custom feature, the site might have many plugins that all must remain compatible in order for the site to work as desired; administration of such a site might be harder than usual and long-term maintenance might be tougher or more expensive.
The use of a lot of plugins certainly does not apply the KISS principle.
2. A Website Client that Tries to Automate Everything
The client tries to automate workflows by introducing third-party APIs, complex membership or customer models, unique e-commerce solutions, etc.
It’s this second point I want to talk about here because it is the most easily avoidable.
Now I’m not berating web developers and application developers for doing as they are told. In fact, in our website support business, our unofficial model is “just do as you’re told”.
I am also not down on any website owner for wanting to make their business run smoother through automation or trying to make their service or product unique.
I’m simply pointing out a few places the KISS principle can be used effectively and asking developers and website owners alike to think about the complexities they might be introducing in an attempt to simplify before it is too late.
Technical Automation Can Break KISS in Web Development
This is where we see the KISS principle broken the most. The scenario is almost always the same.
The website owner wants to automate part of their workflow, and who could blame them for thinking that technology could answer this need? Common examples that we see include:
- Every blog post should automatically post to Facebook and Twitter.
- Social media posts should automatically appear on the website.
- When a user fills out a form, they should be entered into the CRM and/or newsletter system.
- People should be able to sign up to receive automatic blog alerts
- When a user joins a membership site, an invoice should be sent if they opt not to pay online.
- When a user changes their email on a website, it should automatically be updated in all databases that maintain the record.
I could go on and on, but you get the idea of the kind of things we see often.
There is nothing wrong with these requests at all. I, however, am going to argue that many businesses violate the KISS principle and, in turn, cost their site owners much frustration and unexpected costs.
But why are they such bad ideas in practice if they are such good ideas?
Third-Party Connections
Third-party connections or “APIs” provided by services like social media services, CRM systems, or marketing platforms are awesome. However, they go down, get upgraded, and get depreciated.
When you connect your site to a third party via their API, you are now relying on a third party to maintain a potentially critical part of your business.
The catch is that they will accept this responsibility (with your API connection) but will make no promises or warranties that things will work the same in the future; the API may not be supported long-term or guarantee any level of connectivity.
Sure, the big guys out there have some great (big) reliable systems, but you need to consider this third-party reliance when choosing to connect your site to a third party.
Are you willing to accept the cost if the API provider changes their API so that old methods no longer work? Do you have the bandwidth, expertise, and/or budget to research any issues that arise and correct the issue if, for example, an API outage left you with un-synced records?
Does Your Transactional Volume Justify Automation?
Often, we will receive requests to build some automation whereby contact forms are entered into a CRM such as Salesforce/Pardot, email forms are entered into a MailChimp email list, or other data is passed back and forth between the website and a third-party service.
It sounds easy enough, but I think the reasonable question is, “do I have enough volume to justify the automation?”.
In other words, does the automation actually improve workflow, or are you automating stuff because you can?
Sites that receive low traffic, low email signups, and/or low sales contacts might be better off simply collecting the information and having an administrator manually take the next step.
We have seen this a lot, whereby a web developer spends hours developing an API connection or other form of automation when the reality is that it is required only once in and while.
Compounding the general waste of time (I’m sure the developer billed, so maybe it is a waste of money), the client is faced with unexpected frustration when things break down. Additional expenses are required to support these complex integrations.
Avoid Automation for the Sake of Automation
Avoid automation for the sake of automation and build to the current volume; if the site has low traffic, go ahead and keep things simple today, you can always revisit this when traffic levels are up.
Who knows, you may approach it completely different with the intelligence that comes from seeing a business grow versus guessing how things might work.
Unique User and Membership Models
Another area we often see the KISS principle trampled upon is membership sites.
Membership is a complex business or website model, especially when you bring paid memberships into the picture, offer trial memberships, and offer multiple “levels” of membership.
There are a lot of figurative gears that have to turn to make a membership site work for all the users and administrators.
Payments, Denied Credit Cards, Renewals, Trials, Etc.
Payments must be collected, expired members must be contacted, denied credit card renewals must be dealt with, trials must be turned into paid memberships, and email notices must go out for many of these steps.
I can say from experience that membership sites, in particular, seem to fall victim to “spaghetti code” even when built by seasoned web developers.
Rarely are the original plans still in effect a year after launch because real-world use will reveal even more scenarios not covered in the original build.
Keep It Simple Stupid in Membership Websites
There are certainly business and web application models that justify some complex software development, but I urge you to keep your membership site as simple as possible from day one and add to it over time as real-world usage scenarios present themselves.
For example, maybe only offer one membership level upon launch, maybe only accept monthly or annual payments but not both, don’t give a pay-by-check/invoice option, and keep the actual offering as simple as possible while still providing your primary service.
In other words, keep things simple and straightforward from the start.
Unique eCommerce Setups
We don’t work on a lot of e-commerce sites at FatLab Web Support. I don’t like supporting e-commerce sites because their processes are so critical: If money is not moving, we have a problem. However, I have worked on my fair share of e-commerce sites over the years.
You are Not Amazon
The goal to be like Amazon needs to be thrown right out the window from the start by most companies. Amazon is not your overall model unless you have their resources (and you probably don’t).
I know Amazon, in particular, seems so simple: you can save multiple credit cards on file, maintain active subscriptions, store your preferred clothing sizes, have sub-accounts for family members, track shipments, etc.
These are incredibly complex systems with million-dollar infrastructures behind them.
You Can’t Replicate Million Dollar Systems without Millions of Dollars
One of the biggest offenders of the KISS principle is small e-commerce shops that try and replicate some of the features seen on much larger sites.
Their inventory might be small, web traffic might be light and overall sales in the thousands (not millions), yet their websites are also costing them thousands because they are striving to offer certain features that are adding complexity (even if the goal is to make things simpler for the customer or administrator).
Keep It Simple Stupid in eCommerce Websites
If you are starting a new e-commerce site, I highly encourage you to consider your most simple shop model.
If you only offer t-shirts, for example, it’s OK to make each color its own product and not make the color a variable of the t-shirt product (you know, with fancy rollovers, magnifiers, and automatic color changing of the model’s shirt with a click).
Look for additional ways to make things simple, offer flat rate shipping instead of calculating based on weight and zip code, or limit the variables of each product and avoid customization.
E-commerce is actually expensive. Many of my clients have been surprised by these sites’ overall cost of upkeep. Often sharing their frustration with the cost of the website versus the money they make from it.
If you go at it on your own (hire a developer, open a merchant account to accept credit cards, etc.), know that everyone gets paid along the way.
One way to accomplish KISS with e-commerce sites, especially for businesses that do not have a lot of money to invest in the original build and ongoing support, might be to go with services like Shopify, Squarespace, or Wix instead of trying to custom-build your own online store.
Website Design
This is the one that gets under our skin on a daily basis. Complex design for the sake of complex design, or so it seems to us.
I’m talking about eye candy run by many scripts that most certainly hurt the performance of the site and cause conflicts with other features.
We are not designers, and I often joke that the web would be black/white and Arial if I were in charge. A bit extreme, sure, but my point is that day in and day out, we work support for website owners that had overly complex designs built and are now struggling to maintain them.
The biggest complaint we see is about SEO rankings, particularly page load time. Also, the simple ability to add new sections or pages to a site seems to have uniquely designed each page.
The Latest Desing Craze is Not What You Want
The latest design craze is not for your business website, I promise. Like all fads, web design goes through short and long cycles where some things seem to come and go within a few months while others actually win their place among best practices.
Most of the clients we work with are looking to get a 5-year return from their website development investment – meaning they don’t want to even think about redesigning their site for several years after launch.
Keep It Simple Stupid in Web Design
How does a client avoid complexity in design and follow the KISS principle?
Just keep things simple, don’t pull features from cutting-edge sites that have the budget (and maybe an in-house design team) to be constantly working on their designs, who are, in fact, testing whether things work or don’t and by no means expect any one design feature to last five years.
Don’t make stuff move, float, slide, or shake (yes, I have seen stuff built to shake) unless it’s critical to the user’s experience (UX). Consider that each unique element comes with “weight,” which could be measured in future support, SEO performance, or the user’s experience. As boring as it sounds, if you expect your site to last you several years, keep things as simple as possible.
Long-Term Website Support and the KISS Principle
Because I am the guy who ends up supporting these sites, and there are many developers out there like me. We come after the excitement of doing something new has worn off.
We have to figure out why things aren’t working, how to get a feature or function to work after an API has been upgraded or depreciated, and how to get a membership site working after a server/software upgrade reveals that certain features are not compatible or how to make the site load fast despite the many files required to get all the eye candy to work.
Honestly, it’s about the website owner’s experience. As a website support-focused business, we talk to a lot of website owners (website development clients) who are frustrated with various features that have caused nothing but headaches.
Many of them are surprised by the ongoing maintenance and support costs and didn’t figure it into their original plans.
If only they had followed the KISS principle from the start, if only their developers and designers encouraged them to Keep It Simple Stupid.
