Readers of Mobius blog posts one and two in this series know that I was teaching a class this Fall in the VCUarts school on “Problem Solving for Designers”. These same readers know I started the semester thinking I’d write blog posts for each section we covered including insights from teaching Design Thinking using Mobius. It was going to be wonderful and great.
What was I thinking?
Per usual, the Fall has been extremely busy with family and work. For teaching, the additional time spent preparing lectures and exercises meant less time for everything else. Mobius for Designers blog posts being one of them.
With the final grades now turned in and the semester officially over, I’ll use this post to reflect back on the semester and what I learned in the experience.
When we last left off, we were just getting into the Research step in Mobius. This turned out to be fun both in teaching and in practice to see what the teams came up with (see aside). In terms of Research topics, over two weeks we covered:
- Research Techniques with a focus on Observation, Interviews and Data Gathering
- Creating a Research Plan
- Summarizing Research
- Design Constraints
- Determining Investment
- Validating Constraints
For me, the takeaways from the time we spent in research were:
It was the most uncomfortable section for students as it forced them to get outside the class, talk to strangers and observe in public. Not something that comes naturally for most 20 year olds. But this was ultimately a good thing.
One student told me this section was the most different parts of the course compared to her other classes. By this point in their design career they’re pretty far along prototyping and giving critique to others, but connecting a design with a real-world problem was a new concept. At our class’s retrospective on the last day, she said Research was one of the most rewarding parts of the class for her.
I should have clarified the constraints around delivery budget and timelines better so students didn’t spend too much time exploring completely non-feasible solution options. At least one team churned a bit through delivery until they got their bearings. Looking back I think tightening up the constraints to ensure they are thinking of delivering a working solution with feedback by the end of the semester would have helped.
From a teaching perspective, with Research I got into a rhythm I used for the rest of the course when covering new topics. The recipe of ~20 minute lectures followed by ~30 minute exercises where the teams applied the newly-lectured concept to their project. During the exercise I walked around and provided coaching and guidance. Then we took a 15 minute break and repeated so we can learn up to two new concepts a class, if needed. For some classes a homework assignment allowed the students to further apply the concepts on their own or as a team and post the results to their blogs. Based on the feedback at the end of the class, the students really liked this way of learning and I felt it was effective as well.
Before jumping into Options we spent one week clarifying Outcomes. Topics we covered included:
- Outcome Thinking
- Clarifying Outcomes
- Making Outcomes Measurable
Outcomes is central to Mobius and is an important (but ofter overlooked) part of the design process. Part of our motivation for creating Mobius was to help people shift from Output thinking to Outcome thinking. In covering the topic with students a few things stand out:
Of all the sections, this was the hardest for students to get right without a good amount of assistance. They generally got the names such as “Minimize Bike Thefts” or “Increase Sign Readability” easily, but the scales, methods, targets and baselines were much harder for them than I expected. Perhaps it’s in the way I was teaching it.
With that said, for the rest of the course I did hear students often say “we think this design will help us achieve this outcome” as part of their regular language and when presenting ideas to others for critique. So outcomes did have a positive impact on their design thinking approach even if the measurement aspects weren’t quite there. In fact, by the end of the course 2 of the 3 teams had built measurement into their weekly delivery cycles with proactive ways of measuring progress.
“Well I think originally we wanted our outcome to be a completely new, re-designed parking system. We thought that was the best way to fix it and please people who drive and park in Richmond. But as we went along we realized that wasn’t really realistic or necessary. So our outcome turned more into wanting to just clarify an already existing system and create a way for the users to better understand it. Our options to solve that outcome led to us making the map that we finally went with. So technically all along we wanted to fix and clarify what we saw as a broken system, it was just deciding the best and most realistic way to do so. ”
Final exam essay response
By this point in the class the students were very ready to design something. I mean, they’re designers after all. Topics related to Options we covered included:
- Creating Options
- Prototyping Options
- Choosing Options
- Planning Options
We started this section with brainstorming options, using exercises to just crank out lots of ideas within a short period of time – but always in the context of improving their outcomes. We next started prototyping with many napkin sketches and gradually moved towards building and testing (in public) fully working paper prototypes. Then we started to narrow the options based on value and cost so the teams could head into Delivery Planning with some sense of what they wanted to build and release in the final 5 weeks of the course (see photos below).
“Because we spent so little time mocking these prototypes up it was okay if they didn’t work, we just wanted to test them and find out. I can honestly say that I have never prototyped a design project as much as I did this one, and while at times it seemed monotonous, I can see now looking back that it’s what, in large part, led to our parking map being successful. We had three seperate prototypes of the map, and with each one we learned what would make it easier to use and more successful.”
Final exam essay response
Aside from Delivery, Options was the section we spent the most time on – four weeks in total. It’s here where their ideas really came to life. In reflecting on this topic a few things stand out:
This part of the course was very natural for the design students, but what was different was the Research and Outcomes to frame the design approach. My friend Hope summarized it best when she said, “Design students are often focused on creating pretty things, not necessarily useful things”. She and I agree this doesn’t have to be a false dichotomy – you can create products that are pretty and useful, but most young designers aren’t there yet from an experience perspective.
The students came up with some great prototype designs. Most in retrospect didn’t look like the end product (a good thing), but I was happy they explored different avenues. I also enjoyed seeing what they would come up with each day in class and over homework assignments.
For choosing options I decided to use a big visible Outcome Chooser table (photos below) as a way to show them how to compare value to cost for each option. It worked well, although math isn’t naturally a strong suite for designers :-) For one of the teams, this exercise was the biggest influence into their final product because it helped them choose a solution with a dramatically higher value-to-cost ratio than any of their other options.
Delivery, Measure and Adapt
The final 6 weeks of the course were focused on iteratively delivering a solution. I decided to use 5 x 1-week iterations and taught the students just enough about Agile (Scrum) to work as a team. We used far fewer formalities and ceremonies than I’d normally use in a software development project. Topics covered included:
- Iterative Delivery
- Sprint Planning
- Demos & Retros
- Measurement & Adaption
The students came into delivery with working prototypes of options that now started to take shape, but in different ways for each of the three teams. By the end of the class all three teams had working solutions, but some teams came into Delivery knowing exactly what the wanted to create whereas others used the first few iterations to continue to explore options and gather additional feedback to narrow their focus.
Key takeaways from the section for me include:
Agile delivery came naturally to the students, but the 1-week schedule to show working solutions that consistently improved was a challenge to manage with the students schedule (most are in 4 or 5 courses during the semester).
The students continued to run experiments and get external feedback from prospective users throughout the Delivery cycle. While not always measurable (quantified), this feedback was a big source of ideas for improvements and refinements to their ideas. Because of their experience in Research, getting this external feedback wasn’t as scary as it might have been otherwise.
It was personally satisfying to see how the solutions evolved over the last 5 weeks. I enjoyed working with each team to be a sounding board and generally give them my thoughts on their ideas.
By this point the lectures were over and we dedicated the classes to working sessions where I roamed around and helped the teams out where I could. So for me this was like the home stretch of the project where I could be more in a mentor role to encourage them along. It was a nice change of pace.
“The iterative delivery allowed us to confirm the popularity and approval of our bingo game while completeing the overall look and feel of it. The iterative delivery also allowed us to figure out how we would accomplish getting this out in the world. We realized at the first test (where we went to see a movie on the VCU campus and had the audience participate), that physically handing these out might not spark the interest we need. So we decided on a website, which allowed us to release the bingo game in a free, opensource media. We sparked interest through social media so we could get the word out beyond VCU. The iterative delivery allowed us to keep up with the popularity of the website and monitor it.
Without the iterative delivery we wouldn’t have been able to get to the successful point we got, and further we wouldn’t have really been able to find out how successful we actually were.”
Final exam essay response
It is college after all and back in the summer when I designed the course I thought it made sense to have a final exam that assessed what the students actually learned. Project work would be 70% of their grade with 30% for the final. I learned a week before the final that I was the only design professor giving them a final exam :-)
There was a moment when I got this direct feedback that I thought maybe I should drop the final. But then I reflected and thought it would be valuable to have the students look back over the whole of the semester and reflect on what they’ve learned, especially in the context of the end product they developed by iteration 5.
I designed the final to be a mix of easier questions (true/false, multiple choice, fill in the blank) and harder ones that had them reflect on their semester (essays). In the end I’m really glad I went through the process because one of the most satisfying parts of the entire course was reading the students essay responses. It really let me understand, person by person, which concepts stuck and how it impacted their projects and them as designers.
There was a lot to reflect on over the semester. I learned a lot and I think the students learned and lot too. Although I didn’t get as much specific feedback on Mobius as I had originally planned, it did serve a valuable role in guiding the entire course and based on the final student products and their essay responses , I think it was a practical method to teach Design Thinking concepts.