Learning Log: Week of 5/15/17

Note: This post appeared on my Hugo website and was originally published on 05/15/2017. I wanted to transfer and archive some of my previous content.

---

Week of 5/15/17

Edit: (5/31/17) I’m falling slightly behind in my weekly post-pact with Marty, so I made a dedicated goal to jump back in!

This week I participated in the 3rd Maker Educator Convening as well as the Leadership Summit. Monday and Thursday were almost entirely devoted to travel, as the convening was in San Francisco. The Leadership Summit was on Tuesday and then the Convening was on Wednesday. I didn’t have much time to spend working on learning and practicing programming, but I did have lots of learning experiences! On Wednesday I presented a demo session From Scratch to JavaScript where I shared insights and resources about helping youth transition from Scratch to JavaScript via p5.js. In creating and discussing the resources with other educators, I learned a lot about the questions and concerns about transitioning youth from visual languages to syntax. Much of the reflection and all of the resources can be found in the GitHub repository above.

The Importance of Design Personas

Prior to the Leadership Summit, attendees prepared empathy maps. The goal of the map was to create a persona of someone we wanted to impact with maker education. I’ve done some user centered design activities in the past, so I wasn’t unfamiliar with this concept. In the past, I’d built personas but they were usually rather superficial. The benefit of the empathy map was that it resulted in a more detailed profile with specific information about the needs of a particular user.

This was a great way to introduce our group activity. We paired up in small groups with other educators and did a listening exercise where we took turns reading the facts about our personas and then everyone else in the group had to repeat their interpretations of the user needs. This activity created an immediate group connection. Interestingly, we all created similar personas for the activity!

Some of my core takeaways from this experience was that creating an empathy map for a specific user is a great way to add clear definition to a problem. With regard to the summit, the goal was to think of a person who would benefit from/be interested in maker education. Instead of thinking of generalized use cases, the creation of specific people with specific skill sets, problems, and concerns provided a helpful framework for empathetic problem solving. I’d like to start building these practices into the youth curriculum at Digital Harbor Foundation, especially the active listening step where group members share their personas and compare notes afterward.

The reading and reflection process was fast paced, as the activity took about 3 minutes total. For me, the addition of the timed element increased the sense of urgency and resulted in a more keen ear when taking notes. From here, we distilled our notes and discussion into choosing/creating a single persona to model as our user for the remainder of the design process.

Design Thinking: The Problem Statement

Creating a problem statement isn’t something that is new to me either, as it’s a core element in many design thinking exercises. However, I found that using our shared persona to inform our problem statement was actually fairly difficult. Since we had all created such similar personas, we all had somewhat different frames of reference for our contributions. Even though we all knew at an instinctual level what problem we wanted to solve, it was somewhat tricky to create a single actionable sentence. This is a great exercise – truly narrowing down and summarizing the problem like this then provided us with a clear direction. I’ve started integrating this approach into some of the new curriculum I’ve been designing as well as even trying to draft a simple problem statement for anything I’m working to fix. Sometimes the problem statement can take the form of “I want to clearly explain (some concept) to (some audience).” I’ve been finding that these clear expressions of intent help me focus when my attention starts to wane.

Design Thinking: Rapid Prototyping

Since there was lots to do in a relatively short amount of time, much of the activity steps were designed to be fast paced. This is something that I experienced when facilitating a modified version of the Stanford d-school design thinking activity the Wallet Project. The link is currently broken, so I’ll provide a quick overview of the activity. The idea is that the facilitators guide a group through all phases of the design process in 60 to 90 minutes. Each person begins by thinking about what their ideal wallet would be like, and then take pairs take turns interviewing each other about what the aspects of their partner’s ideal wallet. Each phase is quick, usually around 3 to 5 minutes. Each interview is followed by reflection with an emphasis on continual iteration.

Several of the steps, especially the prototyping phase, are intended to be extremely fast paced. The intention is to use the time constraint to help get people into the activity phase. This is a concept that I’ve become much more comfortable with over the last year or so. Previously, I would spend an extended amount of time in the planning, research, and information gathering phases before moving into creating a prototype. However, these recent activities have shown me the benefits of quickly moving into taking action. Having such an extreme time constraint (for example: create a physical prototype within 5 minutes!) gets everyone moving and thinking quickly.

After this initial prototype is finished, we had an equal amount of time for reflection and iteration. I think that structuring these design thinking activities in such a way demonstrates the crucial roles that reflection and iteration play in a problem-centered design process. I’ve always been an advocate of prototyping, especially in any of our digital fabrication courses. However, I’ve started thinking about how to integrate more of these concepts into other areas of my life as well, such as programming.

Super Powers and Kryptonite

Another interesting exercise we did in our breakout groups was to take about 5 minutes and complete a grid of our own personal strengths and weaknesses with regards to group work. There were some questions to guide this process, such as:
– What are your superpowers when working in a group?
– What drains your superpowers when working in a group (kryptonite)?

After reflecting and answering the questions, we shared our answers with the group. These guiding questions provided enough of a framework for us to clearly identify and understand how we all would best function in a group. Our group ended up being paired very well, but I can see this particular exercise providing benefit for longer projects or even well-established teams. I want to facilitate this quick activity for some of our core DHF team, as I think it’s a great method to gain valuable insight into the thought processes of teammates. One thing that’s also interesting is that you can see how people view themselves compared to how you view their role on a team.

I suppose that this is another way to build empathy in a design/problem solving setting. While it’s obviously important to create a sense of empathy with users/clients through the use of empathy maps and personas, it’s also important to take some time to level set and gain some insights into the strengths and weaknesses of coworkers that you may not have known before. This is one of the aspects that I like most about design thinking and collaborate problem solving – the emphasis on the importance of reflection, whether it be on the needs of a user or on the strengths and weaknesses of teammates. Understanding both sides is necessary for a successful project, but in my experience there is often only focus placed on one or the other.

What’s Next?

While I wasn’t able to do much programming this week since I was busy with these other pursuits, I’ve learned a lot and gained insight into the benefits of the design process. I’ve always been a supporter of the benefits of design thinking and design thinking activities, but I now definitely want to use empathy maps and rapid prototyping as much as possible, whether in my own projects or in our youth courses. Additionally, I think the process of human centered design and solving problems that are relevant to a specific user can increase the amount of empathy in general. Having to consider a problem or set of needs/skills from the perspective of another user is a skill that isn’t always easy, and the more exposure that youth have to it from a young age the more empathy they’ll develop over time.