The most unique element of my #IronViz submission was the national park calculator, which is found on the third dashboard. I suspect many people missed this, so writing a blog post about it could be useful. This was my first attempt at trying this technique, but it seemed to work well for my purposes.
Less than 48 hours to the submission deadline, the calculator was still just an idea. I wasn’t sure about the project’s feasibility, because of my lack of experience and time constraints. The idea wasn’t revolutionary though, because several people in the community have explored similar ideas before. For example, Robert Rouse’s political Iron Viz entry “US vs. THEM” used this technique, and before that, Steve Wexler’s Salary Comparison Dashboard broke a lot of the initial ground for this idea. These examples were in the back of my mind when I decided to spend my Saturday trying to build a calculator of my own.
The starting screen of the calculator has a series of eight questions with each question associated with a parameter. The beginning state has the “no selection” value active for all parameters, which causes the instruction screen to show on the right-hand side. Once a selection is made for any of these questions, the instructions worksheet will change into a lollipop chart with a list of recommended national parks. Each selection updates the results and displays the top 8 recommended parks.
Each recommended national park in the lollipop chart directly links to its website, so users can explore in more detail. I felt this was a good approach from a user experience perspective, because it helped inform and guide users about the process. It can get tricky when you are throwing an unfamiliar technique at people, so making this process as simple as possible was the focus of the design. Hopefully, users found this calculator intuitive to use, because my main effort was hiding the complexity involved behind the scenes.
Why Build a Calculator?
Before exploring the how questions, it’s always a good practice to start with the “why”. As already mentioned, this was the first time I tried using this technique, and not many other examples seem to exist. The rare use of calculators is likely due to their narrow applications and the perceived complexity in creating them. Below is a chart to summarize how I see this approach being different from the more typical Tableau use cases.
Instead of me selecting a story for my audience, this approach has the audience tell me what’s important to them. This is a bit of a risky idea from the Tableau author’s perspective, because it requires multiple actions from the user to create value. If one cannot convince their audience to participate, then no answer can be calculated.
This is where Steve Wexler’s approach with the income calculator particularly shines, because he creates this motivation for people by showing them how they compare in compensation against their peers. Assuming users are convinced to participate, the results are perceived to be valuable, and the user experience is well-designed, then people should generally find the calculator useful and rewarding.
Why does a calculator support a rewarding experience? Each selection provides instant feedback with updated results. It’s interactive, which allows an audience gain a variety of results without having to personally conduct in-depth analysis. This could be a good or a bad thing, based on the specific situation. In cases where a high confidence exists in the data results, but each user’s specific needs vary a lot, then a calculator does make a lot of sense. Basically, you are trying predict and match user questions with the data to provide the most relevant answers.
In the case of my national park dashboards, I was trying to answer the simple of question, “Which national park should I visit?”. For questions where the best answer is “it depends”, then a calculator should be considered. This specific question about choosing a national park to visit depends on many different preferences about location, climate, activities, etc. To design an effective calculator, you must be able to correctly identify questions that people care about, while also providing valuable results that are supported by the data. For my application, each selection should support the user’s decision-making process.
How to Build a Calculator?
I relied on my experience with survey data to guide me during the early phases. Since several questions were Likert scale, I primarily based the calculations on a 5-point scale, but any scale can be used, e.g. 10-point or 100-point scales. Once my scales were selected, a separate data set was created with each answer coded with a numeric value. This decision of creating a separate data set helped performance and standardize the logic for the application. Each park would be associated with a code based on the different answers provided by the users. (example below)
Every question has a response and an associated value code. For example, on “What is your preference on humidity?” question, a user selection of “High” would return a numeric code of 4, while “Very Low” on this parameter would return a value of 1. A calculation would then score these coded responses against all national parks. How the logic is constructed is very dependent on the question, but in this case, parks associated with the highest humidity would score worse when compared to the other options of low or medium.
Questions can also be binary. For example, on “What is your main motivation for visiting a national park?” question, all parks are coded with either a one or a zero for all the possible responses: adventure, solitude, natural beauty, popular attractions, winter activities, or water activities. Despite being binary, a park can be associated with more than one response, e.g. a park can be good for people looking for both “Adventure” and “Solitude”. When structured in this way, a potentially complicated question is much simpler to answer. The logic gives max points to parks associated with the response and minimum points for parks not associated with the response. (example below)
Other questions may have small differences, but the method is generally the same. First, select a standard scale. Next, code the items in the data set for all questions. Lastly, build the parameters and calculations to update the final output.
Outside of the results, additional logic counts the number of selections made. This allows me to do a couple of things. First, the instructions are replaced by the lollipop chart after a first selection is made. Second, the n-size updates the denominator of the final calculation to ensure the output will makee sense throughout the process. Of course, more selections lead to better results, because of more variation in the answers. After the final output is calculated, the user could then either click on a specific item in the chart to visit the website or continue to the second question on where to go.
Considering this was the time I built a calculator, the result met my expectations. Several improvements could be considered, like incorporating a question importance field to further customize results. However, one should be cautioned against adding too much information or functionality, because every new addition greatly adds to the complexity for both the user experience and the logic behind the scenes. It’s a real balance between providing customized information and keeping the process simple. I look forward to build on this initial progress for a future project. If you have questions or feedback, then feel free to reach to me on Twitter. @DavidAKrupp