Note: This post is part of a series on using Mobius for teaching university students. If you’d like a little more background, see the first post in the series.
Now that the students have picked their projects and formed into teams, we’re diving into the problem. The next three classes focused on Problem Framing, Users and Empathy and Research. This post covers how we tackled those using Mobius as a guide.
Class 3 – Problem Framing
One of the homework assignments from the last class was for each of the teams to establish an identity and setup a blog. At the start of this class each team shared their blogs with the class.
The inamora team is focused on the problem of women’s portrayal in the media while the you-lock and RVApark’nprobz teams are focused on matters closer to VCU students: bike thefts and parking, respectively. I found it interesting that all the teams chose Tumblr for their blogs, perhaps because of their visibility here in RVA?
With show and tell over, we started into problem framing. But first I wanted to give the students some context about how we were approaching problem solving so I spent some time talking about Design Thinking and the role of designers in the process. Referencing a great article by Tim Brown on the subject, we explored the method and how a focus on empathy for humans was at the center of design thinking.
In my own research, one thing I found interesting was how Mobius naturally aligned to the three phases of design thinking: inspiration, ideation and implementation.
Next we covered the importance of a succinct and snappy problem statement as core to defining the problem. I also introduce Mobius’ 5-steps to framing a problem:
- Create a clear and succinct statement
- Ask why?
- Open or tighten up the problem statement
- Decompose and link problems
- Test the problem statement
The lecture covered the first half of the class and after a break, we came back and applied these concepts to their problem with a series of exercises: one per problem framing step.
Using the Mobius Problem card as a guide, the students worked in their teams through each of the steps – spending about 10-15 minutes per step. Although the students had picked their project nearly a week earlier, they were surprised to find how hard it was to get to a clear and succinct statement of the problem they were trying to solve! That was no surprise for me, but it was an important lesson for them to learn to work and refine their statement until they really zeroed in on the problem they were trying to solve.
When it came time to decompose and link problems, I handed each team a pack of slicky notes and they further broke down their problem statement and identified related problems to the ones they are solving. While I thought this might be the hardest part for them to get, their feedback was that it was actually one of the easiest steps.
At the end of class, one at a time each team read their problem statements to the other teams and got feedback. We talked about how testing your problem statement on others was a simple-but-critical step in the process.
As homework, they were asked to read the Design Thinking article, create their first blog post titled Problem Statement and find two other people to give them feedback on their problem statement.
Overall I was pretty happy with how the class went, although in retrospect I think I covered too much lecture up front before diving into the exercises. I could see it on the students faces right before break that 45 minutes was a long time on lecture. I think in the next classes I’ll intersperse the exercises throughout the class to break it up a little more and keep their interest.
After just one class we completed the Problem step in Mobius and next we’re onto the Deep Dive step where we’ll spend a few classes. Stay tuned…