Service Design & Information Architecture
Building an adaptable, learner-friendly site for the world’s most-visited art history resource
ROLE
Project Lead
UX Strategy
User Research
Information Architecture
Database Design
Prototyping
Usability Testing
CLIENT
Smarthistory
TOOLS
Figma
Wordpress
Airtable
Optimal Workshop

I conducted research to deeply understand the needs of all stakeholders and validate the Smarthistory team's understanding of the problem at hand.

Sitemap of legacy site
Purpose
Understand the breadth of content to inform decisions for new information architecture
Understand how legacy information architecture facilitates or disrupts users' ability to successfully complete tasks
Understand users' needs
Understand other major sources of art history education to contextualize users' mental models
Understand how Smarthistory got to where it is today to be able to communicate with staff effectively
Identify immediate and longer-term opportunities for improving UI and UX site-wide

User interview session about legacy site
Diagnosis

Strategy

Entity relationship diagram for a relational metadata structure. Consulted metadata and taxonomy experts at The Met and Google Arts & Culture to confirm validity.

Sitemap for new information architecture

Affinity diagram of art history courses from 9 major university art history departments, used to prioritize syllabi to develop
Prototyping & Design

Testing a content page wireframe and navigation with a user participant

Implementation


Kanban workflow for art historians to review and confirm taxonomic terms

Table in Airtable base with content pages and metadata

Admin interface of WordPress showing artwork metadata. Many custom fields have bidirectional relationships, so that updates will be automatic on both ends.
View Live Site
Impact
What I learned
💡 When a big transition is underway, trust eases uncertainty.
“Move at the speed of trust” is something I hear again and again from folks who facilitate change; I’m grateful that this project went smoothly in part because of the trust that our team has developed over years of collaborating, and the trust that many of Smarthistory’s users have in our ability to meet their needs.
💡 Listen for what’s working, as well as opportunities for change.
It would have been a mistake to overlook what users said worked well and made changes that threw the baby out with the bathwater. What makes this project successful is its synthesis of the essential functions that make Smarthistory what it is and new enhancements that allow the very structure of the site to reflect changes in the field.
💡 Meet people where they are, even if different people are in different places.
This goes for both end users and for internal team members. Navigating change, whether it’s a new workflow, website, or way of teaching, means understanding where different people might be on a spectrum of readiness for change, meeting their present needs, and equipping them to evolve in time.
💡 Using metaphor and visuals can be crucial in helping bridge understanding.
This project crossed many different expertises: art history expertise, engineering expertise, taxonomic expertise, information architecture and design expertise. Using metaphors and visual representations created a common ground for understanding a vision of change that lived as an idea long before it became a reality.
💡 Design isn’t over after implementation begins.
Sometimes a designer’s role concludes after creating mockups or sharing proposals. Seeing this project through implementation reiterated that processes of implementation are another kind of experience to design with people in mind.
What I'd do differently now that I know what I know
Bring in developers much earlier to be a part of the conversation around how design ideas and strategies would be informed by technical constraints and foreseeable challenges. This would have enabled us to possibly avoid some delays because of the technical complications of some the features.
Do more thorough feature prioritization at the top. This would have helped lighten the load from the get-go, instead of having to deprioritize features that we were non-essential when dev time got tight.
Do fewer rounds of staff feedback on wireframes, and test high fidelity prototypes sooner to get faster turnaround on insights to iterate designs.
If there was time, incorporate open card sorting during user research to validate some of the labels.
© 2025 Kayla’s Portfolio. All Rights Reserved.




