Matt Bishop

Data Analytics & Visualization Student

Redesigning the CUNY Graduate Center Library’s Website: A Design Story

Scope

The CUNY Graduate Center (GC) Library is in the process of revamping its digital presence. In order to do this in a way that centers the user’s experience, a careful examination of user behaviors, desires, knowledge, and expectations is required.

My design team, Team Buttons, set out to research the library’s target users in all of these aspects in order to provide the GC Library with the best possible high-fidelity prototypes to help guide the library’s website design process for desktop and mobile interfaces.

The images below depict the current state of the CUNY GC Library website’s homepage on desktop and mobile devices:

 

 

 

Process

In our effort to create the best possible high-fidelity prototypes, we carried out the following research methods, while utilizing key principles of information architecture and interaction design:

  • User Interviews, Observations, & Questionnaire
  • Card Sorting & Tree Testing
  • Competitive Analysis
  • Low-Fidelity Prototype User Testing

With the above research, we were able to create the following deliverable milestones, along with accompanying research briefs to guide our own high-fidelity prototype design process:

  • Persona
  • Site Map
  • Competitive Analysis Review
  • High-Fidelity Prototypes

 

User Interviews, Observations, & Questionnaire

To begin our user research, we collected data through interviews, observations, and questionnaire submissions from library staff and graduate students (current and recently graduated). For interviews, questions were asked of participants regarding library site use, preferences, and frustrations. Questionnaires included fifteen questions that also touched on library use and preferences but were more focused on gathering ratings regarding common library website activities. Observations were done by having participants carry out three tasks on the School of Visual Arts and Columbia University library websites. The tasks were divided among our four team members, and I conducted two interviews and two observations. Results were then collected and analyzed by the team in order to produce our user profiles in the form of personas.

 

Deliverable: The Persona

My persona is snapshot of a tech-savvy graduate student who wants to use the library and its online tools to conduct her research, enhance her writing skills, and attend events for professional and personal interests. This particular profile choice is meant to illustrate the needs and wants of a typical student user of the CUNY Graduate Center Library based on the results of my team’s user research. This is intended to compliment other personas that my team created, including a library staff member, a professor, and a PhD student.

Major findings from our user research:

  • Site navigation is key
  • Database searches are important
  • Users like events, but are unaware of them

 

Card Sorting & Tree Testing

Our team conducted an online card sorting study of potential menu items informed by the “heat map” that we were provided with of the CUNY Graduate Center Library website’s homepage and from model websites suggested to us by the librarians at the GC Library. For items that we saw users had difficulty with in the card sort, we looked at model websites to see how they structured similar content.

 

The foundation of our tree test came out of this process. Major decisions in our tree test study came from group discussions about logical information structure and user interaction design, such as learning through repetition. The card sort and tree test were created using Optimal Workshop. The pics below are examples of the analyses that were provided on Optimal Workshop as a result of our card sort and tree test respectively.

 

 

 

Deliverable: The Site Map

From our card sorting and tree testing, we found that useful resources which have proven particularly difficult to categorize could be easier to find when brought to the front of the interface rather than burying them deep in the navigation structure. We created the “Quick Links” sidebar to accommodate these hard-to-find yet important items. We added “Chat with a Librarian” to the Quick Links sidebar because of the tendency we saw for users in our tree testing to look in “Librarian Assistant” when searching for items on the website. We also relied on some information found during our earlier interviews, observations, and questionnaire when creating this site map (using Lucidchart).

Main findings of our card sorting and tree testing studies that contributed to our site map creation:

  • Some menu items can be inherently difficult to find within a navigational structure – these should be highlighted for easier access
  • Users categorized different ways of searching together into one group
  • Placing the “My Items” section under “Account” was successful
  • “Librarian Assistance” and “Search” should be high-level menu items

 

Competitive Analysis

