Keeping design complexity at bay can help keep code complexity low and cycle times fast.
Growth in design complexity is exponential and is directly correlated to growth in code complexity.
Do you have a haunting suspicion that your product interface may be too complex? Is it consistently taking longer than you’d expect to ship changes to the interface? Are full-stack engineers getting tired of touching 10 different files in 4 different languages to get something done?
To be fair, it can be hard sometimes to find the balance between complex-to-build and boring-to-use.
However, boring interfaces are often easier to use and can still generate billions in revenue, so we must be ruthless about “using the right tool for the job” in this case. The cost of being relaxed about this could be months, maybe even years of lost development time that could go straight to your competition.
If it’s getting harder and more complex to ship with a small team, then it’s definitely time to consider a reboot in design and technology.
At least, this is the conclusion we have come to at Hired after using angular to support design complexity that turned out to be unnecessary. After enough months we realized we could shed entire layers of design & architecture and achieve the same if not better business results.
From my experience, we’ve reached that point when all of the existing re-usable UI elements have been exhausted and we have no other choice but to dive deep on a novel concept for the web or for our style guide.
At least knowing that it can’t be done more simply makes it much easier to sleep at night.
I’d love to hear your stories about when a design turned out to be too complex or perhaps not complex enough!