Photo: I actually got my daughter to pose a kiss with me! It seemed I needed a real KISS in this article somewhere
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 principal 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!
Who’s to Blame?
When talking about websites there are two obvious sources for this propensity to make the simple complicated: 1) the developer and 2) the client (the person or persons running the organization that 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 to how websites become more complicated than they have to be:
- An inexperienced developer who simply 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 practice, be hard to follow and could potentially introduce complexities to future development. In WordPress we see this a lot as more junior developers (or non-coders) load up websites with many plugins trying to achieve a desired outcome. So instead of 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 client that tries to automate workflows by introducing third-party APIs, complex membership or customer models, unique 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 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.
Common Sources of Complexity
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 MailChimp or other email service.
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 in the case of many businesses they violate the KISS principle and in turn cost their site owners much frustration and unexpected costs. But why, if they are such good ideas are they such bad ideas in practice?
Third-party connections or “APIs” provided by services like social media services or blast email providers 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 you 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 will be supported long term or any level of connectivity. Sure the big guys out there have some great (big) reliable systems but you need consider this third-party reliance when making the choice 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 times we will receive requests to build some kind of automation whereby contact forms are entered into a CRM such as Salesforce, emails 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 then 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 every once and while. Compounding the general waste of time (I’m sure the developer billed, so maybe it is waste of money), the client then is faced with unexpected frustration when things break down and additional expenses are required to support these complex integrations.
With WordPress, for example, there are simple plugins that will do a lot of this and those are fine and may even meet the criteria of the KISS principle, however I still suggest that any kind of automation and third-party connection be carefully thought over. 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 the comes form seeing a business grow versus guessing about how things might work in the future.
Unique User Models
An area we often see the KISS principle trampled upon is in 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 figurative gears that have to turn to make a membership site work for all the users and administrators.
Payments have to be collected, expired members have to be contacted, denied credit card renewals must be dealt with, trials must be turned into paid memberships, email notices must go out for many of these steps. I can say from experience that memberships sites in particular seem to fall victim to “spaghetti code” even when built by seasoned web developers. Why? Because there are so many variables to cover when you develop a membership site that they all are rarely covered in the original development specs and code must be added on top of code. Rarely are the original plans still in effect a year after launch because real world use will undoubtedly reveal even more scenarios that were not covered in the original build.
There are certainly business and website models that justify some of these features 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.
Unique eEcommerce Setups
We don’t work on a lot of ecommerce sites at FatLab Web Support. I personally don’t like supporting ecommerce sites for reason that their processes are so critical: If money is not moving we have a problem. However I have certainly worked on my fair share of eccomerce sites over the years.
The goal to be like Macy’s or Amazon needs to be thrown right out the window from the start by most companies. Unless you have their resources, they are not your overall models. 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. However these are incredibly complex systems with million dollar infrastructures behind them.
Probably the biggest offender of the KISS principal are small ecommerce shops that try and replicate some of the features seen on such 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 make things simpler for the customer or administrator).
If you are starting new eccomerce site I highly encourage your to consider your most simple shop model. If you only offer t-shirts, for example, it’s OK to make each color it’s own product and not make 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 zipcode or limit the variables of each product and avoid customization.
Ecommerce is actually expensive. Many of the my clients have been surprised by the overall cost of upkeep on these sites. Often sharing their frustration of 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.
WordPress for example has WooCommerce, which is an awesome set of plugins and does in fact make a lot of ecommerce setup easier, but many of plugins are paid and require annual subscriptions, the credit card companies will certainly take their share and your merchant account will most likely charge you a transaction fee for each and every sale. Solutions like Stripe exist and simplify some of this but it’s not free.
One way to accomplish KISS with ecommerce 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.
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 if I were in charge, the web would be black/white and Arial. 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 and in particular page load time. Also the simple ability to add new sections or pages to a site that seems to have had each and every page uniquely designed. 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 practice. Most of the clients we work with are looking to get a 2 to 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.
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 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 2 to 5 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. 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.
Why Did I Write an Article About Development When Website Support is My Focus?
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 and 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, how to get a membership site working after a server/software upgrade reveals that certain features are not compatible or how to make 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 they have come to expect, are too ingrained in operations to remove, bad website performance and/or poor user experience. Many of them are surprised by the ongoing costs of maintenance and support 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.