For our competitive analysis, our team evaluated five websites that represented alternatives to the information structure and overall design of the CUNY Graduate Center Library’s website. These sites came from Google Scholar, Columbia University Library, Boston College Library, Duke University Library, and Cornell University Library. These websites presented similar content and functionality to the CUNY GC Library’s website with relation to the needs of graduate student researchers. We selected six dimensions to analyze and compare the competition: the homepage, site navigation, page organization, search, style, and mobile-friendliness. Each dimension was rated on a scale from 1 to 3, with 1 being low-quality and 3 being high-quality.

 

Deliverable: The Competitive Analysis Review

From our competitive analysis, we produced a complete report of our findings. In this report, we considered the following elements to be important when designing our new prototype because of user expectations defined by the competition:

  • Consistent use of style elements across browser sizes
  • An intuitive page layout
  • A well-organized menu hierarchy
  • Good search functionality

 

Low-Fidelity Prototypes: Creation & User Testing

Our team created two low-fidelity prototypes, one for desktop and one for mobile, and tested them on users via the completion of two important yet distinct tasks on the CUNY Graduate Center Library’s website. The desktop task asked users to find the “Chicago Manual of Style” online database and the mobile task asked users to request a book called “Lean UX” through Interlibrary Loan. Prototypes were built in Sketch and connected to InVision for interactive user testing. Each teammate conducted two user tests and results were discussed as a group.

All of our users completed the tasks without much trouble, but important labeling and style issues were discovered in our testing. Some of the major recommendations that I found from this testing are the following:

  • Use the full name of Interlibrary Loan rather than “ILL”
  • The Interlibrary Loan process should be made transparent
  • Make drop-down menu arrows face right by default, or get rid of them
  • Increase the use of text styling elements to separate disparate information fields

 

Deliverable: The High-Fidelity Prototypes

Synthesizing results from all of our earlier tests and research methods, we designed two high-fidelity prototypes, one for desktop and one for mobile, to demonstrate two important tasks on the CUNY Graduate Center Library’s website. We made sure to highlight user personalization, an intuitive menu hierarchy, easy-to-use search functions, a minimalist color palette, and positioning key information above the fold in our final designs. All team members created specific pages of the final prototypes in Sketch according to common themes and a style guide. After this was completed, we collaborated on how to best combine the pages into our final Sketch files that were then imported into InVision in order to add hotspots to the pages to make them interactive.

 

Review

Presenting our high-fidelity prototypes to the CUNY Graduate Center Library staff and viewing other teams’ prototypes allowed us to see if the products of our research aligned with the goals that we set out to achieve. GC Library staff were very responsive to the style and information hierarchy changes that we and other teams implemented. However, the use of user personalization features, such as book recommendations, should be implemented with caution. While our users noted how they desired personalized elements on their online experiences, library staff shared with us their concerns for data privacy when user behavior is being tracked by a site like theirs. An alternative to personalized book recommendations could be staff book recommendations or recommendations based off of user-selected categories (as an optional opt-in feature).

 

 

See Our Final Prototypes!

You can try out our final high-fidelity prototypes by clicking on the links below for the desktop and mobile tasks. I hope you enjoy them!

Desktop

Mobile

For your convenience, task flows for these prototypes are provided below.

Desktop Task Scope: Request the checked-out book called “Lean UX” from Interlibrary Loan.
1) Click anywhere on the text field on the OneSearch bar and click on the magnifying glass icon to the right of it.
2) Click on the second search result on the text that reads “Lean UX: Designing Great Products with Agile Teams.”
3) Click on the “Request through ILL” button.
4) Click on any empty text field and then click the “Submit” button to complete the task.

Mobile Task Scope: Register for “Zotero on Your Laptop: The Basics” event.
1) Scroll down on the mobile homepage and click on the “Zotero on Your Laptop: The
Basics” event advertisement.
2) Click on the “Register” button.
3) Click on any text field to populate Name and E-mail information and then click on the “Submit” button.
4) This task is now complete if you see a green “Registered” notice.

*Note: For either task, you can click on top-left logo or “Home” underneath it to return to the homepage.

 

