I read John Maeda’s book The Laws of Simplicity*: Design, Technology, Business, Life* a few months back because I was able to get it for free with my trial Audible subscription, and it seemed like the answer to some current problems I was having at the time. It seemed like a sweet win considering the book is pretty popular in universities for psychological design studies. I was more excited, at first, to be able to read-listen and pass the time on my drives than to absorb the lengthy content—psychology at work again! But I liked the content and structure of the material. There were 10 laws broken down to understand how and why we should produce software design that is more “simple.” The kicker here is that simple was defined in many different ways. The essence of the story was that “simple” means one thing at times, depending on context, but a completely other opposite thing when in a slightly different context. For instance, a table with medical data account and phone numbers, reproducing a physical roster chart with health information, is made simple when the user-desired column order and count is achieved within the table. This allows for enough, but not too much, information to be read at one instance of the page scroll. Whereas, a slightly different context—a table for a directory with names, addresses, and comments about a neighborhood—is made simple by dropping the table box constraints and using typography and paragraph form to display a card of a few lines of information in blocks continuously down the page. The reason for dropping the table in that context is the problem with undesired row overflow for more complex entries, like addresses, with special display standards for line breaks and punctuation. Also, if the page is broken up by pagination, that many entries makes for a very tedious hunt the user must wrestle. If the table is exchanged with card approach, this information is absorbed easier than mentally parsing through the commas, spaces, uneven row heights, etc. There are many examples like this in the book. One law that really stuck with me, my springboard for the following steps from my work at SEP, is Law 9. “Simplicity is not less just for the sake of less. Failure: some things can never be made simple.” That made me think harder. If the goal is not just Make it simple, then there must be a process to know when simple in every case is more or less achieved. There is not one right way to simplicity, many caveats and exceptions exist. I want to now share some of my practices for design simplicity that has helped me while working with developers and users.
- Diverge thought, perspective, and role – I could write a whole article on how diversity matters in design. Absolutely. Here, I am talking about how diversifying the minds, background perspectives, and expertise roles in a room talking about the direction of the software comes into play with simplicity. In lean design techniques, there is a healthy exercise that includes everyone on a team drawing and collaborating on the vision called design studios. In this process, there is a diverging of many avenues, paths, and solutions towards accomplishing a user goal. This diverging is crucial to simplicity because it pulls out all of the static from everyone’s thoughts and imagination of what the workflow could be, would be, and should be and records it for further reference. Where the interaction and UI designers can converge and agree from a large pool of choices is magical because without the ideas and many creative angles challenging and impacting a solution, the truly important pieces of information may not surface otherwise. This surfaced key information can then be prioritized and converged into something meaningful and simply useful for the user. This is because the cluttered static from before has now been combed and refined to make actionable meaning.
- Boil down experience goals – This comes down to outcomes, instead of output. If everyone on the project, including the client linked to the users, is working to understand the user goals, that’s an excellent start. Where this makes simple happen is when these goals are reduced to the most underlying message, the least common denominator, and then are used to “call the shots”. This means that when a component, placement, or number of screens in a workflow is in question between a combination of developers or designers or project owners, etc., then the underlying reduced goal that the user needs to achieve makes the decision. When the meaningful information and tasks are so clearly defined, the outcome is simple to achieve for the user (i.e. finishing the wizard on tax software so that it is trustworthy, complete, and can be recalled later but also freeing up more time for other things in life).
- Give it time – The other piece I have learned about making simple happen is I have to be patient with my process. More times than not, my work is not finished after one to two iterations of facilitating design decisions and direction with the team. Sometimes getting away from the workflow and wireframes and then revisiting it with fresh eyes another day (mine or a peer’s around me who has never seen it before) is the biggest win. After all of the prioritization and conversations about what needs to be included and what needs to happen, there is beauty in going through work with the focus on simple. Is this page too dense standing 10 feet away from the screen? That looks aesthetically pleasing there, but does it serve the user a purpose? Can the user understand the page hierarchy of information they need to with just a glance? These are just a few. Design, like software, is never “done”. Making simple sometimes happens fast and sometimes happens late. But you might not know when you will get there until you are there. Welcome this.
- Welcome the process – This brings me to my last point—the shortest one. Welcome these steps. Hurrying to make quick design decisions is a dangerous approach to building the right thing. Building empathy over time with your user will help you diverge, boil down, and be patient with the simplifying. Heading into a new project thinking, “I definitely know exactly what this is going to look like and how the interaction will go” may lead to a longer process in the long run by failing to reach the outcome. I’m not saying act slowly. But I am saying that this process is best when approached with intention, plenty of iterations, and the understanding that making simple happen takes time and learning.
A little piece of design—as a “Kasun” point,
Chelsie
