During my time at Clarivate, I worked as a UX designer for the migration of utilities and pages from the older desktop client to the newer Polaris Leap browser platform. Polaris is a suite of products that public and academic libraries use to manage their inventories, complete administrative tasks, catalog, and facilitate patron services. My main responsibilities wearing this hat were meeting with Polaris product managers, learning about the utilities and workflows in the Polaris client and Polaris Leap, creating high fidelity prototypes that improve Polaris client workflows and translate them to the newer web version, present those prototypes and make adjustments based on feedback, and conduct user testing and interviews to validate prototypes and ensure they meet user needs.
I worked on a variety of pages and utilities in Polaris, from settings pages in the Admin portal to purchase order workflows. One exemplary flow I worked on was concerned with handling unlinked authority records, something catalogers especially deal with.
Cataloging is can get complicated, but the general gist is that authority records contain metadata for bibliographic records. This might be an author, or book title, a publisher, or other information. When a bibliographic record contains an authority record that's not in the system already, Polaris needs to make sure the cataloguer is aware of this so they can enter it into the system.
Currently, Polaris on the web doesn't allow users to take action on unlinked authority records. There's a warning pop-up that lists unlinked ones, but if the cataloger wants to resolve them, they'll have to do so in the client. This project's goal was to create the workflow and UI for taking action in Polaris on the web.
A workflow for this exists already in the older Polaris client, but it tends to utilize a lot of modals and pop-ups--sometimes multiple layers of them at a time--that would not be ideal for browsers. The new workflow would need to be done with minimal modal layering.
The actions that needed to be added to the browser were Find & Replace an unlinked record with an existing one, Create a new record using the unlinked one, Adjust Usage of the authority record in an existing one (the product managers and I were unsure what this meant, so we made sure to address this in testing!), and Leave Unlinked which was the only option already available in the browser.
For one, the product managers suggested an alert message that appears on the MARC tab itself once the initial alert has appear. The idea is that if you click out of the alert pop-up, the information is still there in case you want to manually change those records (or so you don't forget).
This type of alert message exists elsewhere on Polaris, so I repurposed that to fit this context. Simple enough.
For the alert pop-up workflow itself, I settled on a table with action buttons above format, as this is very common across Polaris. This paid off as the flow itself was quite intuitive to participants during usability testing.
The idea is that after selecting a heading, appropriate actions will become enabled.
In this case, Find & Replace and Create become enabled. The other two remain disabled because Adjust Usage requires an associated authority record to adjust the usage of and the record is already unlinked so Leave Unlinked would be redundant.
Selecting Find & Replace pulls up Polaris' standard Find Tool, wherein the cataloger would search for the record they want to replace the unlinked headin (i.e. authority record) with. Once they've done that, the Find Tool will close and return them back to the alert pop-up workflow.
The right column displays which action(s) was/were taken, and the middle column populates with the resulting heading.
The cataloger would do a similar step for each of the remaining headings, and selecting Continue when they're done.
The product managers recruited six catalogers from customer organizations and asked me to make sure the new workflow is able to do everything the one in the client can and get any other feedback from them. There were a lot of unknowns about user needs because the product managers weren't as familiar with this flow as others; luckily, having the participants run through the workflow is the perfect way to get that open-ended perspective-level feedback.
I created an as-realistic-as-practical prototype for the workflow as well as a testing protocol tasking participants to utilize each of the four workflow actions. Important also were follow-up questions for these tasks gauging user expectations and how they complete these kinds of tasks currently.
The following is the document of the analyzed results in the original format that I presented to the product managers:
Research/Testing Findings
Finding 1: Participants were unsure what Adjust Usage did
- Multiple Participants expected Adjust Usage to open the authority record so you could adjust information in it manually.
- One had the impression Adjust Usage alters the existing authority record that was selected and was confused, feeling it was strange the existing authority record should be altered.
- In general, participants felt the label was vague and unclear.
- Participants expressed a need or potential need to edit the authority record directly when dealing with unlinked headers.
Recommendation 1: Use the Adjust Usage action to open the selected authority record, or replace Adjust Usage with an action that does
- If an existing authority record has been selected, that will be the record opened. If an authority record will be created from the unlinked header, that would be the record opened; but note that the workflow currently doesn’t create that record until the user clicks Save to close the Check Headings Assistant. So either Adjust Usage should be disabled when a authority record needs to be created, or selecting Adjust Usage will trigger the record creation early.
- The authority record could open either immediately upon selecting Adjust Usage, or after selecting Save. The latter is more in consistent with how the workflow generally works, but the former might make more sense and fit better with user expectations. It may not be ideal to jump the user to another record after selecting Save.
Finding 2: One participant wanted to select multiple headers at once
- The participant’s use case is for libraries that usually create a new authority record rather than use an existing one. The assumption is that they will want to create a new authority record for each, so being able to select multiple and pick that action for all would be less tedious than applying the action separately for each.
Recommendation 2: Include multi-select functionality for headers
- This makes sense for Create and Unlink actions. It makes less sense for Finding & Replace and Adjust Usage, so those actions should probably be disabled.
- The Check All checkboxes have been added to the latest mocks to suggest multi-selecting is possible.
Finding 3: One participant felt a designated confirmation view after saving CHA progress would more clearly communicate what actions have been performed by the system
Recommendation 3: Consider adding a second page to the modal that, after selecting Save on the first page, lists the headings and what actions have been completed for them
- See Frame 3411 for what this confirmation view could look like. Basically, a table with one column listing the headings and the second column the corresponding status for the heading; e.g., “Record successfully created” for a heading whose selected action was Create.
- Because the other three participants seemed okay with just having cheers banners, a confirmation view isn’t necessarily necessary. One important thing to note is that the cheers banners in the prototype for that session only appeared for 10s before disappearing, so it’s possible the participant wouldn’t have felt their was an issue if the cheers banners were visible for longer/until manually closed.
Finding 4: One participant felt the Continue label suggested there was more to the workflow, and did not make them feel confident the system had saved the changes in the bibliographic record.
Recommendation 4: Relabel “Continue” in the CHA to “Save”
- This has already been done in the most recent versions of the mocks.
Finding 5: Participants expressed general pain points and wants for working with authority records
- For example, one expressed a strong desire for the ability to merge two items within the find tool view of authority records.
Multi-select is an easy add from a UI perspective--added a 'select all' checkbox in the top row.
From a UX perspective, it's also simple so long as the software engineering of the site allows linking two or more unlinked headings to one authority record, which seems to be allowed given the base flow in the client allows this.
The standard validation on Polaris is to display green banners. In the prototype these disappeared after 10 seconds, while on Polaris they disappear after a longer period of time. One participant didn't notice these banners in the prototype before they disappeared and as a result felt there wasn't enough feedback on the processes completing--e.g. a record being created.
One suggestion was creating a confirmation page for the workflow that lists all the completion or error messages for the actions that involved record creation or modification. I did create a mock for this, but ultimately the banners made more sense as the direction to hedge in because they're already the standard, something catalogers will expect to see.
First, the Adjust Usage action was renamed to "Open Record" to reflect more clearly what it will do. As for the flow itself, there were a few important things to consider.
The intention of the workflow was to not carry out any actions until selecting the Save button, at which point the authority records are created and/or changed. When a cataloger makes changes to a record when they open it using the Open Record action, are those changes saved right away, or pended alongside other changes? The latter is more consistent with the workflow while the former is more consistent with the rest of the site. Similarly, if a cataloger wants to create a record from the unlinked heading, they may want to open that record and make changes right away. When they do this, is that record created now, or does it remain pending alongside any new changes? And finally, what if a cataloger makes changes to a record but then changes their mind about how to handle the heading?
Unfortunately these questions require information only people familiar with the technical back-end part of Polaris know, and I was not able to get this information before my internship ended. From a UX perspective, however, we can still consider the trade-offs between either option. In the prototype I went with all record changes being pended until selecting Save to maintain flexibility in taking action. This required some warning messages when the cataloger has made pending changes and then selects a different action that would clear those changes, so that catalogers know the work they've done altering records will be erased if they proceed.
Here's a link to the prototype, if you're interested in seeing the edited flow yourself:
Polaris UX projects tended to be lightweight and fast moving. Part of this is just the way of the business-side of things works out, of course, but also because many of the UX changes were translations of workflows that exist in the client. For the purposes of Polaris projects at Clarivate, the UX part of this would be done at this point and efforts would shift to a new project.
The prototype and other mock-ups here were handed off to the product designers, who would then present them to customers and hand them off to developers to build out and package into the upcoming release.
.png)
