Summary The Design Lab and SAP co-designed an online resource community to help university faculty facilitate design-led classes. By providing this support, we aimed to increase student exposure to design thinking.
Contributions As a User Researcher, I helped with conducting user interviews, journey mapping, storyboarding, and rapid prototyping.
Affiliations UC San Diego Design Lab, SAP
While design thinking is highly praised in the industry, college graduates aren't always proficient with the mindset. From interviewing stakeholders to drawing prototypes, most design thinking steps are about hands-on practices -- something that the traditional, exam-based classrooms lack.
How do we provide students with these design opportunities? From our research, there are many alternative pathways to take -- from DFA to hackathons and more -- however, not all students can afford to partake in them. For this reason, we shifted our focus onto convincing educators to provide these opportunities within classrooms.
For educators who are used to teaching a lecture-based classroom, transitioning to a project-based pedagogy can be difficult. In fact, it's reported that it takes almost 3x the effort; this includes creating project prompts, planning grading rubrics, and more. With this constraint, we asked: how might we make this transition easier, such that educators can effectively run a design-led classroom?
Before betting what would make the transition easier, we wanted to understand what goes into course planning. With 5 in-depth interviews and 3 days of participant observation, here are what we consistently observed:
Looking at our observations, one thing became clear: quality resources can help faculty in teaching and course-planning. Naturally, our seed idea was a holistic resource kit. We started with a persona, created her journey map, sketched some rough wireframes, and considered how this kit would tie to our users' overall journey.
Celia Reid is a Professor of Computer Science at a large university. She is well-connected and tech-savvy; she cares about her students and works well with her TA's. Celia is familiar with how to manage a design-led curriculum, although she's not an expert. She's open to experimenting the way she runs her classrooms; however, with her busy schedules, it's only realistic if planning for the experimentation isn't time-consuming.
After we iterated on the user journey with feedback from faculty, we started brainstorming elements that would satisfy/better each experience moment. Overall and briefly, here are some insights:
Our bet was this: if we can provide reputable resources and a trustworthy community to support faculty in running a design-led classroom, then they will be convinced to try it out, resulting in students learning practical, design thinking skills. The key was to show that it is well worth the effort to transition from a lecture-based to a design-led classroom. The result of our ideation was a platform that not only provides these resources, but also connects educators together, where they can share their stories and engage in discussions. Particularly, we used a cookbook metaphor -- in which educators are chefs and resources are recipes; by integrating these recipes and curating the flavors, educators can successfully brew a design-led class.
We card-sorted some recurring concerns we heard from faculty. Three themes emerged:
How should we name these categories? Initially, we named them lessons (lessons to teach in class), methods (management methods), and courses (example courses) respectively. However, users reported that 1. they thought methods meant "design thinking methods" and 2. they were unsure of what lesson meant. Additionally, we also considered naming classroom management as tips, but that was rejected because some faculty mentioned its negative connotations. For those reasons, we finalized the names to methods, class management, and courses; users perceived them well.
What should go on these recipes, exactly? We focused on the experience map and looked at the elements that would satisfy/better each moment. In the wireframe, elements that would address the top-rated concerns by users are placed towards the beginning of each recipe. Furthermore, elements that are of "quick-facts" (labeled with an orange dot) are placed in the side column -- this was to separate them from the content that users would spend more time on, in the main column.
Each category page was intially placed on the navigation bar as a "one-click-away" way for users to locate certain recipes. However, some users reported the uneasy feeling of having too many tabs on the navigation bar; this drove us to minimize the design:
To consolidate the different ways for users to locate a recipe (besides using the navigation bar), we took inspirations from various sites including Yelp. Primarily, we wanted to see 1) how different sites help users find what they're looking for, 2) how these sites organize massive amounts of content cards.
The Design Lab hosted a 3-day workshop with 20 faculty from all over the States for proof of concept. We explained the value of design thinking, facilitated human-centered design workshops, and introduced the Cookbook project. By day 3, many faculty expressed their interests in starting a design-led classroom.
I see myself using Cookbook. So far, our course planning process is sometimes so scattered... we'd hunt around on the internet for information, ask around to see if other faculty might know something... knowing that this site provides a good chunk of relevant information really helps.
- UCSD faculty at the Jacobs School of Engineering
Speak the language of your users.
When we started working on the cookbook idea, we referred to it as a "kit of teaching tips," until one user pointed out our terminology could compromise our credibility. "Educators, at least myself, don't like it when people see what we're doing as 'tips and tricks,'" he explained, "we're putting in so much effort to make sure our classes run smoothly. I feel that simply calling it tips doesn't do our efforts justice." We calibrated our word choice afterwards; it was an important reminder for me to be mindful of the impact words could have on our users.
Keep a physical log of questions for user testing.
Throughout the process, there were multiple instances when we needed to validate our hunches with the users. Would this design be too invasive? How effortful is this user flow? I found it helpful to keep a physical record of these questions, such that we wouldn't forget to ask them when we finally crammed the user testing guide.
Finding the balance between being creative and standing behind usability can be tricky.
When we worked on visual design, we'd sometimes have to compromise our want for something "nifty and minimal." Some designs simply did not meet the usability heuristics. The conversations usually went like this:
A: "We can do it like this! XX company does this, too."
B: "It's a little unconventional. I had a hard time figuring out what that feature was. I don't think this is the way to go..."
C: "Wouldn't it be delightful, though, once the users figure it out? It doesn't seem like it'd take too long to learn what this means."
When in doubt, I found Nielsen's 10 usability heuristics a very helpful guide. Evaluating the clarity of signifiers also helped us find that balance. My take is this: rather than expecting the users to click or hover around to discover an otherwise unknown function, make sure the design communicates that function.