The Catalyst Tools were a suite of nine web applications we designed and developed at the University of Washington to bring its activities online. The tools enabled electronic grade submission, surveys, website creation, discussion boards, homework submission, and more for anyone affiliated with the university. With roughly 100k active users, these tools were widely used across campus in a variety of contexts.
GradeBook enabled instructors to manage grades and share them securely with students. Collect It provided easy homework submission online.
CommonView allowed users to create simple and customizable websites with a drag and drop interface.
As the design team lead and project initiator, I played many roles on this project. In addition to being the primary contributor, I advocated for the scenario-based approach we took and was ultimately responsible for getting stakeholder buy-in.
To draft the initial personas and workflows I worked with another designer across a number of whiteboarding sessions. Similarly, the exploration of different concepts was done collaboratively. We then split the documentation work. I evaluated the concepts by comparing how well they allowed our personas to complete defined tasks and avoid potential pain points.
The Catalyst Tools were developed one at a time and in response to specific needs on campus. While each independent tool worked well for its intended purpose, people were struggling to use them together in a coordinated way. Designs differed, access was configured differently, everything had to be set up separately, and they did not work together. This was tedious. Why did our most advanced and dedicated users have to work so hard to use our tools? I knew we could do better.
The steps required to use multiple tools together were numerous. Note the green section needs to be done for each tool added to a workspace.
To better understand the context where people experienced problems we began by focusing on three typical use cases and personas. Our first persona was a faculty member, the second a researcher, and the third was administrative staff. Based on years of support emails, interviews, and teaching workshops we knew these were the most common audiences and workflows associated with their role.
Personas and Workflows
These personas and workflows provided three important elements that allowed us to move forward with our work:
- a shared understanding of the problem space and target users
- a common language for the team to use when working through designs and concepts
- key user goals and tasks to use as evaluation criteria for future designs
Explore and Validate Models
Through numerous, whiteboarding sessions we decided to explore three different models of integration. This was important because it forced us to think through how a concept could actually work before evaluating it against the other concepts. In other words, it helped us avoid falling in love too quickly with our first solution.
Concept 1 maintained the separate tools, but centered around better integration points. Basic settings like access rights and custom headings would cascade from one tool to another. This concept represented the least amount of change from the status quo.
Page flow diagram for concept 1
Concept 2 explored a very different paradigm by combining all the functionality of the tools into a single tool, essentially turning the tools into functional components. Access management would be centralized and usage logs would be consolidated.
Page flow diagram for concept 2
Concept 3 explored the possibility of grouping tools together around groups of people. Each group and class list would have a space pre-made where users could add content and functionality. While the final workspace wouldn’t have been that different from concept 2, the way users would need to approach it was the exact opposite.
This model never made it off the whiteboard as it suffered numerous problems. After trying to use it to go through our three use cases it became clear that this was not the right approach, despite it having a certain appeal of turning the problem on its head.
Some of the problems we ran into:
- Biggest change from existing behavior would mean current users would have the hardest time learning it.
- Using the same set of people in multiple context would be confusing.
- Assigning group of people (i.e. TA’s) as administrators in another group (i.e. a class) would be confusing.
- Did not match our users’ mental model.
Evaluating Concepts 1 and 2
After eliminating concept 3 I evaluated and compared the merits of the two remaining concepts by simply walking through them with both the persona characteristics we had defined and the individual tasks involved in their workflows. I also compared these to the status quo. As designers and builders, I think it is sometimes easy to forget there might be value in not changing anything at all. The tables below were not meant to summarize or present the findings, but they were a useful tool for systematically thinking through the concepts and understanding the pros and cons involved in both.
This processed helped me decide that a single tool (concept 2) would best fit the needs of our audience. Having a single tool with centralized management would make many tasks easier, such as copying and transferring the tool to other people. It would also be easier to learn for new students and employees. Additionally, moving towards this model meant less design & development work would be required for each new piece of functionality.
I presented this work and my recommendation to the technology director and program manager and successfully received their approval to move forward. After I left the UW, the user scenarios and strategy we developed continued inform their work for some time.
Read more about the Catalyst Tools at http://itconnect.uw.edu/learn/tools/catalyst-web-tools/web-tools-account/