Case Study: Faculty Database

Streamlining the profile editing experience for a faculty database

Includes: usability testing, wireframes


Scholars@Duke is a database intended to centralize information about all of Duke University’s researchers, including faculty, academic staff, and graduate students. Although profiles are created automatically for faculty members, manual editing is still necessary to complete and curate most of the information included. The profile manager interface had been developed ad hoc over the years, with new fields and features added as needed. Increasing the complexity further, it also pulls data from a variety of sources: some fields can be edited directly within the system; others have to be edited in different places, such as a publications management system and a course database; and others can’t be edited by the faculty member at all, but may be hideable. Overall, the editing experience was due for some attention, and when another batch of new fields were slated to be added, the Scholars team decided to take the opportunity to step back and re-envision the whole thing. I was brought in to consult on the user experience for the profile manager interface.

existing editing interface






This project started with a research / pre-testing phase, during which I talked with the clients, attended a series of focus group lunches and interviews that they were running, and reviewed notes from existing research to learn more about the audience and their needs.

I also ran baseline usability testing on the existing interface with a few faculty members, asking them to try making a series of representative types of edits to their profiles. At one end of the user spectrum in this testing, I worked with a participant who found the profile manager totally overwhelming, to the point of having a hard time knowing where to begin with a given task. At the other end was a participant who felt much more confident, but still had trouble finding the right places to make specific types of edits due to the overall busyness of the interface.

Based on this initial information, my goals for the new interface were to make it easier for users to get a sense of what options were available and to reduce the likelihood of them feeling overwhelmed by making the page more consistent and scannable.

Before moving ahead, I also checked out the profile management approaches of several popular websites for inspiration. Facebook’s approach, which groups fields together thematically and provides navigation among the groupings, seemed like a promising model for the amount of information we were working with, and I incorporated those ideas into several of the wireframe variations we looked at.


In the initial round of wireframes, I was working with several ideas that all relied on grouping fields together under scannable headings, so my first step was to work through the field list and come up with a preliminary grouping schema. I drafted sample wireframes reflecting several different layouts, then met with the clients to discuss the options.

option 1: all fields [truncated]

option 2: expandable category sections

option 3: left navigation

option 4: index page linked to category pages

The Scholars team was on board with the idea of grouping the fields, but they wanted to work on a revised grouping using their subject matter expertise. They spent some time on that and then sent me an updated category list, which added a second level of categorization. At that point, they also selected one layout variation for us to pursue (version 3, which used a left-hand category navigation inspired by Facebook).

For this next round, I created some variations that explored how the field groupings might play out within the preferred layout. The Scholars team also brought up the idea of navigating by field instead of by category, so I included a variation based on that idea.

navigation by subcategories

navigation by top-level categories

field-by-field navigation

I worked with the Scholars point person on the project to keep developing those ideas, and we ended up with two approaches that we wanted to test.

Usability testing and recommendations

To get ready for usability testing, I built out the wireframes so that all of the views needed to complete the tasks were represented and rewrote the testing script to cover both layout variations. For each session, we went through a list of tasks with each version (changing up the order to account for bias introduced). From the testing, it became clear that the field-by-field version was easier to navigate. We also accumulated a list of potential field name and grouping changes to refer to the Scholars data team.

To finalize the wireframes for the development team to use, I added in some sample interactions to demonstrate things like form behavior. I also put together a document listing out the full set of fields and pointing to which wireframe each field’s edit screen would be modeled after.


The final plan for the editing interface provides users with a way to scan all of their options without feeling too scattershot or overwhelming. The category headings were key to helping users orient themselves within the list, but listing out each field helped give them confidence that they were editing the right thing. Usability testing was important in this project to assess whether users would find the interface manageable as well as being able to navigate it easily.

final layout, "publications" field view

free text field

structured field

non-editable field

list edited elsewhere

non-editable list

manually entered list

▲ Top