Britannica School, Cover

Project Name: 
Britannica School

Development Method: 
Agile

Software: 
Axure, Indesign

New Key features: 

  • Access Across Tiers

  • Differentiated Interface

  • Integrated Search Results

  • Favorites/My Content

  • Lesson Plans

  • Responsive Design


Encyclopaedia Britannica is an international media company that creates consumer, corporate, and institutional products. Launched in the early ‘00s, Britannica’s flagship product, Britannica Online Learning School Edition (BOLSE), was a digital encyclopedia serving academic users in the K-12 space.

I lead the research and design for a rebuild of BOLSE (rebranded to Britannica School). Goals for the rebuild included:

  • Create a inclusionary culture of user-centered design in the company

  • Connect editorial, sales, and development groups to end users

  • Update the technology powering the product

  • Increase the findability of articles and features

  • Increase product usability

  • Increase ability to find and use content across tiers

  • Introduce new features to address uncovered user problems

  • Use across device types (responsive design)

  • Update visual design

Bench marking and Generative Research

Our initial research was focused on bench marking the existing site and generating new research about our users.

  • Competitive analysis

  • Analytics analysis (google analytics)

  • Secondary research (device types in schools)

  • Heuristic evaluation

  • Stakeholder interviews

  • User interviews

  • Site visits

  • Usability testing for bench marking

Due to the massive amount of research we aimed to conduct, I trained a crew of project managers, designers, and developers to help conduct users interviews.

In addition of being able to simply finish the research, asking others to help had the benefit of engaging people internally. Those who spoke to users often shared their experience with other employees. People I hadn't met frequently  approached me to ask questions about what they heard. 

Collaboration, Communication, and Sharable Insights

In order to create a method of internal feedback and buy-in, I created a cross-functional group of editors, sales people, c-levels, and developers. While research was occurring, I held weekly meetings to discuss the findings and created short, shareable nuggets of content to share as soon as possible

Findings and Artifacts

After all data was collected, I mined it all to find all the patterns. From this, I created a set of high-level findings, artifacts about our users, and design recommendations.

Findings

  1. The search results were a major hindrance for users.

  2. Individual ability to complete core tasks (such as finding a specific article or a list of all bird types) varied wildly, with many users unable to complete the tasks

  3. Students deride others who needed to use “kiddie” websites

  4. Educators look for content that can be used for a variety of learners as reading levels aren’t consistent within one class.

  5. Many types of supplemental materials are needed, such as games, photos, videos, and other activities, not just articles

  6. Educators typically edit materials in order to tailor it to their specific needs.

  7. Users often did not know they had access to BOLSE

 

Artifacts

Core Interactions

Persona Example

User Wants and Needs by User Type

 

Recommendations

Design Recommendations

Design Iterations and Evaluative Research

In this phase, I created problem statements and user tasks specific to each section, then conducted brainstorming sessions to generate ideas.

Then, I created rough page concepts and presented them to a the developers and engineers who would build the product so that I could understand legacy requirements, technical restraints, and the feasibility of certain designs.

Once it was determined a design could be implemented, my team (2 - 3 interns) and I created a interactive prototype for testing, incorporating the all needed features and content. We used Axure for all prototyping.  

A few prototypes used for testing

Each prototype was tested with 5–6 adult users and 3–4 younger users, using the same tasks used for evaluation in the research phase. All testing was moderated and occurred in person.

I presented the research findings to and solicited feedback from the same cross-functional group mentioned previously.

As the testing progressed, we adjusted the designs to account for findings. In total, I ran approximately 50 tests, each ranging from 45 to 90 minutes.

 

Final Designs, Development, and Launch

Final Designs

Development

Once the development sprints began, I became part of the development team, helped write user stories and technical specifications, and participated daily scrums and retrospectives.

This was my first agile development project so integrating design into agile was very new to me. We planned each design cycle (research, design, validate) 2–3 sprints ahead of development in order to allow for time to iterate, as needed.

Beta and Launch

The beta was launched to our users in August 2012 . Once launched, we conducted usability testing, monitored analytic data, and intercepted users (surveys) to determine if our goals were being met.

In total, I tested the beta with 20 users (6 teachers, 8 librarians, and 6 students) and collected survey responses from 200 users. We used this data to tweak certain parts of the site to improve usability.

 

What I Learned

Context is Key.

This was my first time leading the research and design of a large-scale project, and the importance of consistent user feedback became immediately clear to me. I established weekly check-ins (any user, any location) and monthly site visits (mostly Chicagoland area) in order to maintain a strong connection between our team and our users. We discussed overall feedback on the tool, tested new designs, and conducted in-depth interviews.

During one session, I noticed students leaning over and looking at the computers of their neighbors. I asked the teacher about this behavior, assuming she’d mention something such as lack of attention as the problem. Instead, she said students often tease each other if they think another student is looking at something that is “kiddie.” She strongly believed that this chiding led the targeted students to be less interested in the material and, ultimately, to a lessened understanding of the particular concept.

We hadn’t really discussed the social nature of our product before so I brought this back to the team. We decided to simply validate this issue as time permitted. The feedback we began to receive, however, was overwhelmingly agreed with the original teacher. So, we decided to tackle the issue.

We brainstormed ideas with the development team, and our solution allowed students to change the content while maintaining the initial UI. This allows students to adjust their reading level, without others noticing the change, as all the UI would be the same (no “kiddie” look and feel).

While we initially thought this would be an interesting feature for a small section, it quickly became clear in the beta phase that this would be a defining feature of the product. But if we hadn’t had regular, in-person contact with our users, it’s highly likely that this problem might never have been identified.

This was somewhat of an epiphany moment in my practice. I’d been heavily involved in research before, but it was mostly evaluative — testing ideas, features, and products after they’ve been created or explored. This experience gave me goal of incorporating many more methods into my daily practice, as well as a powerful desire to create strong, fluid channels for user feedback. As a result of this project, I strive to have a research practice that is diverse, constantly evolving, inclusive of all users, and highly values behavior over first-person feedback.

Your team is everything.

I also learned the importance of creating cross-functional teams, communicating, and relying on your teammates.

This project was monstrous, and I couldn’t possibly have been involved in every idea or decision. My goal, therefore, was to explain the underlying tenets and goals we uncovered, keep in constant contact with the project managers and developers, record decisions in one place, and trust in the team.

Not only did I learn how to be a better team member, my way of communicating also changed. Now, my process is much more ground-up, involving everyone (from developers to users) from the very beginning.
 

Video: Final Product