Wise
Wise is designed around people—both library users and library staff—with the goal of delivering great experiences and enabling libraries to reflect the needs of their communities. Wise is a holistic system that helps anticipate customer needs and reach them more effectively. Simply put, Wise is a platform for libraries to manage customers, catalogues, ordering, budgeting, and anything else they may need.
Employer
OCLC
Years
2023 – 2024
My Role
UX Research, UX Design, UI Design, Prototyping
Scope of work
As a user experience designer on the Wise team, I was involved in many different product enhancements. Some of the work featured here involves collaborative work with colleagues as well as individual contributions.
Problem Statement
How can Wise provide a better library experience both for staff and for patrons. How can the legacy Wise client software be updated into a modern web console to both improve the visual design and enhance user experience.
Acquisitions
Acquisitions involves many specific library staff tasks. Primarily these tasks are ordering, managing vendors, and budgeting. The work I am sharing here will tell the story of how all of these three needs work together and impact each other in the Wise ecosystem.
Navigation Enhancement
Acquisitions Dashboard
The first problem we identified early on was how we were going to fit ordering, vendors, and budgets into the already overloaded top nav. It wasn’t in scope to consider a full top navigation restructure or new site mapping strategy. What we came up with was an acquisitions dashboard—essentially a home base for all work in the acquisitions space. We added a dropdown to the top nav that nested all three new tools under a single heading, and provided a central hub for future acquisitions features like acquisitions-specific analytics and task tracking.
Old Nav vs. New Nav
Acquisitions Dashboard
Case Study 1: Acquisitions
View Vendors
The current client experience can be cumbersome at times. It’s a nested menu based navigation on the left-hand of the screen, with the information hierarchy not clear or intuitive. This often means unfamiliar users must dig around until they find what they need, often in locations that aren't obvious. For this first stage of adding vendors functionality to the console, the ticket is for “view vendors” only, with vendors still being manage on the client side while that information will populate in a view-only format on the console.
Current client
Explorations
We explored several new ways to approach organizing vendors. Currently a user must add a vendor to the central vendors table, and then navigate to their institution and add them again. And a single vendor will sometimes have multiple accounts. This is to help organize accounts, as some are dedicated for specific purchases or dedicated to specific uses.
The initial approach we took was grouping all of a vendors accounts under a single vendor entry. If the user has 5 different Baker & Taylor vendor accounts, lets nest them all under the same vendor entry. Explorations included both split views and a two screen, card-based approach.
Key Insight
“Most of the time, users are accessing a vendor to look for contact information.”
Refining Explorations
We were armed with new knowledge after early rounds of user research and talking to staff. Library staff users are almost always going to a vendor entry to find contact information. In fact, this is the primary reason multiple vendor accounts even exist. The current client system only allowed for a single contact entry per account.
Opportunities:
Adding multiple contacts per account
Allowing user to select one of those contacts as primary or default to browse contact info faster
Returning to a split view to reduce clicks in search of vendor contact info
Split View Exploration
We returned to exploring a split view as a list rather than a carousel. This was a better use of space and gave the user an opportunity to find their preferred vendor, then account, then contact information as fast as possible.
Roadblock
“We can’t change the current client information architecture. Accounts must remain separate for now.”
Adjusting Course & Final UI
The scope of this work was adjusted and our IA team made use aware that it would involve too much work for this particular ticket to change the way the system organizes vendor accounts. We still felt the list-view exploration was the best solution for the user’s primary needs and continued forward with the same design, slightly adjusted to fit the new constraints.
Mapping the current user flow
Case Study 2: Acquisitions
View Budgets
Creating and managing budgets in the existing client is, like vendors, quite unintuitive. There are over 20 clicks before the user even gets to setting up their budget year and branch. Navigating the multiple steps to setting up a budget means there is almost as much hassle when viewing allocations within a budget’s funds.
Current client
Explorations
We began exploration off of the back of the vendors work, asking if we could repeat some of the structure and design patterns we developed for vendors to create a sense of parity among the budgets module.
Budgets vs Funds
Users will set a budget, typically for a fiscal year, and then create one or more funds. Thinks of funds as buckets of money. Each branch will typically have a different structure, but common ways to think about funds are for material type, genre, and collection. So the user needs a way to view the currently active budget, get a general sense of spending, but also drill deeper into a particular fund to see data about their available funds, transaction log, and setting up “fund automation rules” which relate to the ordering process.
Funds display various status chips and color indication when they reach various thresholds to alert the user at a glance that a fund is nearing capacity.
General Tab
Users commonly dive deeper into a fund for a few reasons, but the primary reason is to take a closer look at how the fund allocations are being used. The general tab opens with a more detailed breakdown of spending, showing both encumbered funds, funds that are fully transacted, and the remaining available.
Transactions Tab
Users commonly dive deeper into a fund for a few reasons, but the primary reason is to take a closer look at how the fund allocations are being used. The general tab opens with a more detailed breakdown of spending, showing both encumbered funds, funds that are fully transacted, and the remaining available.
Fund Adjustments
Deeper in the transactions tab, users are enabled to make adjustments to funds. These can be increases, decreases, and transfers to a fund. This is due to budget shifts during a fiscal year and the need to reallocate the money in a budget. Registering acquisitions can also happen here, which is a roundabout way to log a transaction that for some reason happened outside of Wise, so that it can be logged to properly reflect the current fund spending.
Finalizing UI
After final final scope reductions in the preferences tab, the work for view budgets began wrapping up. Here are some shots of the final UI.