No Longer a UX Shop of One

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.