UX case study: New York Public Library’s “Three Faiths” online exhibition
Wireframes bring people together
This project describes an important lesson I learned during my time as the UX Designer for the New York Public Library. In order to get everyone on a project — particularly designers and stakeholders — to agree, you have to provide common ground for everyone to meet on. For this project, that common ground was the creation and joint development of wireframes.
Challenge
Early in my role as UX Designer for NYPL’s digital team, I observed that the design process was to present stakeholders with finished, high-fidelity designs, and tweak those designs based on stakeholder feedback. While the designs looked impressive, any corrections that needed to be made took a lot of time between iterations. Also, corrections tended to be based on whether stakeholders liked the graphic design, and not whether the interface was effective. We never talked about user needs.
I suspect this workflow was a holdover from when the design of NYPL.org came from not a dedicated digital team, but rather from the graphic designers in the Communications department (who were also responsible for printed materials and signage). We were using a print process to design a digital experience.
In this case, the digital experience was a companion site for a major physical exhibition: “Three Faiths: Judaism, Christianity, Islam.” The exhibition featured manuscripts from the Library’s world-renowned collections, in particular the Hebrew Xanten Bible from 1294, the Harkness Gospels from around the year 900, and the Qur’an completed by Husayn ibn Hasan in 1333.
NYPL’s collections curators are scholars who have earned their expertise over years of study — and do not always trust that their collections will be accurately represented by a team other than their own. (An older colleague mentioned to me right before the first meeting for this project that working with the curators was historically…fraught. Neither group seemed to really get the other.) The challenge, therefore, was not only to present a compelling website that was more than just a brochure (we wanted patrons who could not visit the physical exhibition to experience its value) but also to get the team responsible for building that site to work together well.
Solution
I knew that in order to collaborate, each person needed to have a stake in a shared motivation. At the time, wireframing (and UX practice in general) was relatively new, and I took the opportunity to introduce wireframes to our process. During the project kickoff meeting, the curators described their content needs to the entire team. Everyone got to ask questions and talk about how their particular discipline (design, coding, content) fit together.
Based on this conversation, I developed a first draft of the site in low-fidelity wireframes. At every subsequent meeting, I displayed the wireframes to the full team on a big screen and we all participated in developing the design (which increased in fidelity at each iteration). After every meeting, everyone received a PDF of the latest wireframe.
What had previously been weekly stakeholder check-ins became working meetings, where I led the group through each iteration. The wireframes I created helped facilitate agreement between the high-level stakeholders on the project.
Result
We were able to achieve a universally approved and functional design. Rather than simply approving finished designs, the stakeholders were part of the design process, and therefore felt a sense of investment and ownership.
For this project, the design process was no longer a disjointed guessing game but a conversation — and because it was a conversation, everyone was able to learn from each other. The entire group developed the content and the design together, aided in seeing how content related to the user’s experience of it by the wireframes. Wireframing allowed interactivity and user flow to be developed without the constraint of final graphic design. Because wireframes illustrate what content will look like in context, everyone was able to comment from their particular perspective (for example, developers cautioned against a design that was challenging to build in the CMS). Finally, those various perspectives learned to have empathy for each other. The stakeholders in particular were welcomed for the first time into a process that demystified design and web development.
