Understanding “Design for Understanding”
A reflection on CS247I: Design for Understanding at Stanford University
Introduction
As I wrap up my 2019 fall quarter, I look back on my experience in my design for understanding class (partly for myself but mostly because it’s an assignment). I have grown immensely as a designer because of this class. I faced my fair share of challenges and struggles throughout its duration, but nonetheless walk away with many lessons learned.
In this article, I will highlight several notable aspects of my time in 247, namely: (1) my main learning outcomes, (2) my thoughts on the nature of helping people understand complexity, (3) frustrations that I experienced during the class and (4) my attitude as a designer moving forward.
What I Learned
As a computer scientist studying HCI, I felt fairly confident, at the onset, in my abilities to navigate the design process for 247’s 3 main projects. However, the following concepts were new to me.
Information Architecture
I was exposed to the importance of information architecture briefly in prior HCI studio classes, as well as through my own user experience. However, 247 expanded upon that knowledge by demonstrating how integral it was to websites and other information platforms. How to group information is a critical consideration for any system. Rather than categorizing information according to what made sense to me, it was imperative to think about how the user might categorize information.
The MDAO model
One of the most impactful moments during the quarter was Ben’s lecture on the MDAO model. Reading about the MDA model prior to beginning our game development, its importance was not very salient to me. However, Ben’s lecture solidified my understanding that the designer can only affect the mechanics of a game and it ultimately propagates to the aesthetic response from the player, through the MDAO stack.
In addition, I came away with the strategy to think about the stack in the reverse order: what kind of learning outcome and aesthetic response do we want to achieve? How does that emerge from player dynamics? What mechanics are required to create those dynamics? From there, we can anchor our decisions about game mechanics with our ultimate learning goal in mind.
The Importance of Playtesting
While ideating, iterating, and receiving high level feedback certainly evolved our game, nothing provided as rich and applicable of feedback as playtesting. The first playtest that we ran within our group was monumental because we finally got to experience what our game was like.
The answers to the following questions became more concrete:
- How did each turn feel?
- Did we agree with the impact that individual game mechanics had on the game state?
- What were emergent player behaviors?
Through each iteration of our game, while we may have had an intended outcome in our mind when implementing a new mechanic, playtests allowed us to see if that was in fact the case.
Mental Models
Being able to abstract the main components of a system in order to better understand its functions was a strategy that I used not only for 247 but in my other classes as well. The idea of breaking down a system that has a simplified assumption (e.g. environmental policy always comes at the cost of economic growth) into its nuances was a motif throughout the class (coming back later into the intricacies of “Fun”).
My thoughts on the nature of helping people understand complexity: emotionally, intellectually, experientially
Trying to understand a problem space has been a key component in my understanding of the design process since I took my first HCI class. Developing a tool to help others understand that space was a new, meta-task.
Whilst conducting research for our P1 explorable explainer, my group members and I came across various forms of media that communicated similar messages about climate change and the economy. We noticed, however, amongst ourselves and others, that the efficacy of each form varied — for example, visualizations tended to be more engaging than articles.
As a consequence, our explainer took the form of a simulation in order to more strongly engage the user with the information. This goes along with a central idea towards the end of the class that games are effective vehicles at communicating information.
Frustrations
There were times during the class that I felt lost, or that a concept did not make sense. Much of it stemmed from my impression that the class tackled many different topics and that I was not able to dive deeply into any one of them as I much as I wanted.
The first half of the class felt like a completely different class than the second half. In the beginning of the class, it felt as if we had breezed through the topics of: understanding complexity, design principles, and information architecture. They were the main focus for a single lecture and were not reinforced through later checkpoints.
Additionally, for P1 it felt as if there was an illusion of freedom in what form our explorable explainer could take, but a subtle funneling to use instruments like Twine/HTML. As a result, I felt very ill-equipped to produce a quality explainer if it could be of any form and at the same time did not receive much technical support in Twine/HTML. Learning website development tools was also our burden to bear, with little introduction to possible frameworks.
When getting into the information architecture portion, I felt like we got to dive a bit deeper, but again it seemed to go by so quickly after only a handful of introductory readings and lectures. When implementing our P2 website, I would have loved to have produced iterations of the website in the same way that we iterated on the game; we only had a week after the in-class feedback to produce a working website.
The game design unit and all of P3 felt much more concrete and targeted and I had a better grasp of how the lessons in class and in readings/videos connected with the overall project that we were building. However, apart from using the same problem statement as P1/P2, we never really came back those projects as P3 was developed.
Moving Forward
I find myself using the techniques that I learned in 247 to critique design in my everyday life; just the other day, as I was grabbing dinner with some friends, I was struck by how hard it was to parse the restaurant’s menu. I started to bring up what I knew about design principles and information architecture to critique the menu. Overall, I leave 247 with a stronger sense of my own design abilities and a set of tools that I know will prove useful in any future project that I tackle.