Visual Lies: Usability in Deceptive Data Visualizations

Designers can utilize usability principles to create products that may greatly enhance our everyday lives. From smart phone apps to non-Norman Doors, the application of usability principles has given us wonderful tools, games, and digital interfaces. But what about the dark, deceptive uses of these principles?

In a previous post, I explored ways in which online notices for terms and conditions are often designed in ways to be deceptive to internet users (that post can be found by clicking here). In this post, I focus on a few methods that data visualizers sometimes utilize to mislead users about research findings. For each method, I highlight the signifiers that are manipulated to promote an unrealistic understanding of the visualized data. I concentrate on examples of three areas in which data visualizations can be misleading: size, segmentation, and graph type.

 

Size 

Size signifies quantity, or the volume, number, or degree, of variables within a data visualization. The appropriate use of size can promote a realistic understanding of quantities discovered in a study. Two ways in which this signifier is manipulated to deceive users are the use of a truncated axis and depicted radius as quantity.

Truncated Axis

Figure 1.0: Example of a truncated axis (Source: https://blog.heapanalytics.com/how-to-lie-with-data-visualization/).

The graphs in Figure 1.0 above depict an exaggerated form of a truncated axis. In this image, the y-axis from the graph to the right is cut when transcribed onto the graph to the left. The result is a line graph that seems drastically different. A data visualization makes use of visual signifiers to show users trends and highlights in data, but the significant difference in size of the bars in the graph on the left suggest to a user that interest rates have increased drastically from 2008 to 2012 – a misinterpretation that is avoided in the graph on the right. Both graphs show the same data, but the one on the left represents the data in a misleading fashion.

Radius as Quantity

Figure 2.0: Example of using radius as quantity (Source: https://medium.com/@Infogram/study-asks-how-deceptive-are-deceptive-visualizations-8ff52fd81239).

When depicting points on a scatter plot, it is often helpful to manipulate the size the points to represent differing values of a variable that is not represented on the x and y axes. Since size typically signifies quantity, it is best to stick to a one-to-one mapping between the area of points and the actual values (https://medium.com/@Infogram/study-asks-how-deceptive-are-deceptive-visualizations-8ff52fd81239). A deceptive designer, however, may utilize radii to represent quantities. Since users typically view size as a signifier of quantity, the differences in quantity between points on such a scatter plot would appear more dramatic than they should be, as seen in Figure 2.0 above.

 

Segmentation

Segmentation, or the separation of elements into parts, can signify categories, domains, or ranges within a chart. The careful use of segmentation in a data visualization may enhance a user’s understanding of the data. However, deceptive uses of segmentation can lead users to incorrect conclusions about a visualized set of data. Binning and using a limited scope are two ways that segmentation can be misused in a deceptive manner.

Binning

Figure 3.0: Example of the manipulation of binning (Source: https://flowingdata.com/2017/02/09/how-to-spot-visualization-lies/).

Binning is a tool often used in choropleth and heat maps to categorize values by colors across geographic regions. Binning limits the range of colors into a specific number of options deemed appropriate by the map’s designer. If done ethically, binning can aid a user’s ability to discover values on a map by allowing for easy referencing to a legend included with the map. If done in a deceptive manner, a map designer can limit the number of color bins too much, making very different values seem as if they are the same. Figure 3.0 shows an example of this with a deceptive instance of binning given in the legend on the left.

Limited Scope

Figure 4.0: Example of providing a limited scope (Source: https://flowingdata.com/2017/02/09/how-to-spot-visualization-lies/).

Sometimes quantities rise and fall naturally with something that is cyclical. In Figure 4.0, the graph to the left shows values that are rising, but the graph to the right reveals that it is part of a much larger graph that shows values which rise and fall at fairly regular intervals. Variables such as profit may rise and fall seasonally, or with each fiscal quarter, depending on the times of peak sales periods. A deceptive designer could use a limited scope to criticize a sales team for seemingly poor performance during a low season, even though the performance might be normal when viewed on a larger scale. The limits of a y-axis signify a complete range to a user, and so anything falling outside of that range is not likely considered at all by users (and is quite literally invisible).

 

Graph Types

Types of graphs can be used to manipulate a user’s ability to understand a data set. It is important when visualizing data to choose a graph type that most appropriately aids a user’s visual interpretation of complex data. Two graph types that are often misused are pie charts and maps; I will briefly explore these graph types below.

Pie Charts & Difficult Comparisons

Figure 5.0: Example of the misuse of pie charts (Source: https://infogram.com/blog/4-common-missteps-that-lead-to-deceptive-data-visualizations/).

Pie charts are notorious for their inability to be compared accurately to one another. When striving for an accurate portrayal of values, they should be avoided. This can be seen in Figure 5.0 above: a user of these pie charts would likely have a very difficult time comparing the values from each chart if it weren’t for the numbers given for each slice of the two pies. Since size signifies quantity in most charts, it is best utilized in charts where sizes are more easily comparable, like in bar charts or even scatter plots.

Maps & Population Density

Figure 6.0: Example of a map that includes human-dependent spatial data without accounting for population density (Source: https://flowingdata.com/2017/02/09/how-to-spot-visualization-lies/).

A good rule of thumb in spatial data analysis is to always account for population density when visualizing values that are person-dependent. On a choropleth or heat map, where color signifies quantity, a user will be drawn to the colors that a legend indicates are most extreme. In Figure 6.0, areas that are darkest are simply the most population-dense regions of the United States. Without accounting for population density, your newly created map may look the same as hundreds of maps bearing a striking resemblance to Figure 6.0, which are falsely considered informative and are regularly shared across social media sites.

 

Discussion

The purpose of this post is not to encourage the use of these deceptive practices. To the contrary, my aim is to raise awareness of their existence so that the average user may be better able to identify misleading data visualizations. It is important to note here that many of these practices may not be deceptive when used appropriately (e.g. truncating a y-axis when a small change in value has significant real-world consequences, such as in global temperature changes related to climate change). With a greater understanding of usability principles and data literacy programs that apply these principles to the interpretation of data visualizations, users can better protect themselves from being misled about data. Many data visualizers are perpetrators of these deceptive acts accidentally, so an awareness of these techniques could also encourage the creation of more accurate and ethical data visualizations from those willing to learn. The utilization of purposeful user testing, through the asking of questions that require users to find values or make conclusions based on a graph, could also help ethical data visualizers to avoid the unintentional inclusion of these deceptive data visualization elements.

 

 

References

Krystian, M. (2016, February 17) Watch Out! 4 Common Missteps that Lead to Deceptive Data Visualizations. Retrieved December 4, 2017, from https://about.infogr.am/blog/4-common-missteps-that-lead-to-deceptive-data-visualizations/

Parikh, R. (2014, April 14). How to Lie with Data Visualization. Retrieved December 4, 2017, from https://blog.heapanalytics.com/how-to-lie-with-data-visualization/

Study Asks, How Deceptive are Deceptive Visualizations? (2016, October 11). Retrieved December 4, 2017, from https://medium.com/@Infogram/study-asks-how-deceptive-are-deceptive-visualizations-8ff52fd81239

Yau, N. (n.d.). How to Spot Visualization Lies | FlowingData. Retrieved December 4, 2017, from https://flowingdata.com/2017/02/09/how-to-spot-visualization-lies/

 

Design Critique: Splitwise (iPhone App)

Splitwise (version 4.4.12 for iOS 9.0 or later) is an Apple iPhone application designed to “split bills and expenses the easy way.” This app functions as a bill splitting and record-keeping tool for roommates, friends, or any group of individuals with shared or borrowed expenses. Splitwise provides an appealing and simple digital interface that makes bill creation quick and easy but requires some additional work to be an effective record-keeping app for bills. This review examines the usability of the homepage layout, bill creation process, and bill history function of Splitwise using Don Norman’s concepts, principles, and terminology included in his book, The Design of Everyday Things.

 

The Homepage

 

Figure 1: Splitwise homepage.

The homepage of Splitwise provides excellent discoverability. As seen in Figure 1, the homepage of the app provides a small number of clear options for the user to choose from. Placing the most common function of Splitwise, bill creation, at the bottom-center of the screen right above the iPhone’s home button, makes it easy for the user to discover it. A simple “+” provides a well-known signifier that a bill can be added without requiring much knowledge in the head. The app draws additional attention to this button by making it green while nearby buttons are gray. Other options, “Friends,” “Groups,” “Activity,” and “Me,” are labeled plainly around the bill creation button and they open pages that map logically to the label names. Money owed to and from the user, as well as the user’s total balance, are displayed prominently in a banner near the top of the page – all data that the user would likely want to know before creating a bill. This system image reflects what information the user would like (and might expect) to be included on Splitwise’s homepage.

 

Bill Creation

 

From Bibblebytes

Figure 2: Bill creation page 1.

Bill creation is initiated by clicking the “+” button. As seen in Figure 2, the user is prompted to enter names or contact information (either as phone numbers or email addresses) of other participants included in the bill. Splitwise’s integration with a user’s iPhone contact list permits the user to start typing and have a suggested contact appear at the top of the menu, allowing for quick selection with immediate feedback. This mirrors the searchability of the contact list on the iPhone’s default Phone app, so a user will likely be familiar with this process. If not, default faded text in the top banner, “Enter names, emails, or phone #’s,” provides additional knowledge in the world for simple discoverability to novice users.

From AppAdvice

Figure 3: Bill creation page 2.

After selecting at least one person or group, a new screen appears (as seen in Figure 3). In this new screen, users must enter a bill description and amount. The bill description and amount fields include faded text above a dark underline – a standard digital signifier indicating that the user can enter text. The default faded text for the bill description, “Enter a description,” provides instructions that will assist novice users. Additional options* to change who paid for the bill and how it should be split are indicated by a gray bubble underneath the bill amount. This gray bubble is a poor signifier since it is inconsistent with the simple bill amount and type signifier of underlined faded text; matching them would provide greater discoverability to its function. Once the user completes the required description and amount sections, the bill creation process can be completed by clicking the “Save” button at the top-right of the page. This “Save” button remains inactive until the required information is completed, providing a physical constraint that forces the user to enter key information. Only two pages for bill creation with three required data points makes this process simple for a user to navigate and limits opportunities for slips and mistakes.

*An additional bill type image option will be discussed in the Bill History section below.

 

Bill History

 

Figure 4: Activity page.

Previous bills that are created or paid are added to the “Activity” section of the app (as seen in Figure 4). Bill type images are included on the left-hand side of each item, but there is no way to sort or search by these bill type images. The existence of a bill type image in Splitwise is confusing: it signifies some purpose, but is not mapped to any existing affordance. Furthermore, there is no indication during bill creation that a bill type image can be assigned. The user must click on the default bill type image to the left of the amount field (as seen in Figure 3) during bill creation to open a selection menu, but the app provides no clear signifier for this functionality. Even without bill type images, the app provides no way to search through the Activity page by text. A spreadsheet of bill data for a specific friend or group can be exported, but no searchable in-app functionality exists. To remedy this, scrapping the bill type image option and including a text search function on the Activity page would eliminate confusion about the bill type image’s purpose and provide the user with a simple bill history tool that mirrors the contact list’s searchability.

 

The Verdict

Splitwise provides an efficient, usable tool for splitting bills. The homepage is simple to navigate and bill creation is a short and painless process. Splitwise’s bill history capability is lacking, providing a confusing bill type image functionality and no in-app way to search through a user’s history. However, getting rid of the bill type image option and adding a text search function to the Activity page would fix this. Regardless, Splitwise provides a nearly painless user experience for bill splitting and continues to be one of the most popular apps of its kind.