Previously, I wrote about the value of design in libraries, and others, including Stephen Bell and Aaron Schmidt, have written and presented on the topic of design in libraries as well. Now I’d like to focus on and delve specifically into what graphic design process may entail. For librarians who design regularly, I hope this helps to articulate what you may be doing already or perhaps add a bit to your tools and tips. For those that don’t design, I hope that this might give you insight into a process that is more complex than it may seem and that you might give designing a try yourself. For some ideas, try any of these are great library design projects: signs, webpages, posters, flyers, bookmarks, banners, etc.
What Is It Like to Design?
People might wonder why design needs to be a process. The very basic process of design, like many processes, is to solve a problem and then create a solution. Jason Fried, founder of 37signals and co-author of Rework, tweeted recently, “Your first design may be the best, but you won’t know until you can’t find a better one.” He later added this image from The Intercom blog as an illustration to make this important point. Striving for an elegant or best solution is something librarians and designers have in common. Librarians often share best practices and examining this process may not only assist us in terms of design, but perhaps we can apply these concepts to other areas of librarianship as we create programs, outreach, marketing, and more.
Design is a process.
Designers work hard to develop a successful design and it doesn’t always come easy. Here are some of the basic steps designers take in the development phase of their work. Every designer is a bit different, and not all designers follow the exact same process. However, this is a pretty good foundation for beginner designers and once you get good, you can incorporate or modify pieces of the process to make it work for you and the project at hand. Design is subjective and there are few hard and fast rules to follow, however, in future posts I’ll be talking more about design elements and details to help you create stronger designs that will speak to your users.
Design has constraints.
Before you start laying things out and jumping into a design, you want to understand what the “specs” or specifications are. These are the details of the final piece you need up front before you begin any design. For example, is the piece going to be printed or is it an online piece? What’s the budget? Is it black and white, color, how many colors? What size? If printed, what paper will it be printed on? Will color bleed to the edge or is there a border? Is there folding or cutting involved?
All of these considerations are going to be the rules you must work under. But most designers like to think of them as challenges; many times if the specs aren’t too restrictive they can actually empower the designer to drive harder to make it more creative. You really don’t want to start designing before you get this all worked out because once you’ve jumped in it can mean starting over if a critical spec is missed. If you have designed for a set of specs and then try to modify it to fit all new specs later, it almost always compromises the strength of the design to work this way. Better to know those specs up front.
Design requires an open mind.
Sketch like crazy. You may think you have the best, most original idea ever once you get your assignment or have your specs, but please do yourself a huge favor and sketch some ideas out first. Do at least a page of sketches if not much more. Take notes, do some research on the topic, do word associations and mind maps and draw stick figures and doodle. Keep an open mind to new possibilities. Observe the world around you, daydream, and collect inspiration. You might still stick with that first idea but chances are you come up with something even better and usually more original if you push yourself to think in new ways and explore.
Design step by step.
Depending on the complexity of the piece, whether it’s print or web, I might do more or less of each step below. If you’re designing or reworking a website, this is a good method to get a powerful, thoughtful design. And of course, you can go back and iterate based on feedback given, changes to the design that impact design elements. If the design structure is strong, changes should be fairly small.
Basic Design Development Process:
1. research the topic, take notes, ask questions, doodle, jot down ideas, simmer
2. series of thumbnail sketches
This is an extension of step 1. Do as many as you can muster…do it until you are sick of it. Here is a great presentation I recently found on sketching.
3. build wireframe
Stay abstract/block in composition. This is going to be larger than a thumbnail but try to keep it free from detail.
4. sketch comps
Take steps 2 and 3 and flesh out 3 comps. These should not be final but should follow specs and be close to finished in terms of look and feel for the major design components. You may use lorum ipsum text if you wish. This technique helps to keep people from giving feedback about the content over the design. Of course there are times the content may absolutely need to be there but use your own discretion and know that this is an option and may help in moving forward.
5. finalize comps Usually 3 choices are offered to a client, but if you are your own client obviously just do your favorite.
All of this is separate from any CSS, html, javascript, etc. Mock it up using Photoshop and/or Illustrator (or a similar program of your choice). The point is to focus on the design apart from laying down code. “Form Follows Function” really rings true. It isn’t an either/or statement. The product must work first and foremost and the design will support, enhance, and make it work better. If it doesn’t work, no amount of gorgeous design will change something that is badly broken.
TaDa, right? The design is done, let’s celebrate!
Well, not exactly. This process is merely just one phase of a much larger process that includes steps including: initially meeting the client, negotiating a contract, presenting your designs, more testing and usability, iterative design adjustments, possibly working with developers or print houses, etc. Design is a process that requires study, skills, schooling, and knowledge like many fields. I’ll be talking about more design topics in the future, so what is not covered here I’ll try and cover next time. Luckily, I gathered some great…
Design resources to get you started:
This is not a comprehensive list by any means but highlights of a few resources to get you thinking about design.
Non-Designer’s Design Book: One of the best beginner design books out there (overlook the cover- it really is a great book!).
Smashing Magazine: Really good stuff on this website- including freebies, like decent icons and vector artwork. Covers typography, color, graphic design, etc.
a list apart: another great site that delves into all kinds of topics but has great stuff on graphic design, UI design, typography, illustrations. etc.
Drawing on the Right Side of the Brain: seriously. even if you think you can’t draw. try it. anyone can draw, truly. Drawing helps you think in new and creative ways- it will help you be more creative and help in problem solving anything. Even those small doodles are valuable.
At the NCSU Libraries, my colleagues and I in the Research and Information Services department do a fair bit of instruction, especially to classes from the university’s First Year Writing Program. Some new initiatives and outreach have significantly increased our instruction load, to the point where it was getting more difficult for us to effectively cover all the sessions that were requested due to practical limits of our schedules. By way of a solution, we wanted to train some of our grad assistants, who (at the time of this writing) are all library/information science students from that school down the road, in the dark arts of basic library instruction, to help spread the instruction burden out a little.
This would work great, but there’s a secondary problem: since UNC is a good 40 minute drive away, our grad assistants tend to have very rigid schedules, which are fixed well in advance — so we can’t just alter our grad assistants’ schedules on short notice to have them cover a class. Meanwhile, instruction scheduling is very haphazard, due to wide variation in how course slots are configured in the weekly calendar, so it can be hard to predict when instruction requests are likely to be scheduled. What we need is a technique to maximize the likelihood that a grad student’s standing schedule will overlap with the timing of instruction requests that we do get — before the requests come in.
Searching for a Solution – Bar graph-based analysis
The obvious solution was to try to figure out when during the day and week we provided library instruction most frequently. If we could figure this out, we could work with our grad students to get their schedules to coincide with these busy periods.
Luckily, we had some accrued data on our instructional activity from previous semesters. This seemed like the obvious starting point: look at when we taught previously and see what days and times of day were most popular. The data consisted of about 80 instruction sessions given over the course of the prior two semesters; data included date, day of week, session start time, and a few other tidbits. The data was basically scraped by hand from the instruction records we maintain for annual reports; my colleague Anne Burke did the dirty work of collecting and cleaning the data, as well as the initial analysis.
Anne’s first pass at analyzing the data was to look each day of the week in terms of courses taught in the morning, afternoon, and evening. A bit of hand-counting and spreadsheet magic produced this:
Instruction session count by day of week and time of day, Spring 2010-Fall 2011
This chart was somewhat helpful — certainly it’s clear that Monday, Tuesday and Thursday are our busiest days — but but it doesn’t provide a lot of clarity regarding times of day that are hot for instruction. Other than noting that Friday evening is a dead time (hardly a huge insight), we don’t really get a lot of new information on how the instruction sessions shake out throughout the week.
Let’s Get Visual – Heatmap-based visualization
The chart above gets the fundamentals right — since we’re designing weekly schedules for our grad assistants, it’s clear that the relevant dimensions are days of week and times of day. However, there are basically two problems with the stacked bar chart approach: (1) The resolution of the stacked bars — morning, afternoon and evening — is too coarse. We need to get more granular if we’re really going to see the times that are popular for instruction; (2) The stacked bar chart slices just don’t fit our mental model of a week. If we’re going to solve a calendaring problem, doesn’t it make a lot of sense to create a visualization that looks like a calendar?
What we need is a matrix — something where one dimension is the day of the week and the other dimension is the hour of the day (with proportional spacing) — just like a weekly planner. Then for any given hour, we need something to represent how “popular” that time slot is for instruction. It’d be great if we had some way for closely clustered but non-overlapping sessions to contribute “weight” to each other, since it’s not guaranteed that instruction session timing will coincide precisely.
When I thought about analyzing the data in these terms, the concept of a heatmap immediately came to mind. A heatmap is a tool commonly used to look for areas of density in spatial data. It’s often used for mapping click or eye-tracking data on websites, to develop an understanding of the areas of interest on the website. A heatmap’s density modeling works like this: each data point is mapped in two dimensions and displayed graphically as a circular “blob” with a small halo effect; in closely-packed data, the blobs overlap. Areas of overlap are drawn with more intense color, and the intensity effect is cumulative, so the regions with the most intense color correspond to the areas of highest density of points.
Heatmap example from my previous work, tracking touches on a touchscreen interface. The heatmap is overlaid onto an image of the interface.
Part of my motivation for using heatmaps to solve our scheduling problem was simply to use the tools I had at hand: it seemed that it would be a simple matter to convert the instruction data into a form that would be amenable to modeling with the heatmap software I had access to. But in a lot of ways, a heatmap was a perfect tool: with a proper arrangement of the data, the heatmap’s ability to model intensity would highlight the parts of each day where the most instruction occurred, without having to worry too much about the precise timing of instruction sessions.
The heatmap generation tool that I had was a slightly modified version of the Heatmap PHP class from LabsMedia’s ClickHeat, an open-source tool for website click tracking. My modified version of the heatmap package takes in an array of (x,y) ordered pairs, corresponding to the locations of the data points to be mapped, and outputs a PNG file of the generated heatmap.
So here was the plan: I would convert each instruction session in the data to a set of (x,y) coordinates, with one coordinate representing day of week and the other representing time of day. Feeding these coordinates into the heatmap software would, I hoped, create five colorful swatches, one for each day of the week. The brightest regions in the swatches would represent the busiest times of the corresponding days.
Arbitrarily, I selected the y-coordinate to represent the day of the week. So I decided that any Monday slot, for instance, would be represented by some small (but nonzero) y-coordinate, with Tuesday represented by some greater y-coordinate, etc., with the intervals between consecutive days of the week equal. The main concern in assigning these y-coordinates was for the generated swatches to be far enough apart so that the heatmap “halo” around one day of the week would not interfere with its neighbors — we’re treating the days of the week independently. Then it was a simple matter of mapping time of day to the x-coordinate in a proportional manner. The graphic below shows the output from this process.
Raw heatmap of instruction data as generated by heatmap software
In this graphic, days of the week are represented by the horizontal rows of blobs, with Monday as the first row and Friday as the last. The leftmost extent of each row corresponds to approximately 8am, while the rightmost extent is about 7:30pm. The key in the upper left indicates (more or less) the number of overlapping data points in a given location. A bit of labeling helps to clarify things:
Heatmap of instruction data, labeled with days of week and approximate indications of time of day.
Right away, we get a good sense of the shape of the instruction week. This presentation reinforces the findings of the earlier chart: that Monday, Tuesday, and Thursday are busiest, and that Friday afternoon is basically dead. But we do see a few other interesting tidbits, which are visible to us specifically through the use of the heatmap:
Monday, Tuesday and Thursday aren’t just busy, they’re consistently well-trafficked throughout the day.
Friday is really quite slow throughout.
There are a few interesting hotspots scattered here and there, notably first thing in the morning on Tuesday.
Wednesday is quite sparse overall, except for two or three prominent afternoon/evening times.
There is a block of late afternoon-early evening time-slots that are consistently busy in the first half of the week.
Using this information, we can take a much more informed approach to scheduling our graduate students, and hopefully be able to maximize their availability for instruction sessions.
“Better than it was before. Better. Stronger. Faster.” – Open questions and areas for improvement
As a proof of concept, this approach to analyzing our instruction data for the purposes of setting student schedules seems quite promising. We used our findings to inform our scheduling of graduate students this semester, but it’s hard to know whether our findings can even be validated: since this is the first semester where we’re actively assigning instruction to our graduate students, there’s no data available to compare this semester against, with respect to amount of grad student instruction performed. Nevertheless, it seems clear that knowledge of popular instruction times is a good guideline for grad student scheduling for this purpose.
There’s also plenty of work to be done as far as data collection and analysis is concerned. In particular:
Data curation by hand is burdensome and inefficient. If we can automate the data collection process at all, we’ll be in a much better position to repeat this type of analysis in future semesters.
The current data analysis completely ignores class session length, which is an important factor for scheduling (class times vary between 50 and 100 minutes). This data is recorded in our instruction spreadsheet, but there aren’t any set guidelines on how it’s entered — librarians entering their instruction data tend to round to the nearest quarter- or half-hour increment at their own preference, so a 50-minute class is sometimes listed as “.75 hours” and other times as “1 hour”. More accurate and consistent session time recording would allow us to reliably use session length in our analysis.
To make the best use of session length in the analysis, I’ll have to learn a little bit more about PHP’s image generation libraries. The current approach is basically a plug-in adaptation of ClickHeat’s existing Heatmap class, which is only designed to handle “point” data. To modify the code to treat sessions as little line segments corresponding to their duration (rather than points that correspond to their start times) would require using image processing methods that are currently beyond my ken.
A bit better knowledge of the image libraries would also allow me to add automatic labeling to the output file. You’ll notice the prominent use of “ish” to describe the hours dimension of the labeled heatmap above: this is because I had neither the inclination nor the patience to count pixels to determine where exactly the labels should go. With better knowledge of the image libraries I would be able to add graphical text labels directly to the generated heatmap, at precisely the correct location.
There are other fundamental questions that may be worth answering — or at least experimenting against — as well. For instance, in this analysis I used data about actual instruction sessions performed. But when lecturers request library sessions, they include two or three “preferred” dates, of which we pick the one that fits our librarian and room schedules best. For the purposes of analysis, it’s not entirely clear whether we should use the actual instruction data, which takes into account real space limitations but is also skewed by librarian availability; or whether we should look strictly at what lecturers are requesting, which might allow us to schedule our grad students in a way that could accommodate lecturers’ first choices better, but which might run us up against the library’s space limitations. In previous semesters, we didn’t store the data on the requests we received; this semester we’re doing that, so I’ll likely perform two analyses, one based on our actual instruction and one based on requests. Some insight might be gained by comparing the results of the two analyses, but it’s unclear what exactly the outcome will be.
Finally, it’s hard to predict how long-term trends in the data will affect our ability to plan for future semesters. It’s unclear whether prior semesters are a good indicator of future semesters, especially as lecturers move into and out of the First Year Writing Program, the source of the vast majority of our requests. We’ll get a better sense of this, presumably, as we perform more frequent analyses — it would also make sense to examine each semester separately to look for trends in instruction scheduling from semester to semester.
In any case, there’s plenty of experimenting left to do and plenty of improvements that we could make.
Reflections and Lessons Learned
There’s a few big points that I took away from this experience. A big one is simply that sometimes the right approach is a totally unexpected one. You can gain some interesting insights if you don’t limit yourself to the tools that are most familiar for a particular problem. Don’t be afraid to throw data at the wall and see what sticks.
Really, what we did in this case is not so different from creating separate histograms of instruction times for each day of the week, and comparing the histograms to each other. But using heatmaps gave us a couple of advantages over traditional histograms: first, our bin size is essentially infinitely narrow; because of the proximity effects of the heatmap calculation, nearby but non-overlapping data points still contribute weight to each other without us having to define bins as in a regular histogram. Second, histograms are typically drawn in two dimensions, which would make comparing them against each other rather a nuisance. In this case, our separate heatmap graphics for each day of the week are basically one-dimensional, which allows us to compare them side by side with little fuss. This technique could be used for side-by-side examinations of multiple sets of any histogram-like data for quick and intuitive at-a-glance comparison.
In particular, it’s important to remember — especially if your familiarity with heatmaps is already firmly entrenched in a spatial mapping context — that data doesn’t have to be spatial in order to be analyzed with heatmaps. This is really just an extension of the idea of graphical data analysis: A heatmap is just another way to look at arbitrary data represented graphically, not so different from a bar graph, pie chart, or scatter plot. Anything that you can express in two dimensions (or even just one), and where questions of frequency, density, proximity, etc., are relevant, can be analyzed using the heatmap approach.
A final point: as an analysis tool, the heatmap is really about getting a feel for how the data lies in aggregate, rather than getting a precise sense of where each point falls. Since the halo effect of a data point extends some distance away from the point, the limits of influence of that point on the final image are a bit fuzzy. If precision analysis is necessary, then heatmaps are not the right tool.
About our guest author: Andreas Orphanides is Librarian for Digital Technologies and Learning in the Research and Information Services department at NCSU Libraries. He holds an MSLS from UNC-Chapel Hill and a BA in mathematics from Oberlin College. His interests include instructional design, user interface development, devising technological solutions to problems in library instruction and public services, long walks on the beach, and kittens.
Do you know what an infographic is? Infographics are visual representation of facts, tutorials, or other data-centered information that inform while staying focused on great design.
Here’s an example of one about the history of the iPad:
iPad infographic via http://killerinfographics.submitinfographics.com/
This infographic takes a whole mess of data and makes it visually interesting and easy to digest.
So, what do infographics have to do with libraries? Libraries have tons of data- both informational and instructional data ranging from topics like local history facts to how to do research. Take a look at this Google infographic recently posted on the HackCollege site: http://www.hackcollege.com/blog/2011/11/23/infographic-get-more-out-of-google.html
A snippet:
Google infographic via http://www.hackcollege.com/
This image highlights several complex research skills while explaining the thought process behind it in one easy to understand sentence, while being attractive and compelling to look at. What’s better than that?
Great examples of infographics can be found across the web. Wired magazine, for one, often uses them and Holy Kaw!, Guy Kawasaki’s website (http://holykaw.alltop.com) also highlights great infographics from other sites. Another great site to see examples of different types of infographics is http://killerinfographics.submitinfographics.com/.
The importance of infographics and other great visualizations of data (see Warby Parker’s 2011 Annual Report for the best annual report ever: http://www.warbyparker.com/annual-report-2011) to libraries is obvious. People respond to great design, and great design makes information accessible and inviting. It is in our best interests to strive for great design in all that we do, to make libraries accessible and inviting.
Recently, Sophie Brookover, New Jersey librarian, posted in the ALA Think Tank Facebook page (http://www.facebook.com/groups/ALAthinkTANK/) about starting a group of librarians learning to create infographics, much like the Code Year project. This idea is very much in the early stages, but keep an eye on it or get involved- good things are sure to come.