Beware of the hidden costs of complexity
The more unknown unknowns there are in a design brief or system requirements, the more time is required to understand the core problems in order to design a suitable solution.
Simple problems tend to have simple solutions. And, if you’re working with an experienced designer or developer, it’s likely something they have dealt with before, so it’s straightforward to implement.
I have worked with many founders who have great products, a great story, and a strong mission and purpose.
They have all the ingredients for success.
They get derailed because they have big ideas for how it should all work and strong opinions on the implementation of these ideas—without fully understanding what’s simple and what’s not.
I am a minimalist and a pragmatist by nature and I love the beauty in simplicity—whether a simple design or a simple system. Simple doesn’t have to be basic; intentional minimalism and simplicity might take more work upfront than over-designing or over-engineering. But there is ultimately less technical debt and less headspace cost—and likely less time and money spent—in the long term.
There’s a difference between complicated and complex, and it’s important to ponder this distinction in the context of how your business operates, how you manage your team, and the features and functionality of your website.
Complicated problems take work and effort and time to figure out, but the formulas are well known and the path well trodden. It might take time, but there are few unknown unknowns. With complicated problems, it’s more a matter of working through the methodical steps to develop a solution than it is about developing something entirely new.
Complex problems, on the other hand, have many moving parts and inter-connected elements.
A typical ecommerce site built on Shopify might seem somewhat complicated—especially to someone just starting out—but there is limited complexity. We’ve seen it all before and we know how everything works and how all the features and functionalities relate. We know that themes are best as a starting point, what apps do use, and how the content should flow through the pages.
One of the reasons I have spent 15 years building on Shopify is because by honing my expertise on a single platform, I have inherently reduced both the complication and complexity of a high-performing store. If I were to build an ecommerce site from scratch with open-source frameworks, frontend libraries, databases etc., it would be both complicated and complex. And, it’s likely, few people would understand how it worked. It would be difficult to build, difficult to maintain, and difficult to operate.
When building a new site—or adding significant new functionality—I always encourage starting with the simplest, most focused, most clearly understood goals first.
Try to strive, always, for best-practice solutions. There are likely countless examples of other sites with similar aspects to what you are wanting to do. And there are likely apps and themes and code patterns you can use.
If you don’t need to reinvent the wheel, don’t.
If you need a newsletter signup form, do you really care where or how or when it pops up on the screen, the shape of the popup, whether it has a drop-shadow, and the color of the button? Or, do you simply need to get visitors to sign up to your mailing list? (Have you thought about what happens next? Do you have a welcome serious, win-back campaign, and abandoned cart flow sketched out? Or, are you still thinking about what the signup form needs to look like?)
If you need a loyalty rewards program, do you need custom points mechanics, custom workflows, custom messaging, and a custom interface? Or, will one of the many excellent apps achieve your goals with minimal implementation effort?
If you need subscriptions, do you really need custom trial periods and workflows and renewals that are so complex, you have pages of spaghetti diagrams explaining how it works? Might there be a simpler way to do it—at least for v1? You might be surprised this simpler version actually serves you well through v2, 3, and 4, too!
If you need a product finder quiz, do you really need to custom build it just so you can ask one out of 15 questions in a specific way or so you can change the colors and layout? Or, might the app’s best-practice recommended approach suffice until you have more data? Do you even need a quiz? Are your products that complicated; or, is it how you’re merchandizing and messaging and categorizing that leads to confusion?
If you need mega menus and sidebars and accordions and collapsible sections and animations and carousels and popups, have you considered where you can reduce categories or content to simplify your content architecture?
Do you have enough data to back up these requirements—or are they just personal preferences and opinions? How much time and technical debt might be wasted that could be spent on more impactful aspects of your site that might really move the needle?
There is a tremendous cost—financial, time, and, dare I say, most importantly, headspace—to each and every thing you add that introduces complexity and unknown unknowns.
By launching with the simple, best-practice, tried-and-tested version, you will have more headspace to focus on other aspects of the business. You will have more time and money to allocate towards implementing other best-practice features and functionality you thought you would do without. This will enable you to move faster and collect more data to see what really moves the needle.
Do not underestimate the headspace cost of complexity—on top of the added time, money, and technical debt. Keeping things lean enables you to stay nimble, iterate faster, and grow more sustainably.