Given a choice between functionally equivalent designs, the simplest design should be selected. Universal Principles of Design
Simply put, less is more. Another important implication of this concept is that for any explanation, choose the simplest one – In Wikipedia there is a great example for this; faced with two possible explanations for an empty fridge, hungry roommates or aliens, Occam’s Razor suggests we choose the first option.
Especially today, we are bombarded by thousands of ads and messages every day. We don’t have patience to process all these information, nor do we have time to learn new things (for most of us). Obviously this brings a big challenge to cut through this huge information clutter to spread your remarkable application or service. You will always choose (among thousands of brands and applications) the ones that
- have familiar patterns – easy to recognize
- are intuitive – you understand easily without any further explanation
- you have emotional attachment with – which is the most difficult one to achieve for a brand
I have to admit, applying this concept to real life is extremely difficult. One reason for this is the undeniable attractiveness of adding more and more stuff to your product so you feel better thinking that you will satisfy more people, and you will not miss any important feature out. However this kind of thinking almost every time leads to more dissatisfaction among your users and costs you much more at the end with significant development time and money.
Jason Fried and his team in 37Signals call this ‘Getting Real’ and I love their methodology. Only start with essentials, not one feature more, never. Test with your audience, and then you will start getting feedbacks. Don’t listen… for couple days. Once everything settles down, first anxieties about a change on the feature is gone, then start listening. If you get individual feedbacks on how bad that feature is or why you don’t have that particular feature on your app, keep that in mind but move on. However, once you get continuous feedbacks or a specific feature request from multiple channels, get it done. Not in months, but in days or max couple of weeks. That’s what is called Getting Real. When you look into the design of any application that Signal37 developed you will see a reflection of this methodology, and you will experience a very simple design – for even real complex solutions.
How to overcome the clutter on an app? Occam’s Razor tells you a very important lesson, but as we all know keeping UI very clean is not an easy task considering all the navigation, marketing copy, forms, interactions you need to add to a simple page.
Let’s assume, we need to work on editing a member profile page. Start with a sketch of your section – very low fidelity, just with a paper and pen. Only concentrate on the section to accomplish the task on that page, not even the full page; skip the navigation, the sidebars – you can complete them later based on your design patterns.
Draw the UI roughly, with bold sharpies so you cannot even see the details, the copy etc – they are all secondary at this point. Once your team agrees on the sketch, you can start working on the details. On a regular development cycle, you may consider documenting or wire framing the design, put it on a Photoshop, add many details including the copy, so you are ready for a prototype. Once all done, then you start coding the page and bring it to live. A typical development lifecycle takes couple days or maybe a week depending on your page.
However, the team at 37Signals does an interesting twist just right after the sketch drawing on a piece of paper. They skip all the detailed planning part and jump right into the html coding. That’s revolutionary for couple reasons. First, you cut the development cycle to hours by doing that but more important than that you first solve the problem of how to edit the profile page immediately without getting into any fancy stuff. Most of the time we cannot make it right at the first time, so you tweak the code and there it is, you can see the difference immediately. So you iterate many times until you get it right on the coding. Think how this process would take with the regular development cycle. After weeks of planning and development you realize that it doesn’t work the way you wanted. You tweak it but it may also affect all the design at the background, so you gotta fix that part as well. A lot of double work and waste of time. I am not disputing the fact that planning plays a significant role in designing a complex systems, but the best planning I believe is to see the idea performing right on the page real time (with real code and even real data if you can), that’s really priceless.
Keep Occam’s Razor always in mind in designing your applications, web or mobile. Simplicity is key and extremely difficult thing to achieve.
Book – Getting Real by 37Signals
Blog – Avinash Kaushnik – Remarkable Occam’s Razor blog
Blog – Presentation Zen