On Twitter recently, I was asked for advice about setting up a new one-person UX shop in a library. I’ve only recently emerged from the UX-shop-of-one world, thanks to the addition of a part-time UX designer to my “team” and am not entirely sure how much my experience yields universal insights. So consider the following caveats about how institutional differences will affect the usefulness of any thoughts I have about how to get started.
- How many people work in your library? Size of the library staff matters. If you are one of dozen or less people staffing the library, then your UX work is likely bundled in with other job responsibilities. Some libraries are large enough to support a whole unit or division devoted to UX (or at least web services, web oversight, etc.)
- How directly can you make changes to the website (and its attendant ecosystem services and resources, such as the link resolver, the discovery layer, subscription databases, catalog records, proxy server, ejournals knowledgebase, etc.) or to physical locations in the library where you want to work your magic?
- What is the culture of change in your library? Do proposed changes and new initiatives tend to get debated to death? Does everyone have to weigh in on decisions?
With those considerations, here are some suggestions for someone just getting started as the sole person with UX responsibilities (or a UX job title).
- Find your tribe inside and outside the library. In the library, look for people who are open to user-centered services or user-centered design so that you can have someone to bounce ideas off of. If that person happens to run a service or manage a resource that you’d like to do some design work on, all the better. Outside the library, you’ll want to find communities of people in libraryland who are interested in talking about UX work and communities that serve a broader UX professional audience. For me, this includes:
- Dive into “the literature” (I’ll only mention a few books, as there are dozens worth reading)
- Useful, Usable, Desirable. A great book about UX in libraries by Aaron Schmidt and Amanda Etches to get started with. Especially useful is the way the book is organized to help you assess all aspects of your library to help you identify where you might want to begin your design work.
- Rocket Surgery Made Easy. UX expert Steve Krug’s book about usability testing and design work.
- Don’t Make Me Think. A revised edition of a classic book by Steve Krug about UX and web design.
- Weave: Journal of Library User Experience. Open access FTW!!!
- LibUX. Check out the archives of this podcast and make sure you subscribe to it.
- Carefully gather evidence from user research and save it in a mindful fashion as you work on projects. It is essential to draw on this evidence when making formal proposals for some change you’d like to make. The more you can show your colleagues that design decisions can be driven by evidence and not whim, the more likely they’ll listen to you.
- Do usability tests on existing systems and services to identify and properly document problems.
- Learn as much as you can about project management, as a lot of UX design work is a multi-step process that usually involves your collaboration with colleagues who may not always see the big picture of the project.
Last fall, I was given the OK to hire a part-time user experience designer, which meant that my library’s user experience team was no longer a one-person operation. For the past four years, I’ve been working mostly on my own, although I frequently did projects that paired me up with others in the library (such as the time I worked with the head of access services to set up our new online reservation system for group study rooms).
One of the issues I’ve been working through over the past four months since I gained a part-time colleague is communication. Since it is no longer just me here, I need to be more intentional in sharing information. Although there are services to help you with project management in a team setting–things like Asana and Trello–I’ve found so far that a more low-key technology seems to be pretty good far: an internal wiki.
I’ve been using our campus’ wiki system from Confluence for many years now and feel pretty comfortable creating a new space there for the UX work my colleague and I are engaged in. In case it is useful to anyone else, I’ll share the set up.
First, there is a main page that lists all the projects in the pipeline. The project list is organized into high, medium, and low priority groups. Each project gets its own page. Each project page has these sections:
- The Problem. A quick statement of what problem we are trying to solve with our UX design approach. For example, on the project page for “Databases by Subject,” the problem is that the current page requires too much scrolling.
- Research Questions. As we start to dig into each project, we try our best to consider what it is we really don’t know but probably should if we hope to do the project in a way that aligns closely with user expectations. We want to make sure that we are questioning as many of our assumptions as possible. These questions will guide our efforts to understand our users before we get to the stage of producing high fidelity mockups. With the “Databases by Subject” page, the questions we have include things like:
- Which is better for users: an alphabetical list of subjects or chunking the subjects within broad categories?
- If we do use categories, what are the best category labels?\
- If we do use categories, should we still have an A-Z drop down menu on the page that simply lists databases by name?
- Design Ideas. At all stages of the project, we’re finding we have lots of ideas, both big and small, that may help us when we get to the mockup stage. This is a place to quickly note those. For some projects where it’s likely there is more than one distinct direction to go in, we’ll have a subsection of “General Design Principles” that apply to different options and a subsection for each specific option. For example, we are working on a redesign of the central search box on our home page. We’ve got a general principles subsection to specify things we should include and we’ve got subsections for the two main design options we have: a box with a drop down menu or a box with tabs on top.
- Milestones. This is a list of the main tasks we’ll need to accomplish. In Confluence, these can be styled as a proper to-do list, which I like because of the satisfaction I get from ticking off a check box once some milestone has been reach. I probably need to read up more on project management techniques to see if it makes sense to break this section out from the Project Timeline section that we also create.
- Project Timeline. This helps me get a rough sense of the flow of the project and think about how the deadlines align with the academic calendar, which is important as some changes we’d like to make are so major they really shouldn’t go live until the end the semester.
- Project Documents and Files. We’ve been using a shared Google Drive for mockups, usability test recordings, screenshots of other websites, etc. It’s easier to use Google Drive for this than to go to the trouble of uploading it all to the Confluence wiki.
- Sources of Evidence Used. This lists the evidence of user behavior that we will use throughout the design process. For a project we’re doing now to redesign the central search box on the library’s home page, the list includes Google Analytics event tracking data on use of the tabs on the existing search box; usability tests; and query log analysis. The items on the list may link to a new page just about that item if it is a big enough thing. That’s the case with usability tests, which are usually big enough endeavors to merit their own pages in the wiki; so, for example, we have a page just about the details of the initial usability test run last December on the central search box.
I’m hoping all of this project management work will help me when the time comes to make the case to various stakeholders in the library about the design change I’d like to make. Depending on the scope of the change being suggested, I may need to write a report detailing the research that went into the recommended design.
This system of using a wiki for project management has really helped us organize the work better. I suspect, though, that the “to do” aspects of it need some more work. I’d rather not use a separate system to manage that and hope to figure out more ways to use Confluence (for example, I haven’t taken advantage yet of the ability to tag people in Confluence with an @ symbol to assign them tasks). For now, though, I feel like we’re in a better place with this kind of shared documentation.