The Design of Everyday Things surprised me. Allow me to unpack that statement a bit. As I opened the cover of DOET (an abbreviation the author frequently uses), I expected the book to be helpful, but I did not expect what I received. The book first came to my attention from a data visualization blog post (or it could have been a talk, but that’s not pertinent) which heavily influenced my expectations. I figured, “if the book is highly recommended by data viz folks, it is probably full of advice on how to make something more aesthetically pleasing.” My mind was too narrowly focused on the graphical elements of design. I could have been disappointed when Don Norman began to unpack design psychology or industrial design or the science behind short-term vs. long-term memory, but I wasn’t. I could have felt bogged down and nodded off as I laid in a hammock each lunch break reading through the details of design processes. I wasn’t. Instead, I felt a renewed sense of creativity and deeper understanding that can greatly enhance my work today. Really, I shouldn’t be surprised. I pray before selecting a book to read, and this was the book I was led to read, so I should not be surprised at how timely the content has been in my day job.
What I Learned
I learned A LOT from this book. Allow me to share some takeaways that apply to data viz, reporting, and business intelligence with thoughts on how I plan to apply them.
The Human-Centered Design Process
The Design of Everyday Things reinforced for me the principle that people must come first when designing a data visualization or reporting solution. After all, these solutions are created to answer people’s questions, or tell people a data story, or give people insights about their business, and so on. A truly successful project must be a partnership between SMEs and data professionals, each bringing their area of expertise to the table, working together to produce a useful solution.
Norman breaks human-centered design process down into four different activities:
- Observation: this is the “show me” phase and can take the form of user interviews, working group meetings, or design sessions. “Show me the current pain points”, “show me how access to this data will simplify your role”, “show me what this data looks like in the source system”. You get the idea. Us data nerds need to become more extroverted! We can fight it, but the more questions that we ask of SMEs, the more understanding we will gain. And the more we understand the real problems of our end users, the better solutions we will deliver. It is important to put the time in during this phase to capture accurate data definitions, to create good documentation, to learn the business processes and business systems. Time invested here will save time later and cut down on the “hey, that’s not how we calculate that” or “this data is not right” conversations during UAT. Once the solution (or at least and MVP solution) has been deployed, “show me how you’re using the report” or “show me what is and what isn’t working for you in this iteration of the solution” can be good questions while iterating through the process.
- Idea generation (ideation): This is a phase where a skilled data visualization professional can exercise their expertise. Often SMEs are not sure how they want to see their data displayed. Occasionally some will ask for a specific chart type, but most often people are so used to seeing their data in a spreadsheet that it’s hard to imagine it as a chart. Or they’re so used to the table that the only want the table. During this idea generation phase, I think it is a good idea to prepare a couple of different but appropriate chart types. Then present each option to the end users and work together to select the best one. It is important here to always make sure that whatever the visualization, it should support solving the problem(s) at hand. It is okay if it takes several iterations to get to the final result.
- Prototyping: The importance of useful prototypes is what I took away from this section. It seems obvious to say that, but I have produced some quick mockups in the past that technically worked, but did not allow the user to get a great feel for how the solution would work. And it added time during development to get it right. Lately, I have been mocking up new report designs in Power BI trying to get the look, feel, and functionality as close to the final product as time will allow. I want end users to be able to get hands on with the prototype, to try to break it, to see if the solution really will be the solution before development time is used taken to create the final product. Reading DOET has encouraged me to stick with this while finding ways of producing the mockups more rapidly.
- Testing: Do unit testing, peer reviews, QA, UAT, and whatever else you need to do to test the design. Don’t skimp on this step. If something is wrong, and there usually is, then give opportunity for that issue to be discovered and resolved as early as possible.
Iterate and iterate over this process until reaching the desired solution. This is an area I can and should encourage more. Norman discussed how this process can frustrate product managers because of a seemingly endless timeline of designers going through these steps over and over. I’m glad this came up in the book. As a designer, it highlights the need to develop good relationships with the product owner, product manager, or project manager. Have open discussions about the design needs for the project and work together to budget the time needed to walk through the process. This perhaps was the biggest takeaway that I can apply today.
Affordances and Signifiers
An affordance determines what actions are possible with an object. In other words, how an object can be used. A signifier communicates how an action should take place. Norman uses the example of a door. A door affords opening and closing. Sometimes we can tell if a door should be pushed or pulled by looking for handles or push bars. If we see hinges, that gives a clue as to which side of a door we should push or pull on. These are signifiers. In the same way that someone should be able to look at a door and know how to use it, someone should be able to look at an interactive report and work with it. Given the basic training that any technological tool requires, a good report design should make interactivity obvious wherever possible. I thought about Power BI’s drill through functionality while reading. This is very useful functionality in reporting, but, in my experience, many end users don’t know how to use it even after they’re shown. In this case, the affordance is not well signified, I think, without adding a drill through button. That’s one of my gripes with Power BI. Putting drill through aside, this highlights the importance of well-placed slicers, text, titles, or other possible signifier in a report. Signifiers that indicate when cross filtering or drill down is appropriate, how to export data, or navigate the report. All these details are thought through in a good report design.
In Closing
The Design of Everyday Things surprised me. Allow me to unpack that statement a bit. As I opened the cover of DOET (an abbreviation the author frequently uses), I expected the book to be helpful, but I did not expect what I received. The book first came to my attention from a data visualization blog post (or it could have been a talk, but that’s not pertinent) which heavily influenced my expectations. I figured, “if the book is highly recommended by data viz folks, it is probably full of advice on how to make something more aesthetically pleasing.” My mind was too narrowly focused on the graphical elements of design. I could have been disappointed when Don Norman began to unpack design psychology or industrial design or the science behind short-term vs. long-term memory, but I wasn’t. I could have felt bogged down and nodded off as I laid in a hammock each lunch break reading through the details of design processes. I wasn’t. Instead, I felt a renewed sense of creativity and deeper understanding that can greatly enhance my work today. Really, I shouldn’t be surprised. I pray before selecting a book to read, and this was the book I was led to read, so I should not be surprised at how timely the content has been in my day job.
What I Learned
I learned A LOT from this book. Allow me to share some takeaways that apply to data viz, reporting, and business intelligence with thoughts on how I plan to apply them.
The Human-Centered Design Process
The Design of Everyday Things reinforced for me the principle that people must come first when designing a data visualization or reporting solution. After all, these solutions are created to answer people’s questions, or tell people a data story, or give people insights about their business, and so on. A truly successful project must be a partnership between SMEs and data professionals, each bringing their area of expertise to the table, working together to produce a useful solution.
Norman breaks human-centered design process down into four different activities:
· Observation: this is the “show me” phase and can take the form of user interviews, working group meetings, or design sessions. “Show me the current pain points”, “show me how access to this data will simplify your role”, “show me what this data looks like in the source system”. You get the idea. Us data nerds need to become more extroverted! We can fight it, but the more questions that we ask of SMEs, the more understanding we will gain. And the more we understand the real problems of our end users, the better solutions we will deliver. It is important to put the time in during this phase to capture accurate data definitions, to create good documentation, to learn the business processes and business systems. Time invested here will save time later and cut down on the “hey, that’s not how we calculate that” or “this data is not right” conversations during UAT. Once the solution (or at least and MVP solution) has been deployed, “show me how you’re using the report” or “show me what is and what isn’t working for you in this iteration of the solution” can be good questions while iterating through the process.
· Idea generation (ideation): This is a phase where a skilled data visualization professional can exercise their expertise. Often SMEs are not sure how they want to see their data displayed. Occasionally some will ask for a specific chart type, but most often people are so used to seeing their data in a spreadsheet that it’s hard to imagine it as a chart. Or they’re so used to the table that the only want the table. During this idea generation phase, I think it is a good idea to prepare a couple of different but appropriate chart types. Then present each option to the end users and work together to select the best one. It is important here to always make sure that whatever the visualization, it should support solving the problem(s) at hand. It is okay if it takes several iterations to get to the final result.
· Prototyping: The importance of useful prototypes is what I took away from this section. It seems obvious to say that, but I have produced some quick mockups in the past that technically worked, but did not allow the user to get a great feel for how the solution would work. And it added time during development to get it right. Lately, I have been mocking up new report designs in Power BI trying to get the look, feel, and functionality as close to the final product as time will allow. I want end users to be able to get hands on with the prototype, to try to break it, to see if the solution really will be the solution before development time is used taken to create the final product. Reading DOET has encouraged me to stick with this while finding ways of producing the mockups more rapidly.
· Testing: Do unit testing, peer reviews, QA, UAT, and whatever else you need to do to test the design. Don’t skimp on this step. If something is wrong, and there usually is, then give opportunity for that issue to be discovered and resolved as early as possible.
Iterate and iterate over this process until reaching the desired solution. This is an area I can and should encourage more. Norman discussed how this process can frustrate product managers because of a seemingly endless timeline of designers going through these steps over and over. I’m glad this came up in the book. As a designer, it highlights the need to develop good relationships with the product owner, product manager, or project manager. Have open discussions about the design needs for the project and work together to budget the time needed to walk through the process. This perhaps was the biggest takeaway that I can apply today.
Affordances and Signifiers
An affordance determines what actions are possible with an object. In other words, how an object can be used. A signifier communicates how an action should take place. Norman uses the example of a door. A door affords opening and closing. Sometimes we can tell if a door should be pushed or pulled by looking for handles or push bars. If we see hinges, that gives a clue as to which side of a door we should push or pull on. These are signifiers. In the same way that someone should be able to look at a door and know how to use it, someone should be able to look at an interactive report and work with it. Given the basic training that any technological tool requires, a good report design should make interactivity obvious wherever possible. I thought about Power BI’s drill through functionality while reading. This is very useful functionality in reporting, but, in my experience, many end users don’t know how to use it even after they’re shown. In this case, the affordance is not well signified, I think, without adding a drill through button. That’s one of my gripes with Power BI. Putting drill through aside, this highlights the importance of well-placed slicers, text, titles, or other possible signifier in a report. Signifiers that indicate when cross filtering or drill down is appropriate, how to export data, or navigate the report. All these details are thought through in a good report design.
In Closing
As Norman makes clear in DOET, good design does not just mean an aesthetically pleasing object, even though that certainly plays a part. Good design involves working through a process that results in a useful product for people. I agree with those who have already written on the book and echo their recommendations of The Design of Everyday Things.
