Just like last Fall, I’m using Mobius as the framework for teaching the students how to solve complex problems. We are about a 1/3rd of the way through the semester and with the bike race in town all next week and school out, I thought this was a good time to share what the students are doing and what we are learning.

**Focus Areas this Year
**

This year’s class is in many ways similar to last years, but the students are about 2 years older on average so further along in their major. Based on a few adjustments I made over the summer (below), by class 4 we used voting dots to narrow down to 3 problems for the semester. With 9 students, this means 3 teams of 3 each, which works well.

Like last year, each team has a blog to post their progress, so bookmark these and follow along at home:

Silent Majority – Focused on improving mental health awareness on VCU campus

RVA Biking – Focused on improving biking safety in RVA

For the Love of Print – Focused on improving printing options for VCU design students

Each blog contains the results of our class exercises and their homework, which is updated weekly. In particular check out some of their empathy maps and target outcomes, which I particularly like.

** **

**Refining Mobius in Practice**

A big part of the reason I took this teaching opportunity was to work out how to teach the concepts behind Mobius in practice. Working with art students forces me to get out of the business world for a few hours each week and teach these ideas in a clear and simple manner. No industry jargon. No corporate politics.

A good example came from the class where I introduced Design Constraints. Mobius has four basic types of constraints:

**Budget**– The limit of the money an organization plans to invest to solve the problem**Event**– Time related to when a solution must be found and delivered. Often a date or event**Governance**– Regulatory oversight, whether a law or an internal policy or standard**Capabilities**– Skills and experience of the people, processes and technologies delivering the solution

As I was covering these in class, I could tell the terminology (budget, event, etc.) wasn’t resonating. I found myself repeating this phrase, “just think about event as *time* and budget as *money*” when one of the students said, “We’re art students, keep it simple for us”.

In that moment I realized that terms like budget and event that are more common in the business world aren’t the clearest convenience of the core ideas. So perhaps in Mobius we consider renaming our constraints to :

**Money****Time****Regulatory****Skills**

I don’t know, what do you think?

**Inspect and Adapt**

Over the summer I made a few tweaks to the class plan, most based on feedback from last year’s class but also a few based on changes to the Mobius Loop. The main ones include:

- Doing direct observation research earlier (class 2) to learn to identify problems (thanks Hope!)
- Choosing a problem that impacts the local community directly (new constraint)
- Giving students more time before choosing the problem for focus (class 4 versus 2 last year)
- Getting to Options faster; this is what the students love (class 8 versus 10 last year)

Making these adjustments resulted in two additional 1-week delivery cycles (7 instead of 5), giving the students more time for conducting research, running experiments and implementing options.

So far the changes are paying off and the course is running smoother. Here’s what we have covered to date:

- Class 1 – Introductions
- Class 2 – Design Thinking
- Class 3 – Problem Framing
- Class 4 – Problem Selection (for semester)
- Class 5 – Stakeholders and Users
- Class 6 – Outcomes
- Class 7 – Measurable Outcomes & Design Constraints
- Class 8 – Research
- Class 9 – Options

I’m also more relaxed as I’m already familiar with the lecture content and exercises. So I’m spending about an hour to prep for each class, less than a third the time I spent last year when I was writing all the lecture content from scratch.

All in all it has been a very busy Fall but things are going well. Stay tuned for more…

]]>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.

**Research **

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.

**Outcomes**

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

**Options**

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

**Final Exam**

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.

**Summary**

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.

*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…

When I decided to teach the course, one of the things I promised myself was to write about the experience of teaching for the first time. I also wanted to write about the feedback on putting Mobius into use and learn something from the students in the process. So this post kicks off what I hope is a series of posts about what we’re doing and where we’re going with Mobius in the classroom.

Class 1 – Introductions

The first class we started with the required review of the syllabus, schedule and other logistics. After a brief introduction of myself the students introduced themselves. Then we jumped into an exercise I do with my training classes: expectations. I passed out stickies and asked the students to write down their expectations for the course, one idea per sticky. After 5 minutes they posted their results on the board.

Then we did another fun exercise: silent sort. Half the class went to the board and without talking, organized the expectations into affinity groups. After a few minutes, they sat down and the remaining students organized them further into tighter groups. All without talking. In 8 minutes total.

I put labels on each of the groupings and as a group we discussed the themes that emerged from their expectations: teamwork, real-world experience and problem solving were key groupings

Next I introduced Mobius, I showed the students the canvas and walked them through how we’re going to use it over the course of the semester on their project.

At the end of class came the hard part: the homework assignment to pick a problem they wanted to solve over the semester. I asked the students to come back on Wednesday and in 4 minutes or less, tell their peers:

- What problem they wanted to solve?
- Why it was important to them?
- Why it should be important to others?

I also asked them to bring a one page visual design that represented their problem to share with the class as their visual aid when they presented.

Class 2 – Picking a Problem and Organizing into Teams

When we reconvened for the second class I asked the students to present to their peers the problems they proposed to solve over the semester. One by one, each student came forward and presented their ideas. Some of the problems related to the city surrounding the VCU campus: parking, bicycle thefts and homelessness. Others focused on women’s portrayal in media an app for helping art students.

After all the students had presented we laid out out the 1-page visuals side by side and I introduced another old consensus technique: dot voting. Or as one of the students said, “Oh, we get to use stickers!” I gave each student 5 voting dots (stickers) and asked them to vote for the projects they were most interested in working on over the semester.

After all the votes were talied three problems rose to the top: bicycle theft, parking signs and women’s portrayal in media.

I next asked the three students who’s problem was chosen to stand up and the other students to self-organize around the problem the wanted to work on, according to their votes. This yielded our three teams for the semester and our first class photo.

The last bit of the class focused on team norms and the importance of getting them established early. After providing some examples I asked the students to spend 10 minutes thinking about their own team norms.

Afterwards each of the teams shared some of their norms and we had group conversation about the process of establishing their norms. We also agreed to establish some class norms and picked a few the teams had established the related to interactions.

I asked the team, “what should happen if someone violates the class norms?” There was a bit of silence and then one of the students said, “You’re the teacher, shouldn’t you do something about that?” I was reminded that oh yeah, I am the teacher. So I proposed that if this happened, I’d pull the student aside and have a 1-on-1 with them. The students agreed this ok and with that we wrapped up the second class.

For homework, I asked the students to come up with an identity for their teams include a name and some design elements. They were also asked to setup a blog with their new team identity. This will be used over the course of the project to post about their progress.

And with that we wrapped up the first week. With the design of the course built around team-based projects, I knew that if week 1 went south the entire class was in jeopardy. Luckily I think we’re off to a good start and the students seem engaged in trying to make an impact over the semester.

Next week we dive into the first step in Mobius:What problem are you really solving?

Stay tuned for progress in the coming weeks and feel free to post comments.

]]>