Last time I talked about using Behavior Driven Development (BDD) as a way to describe user needs in the prototype.

Claim: The functional spec should focus on user behavior.

A functional spec traditionally describes the behavior of a system; however, when designing for social change it is important to also document user behavior. We developed a scenario-based functional spec based on BDD, which describes a user’s relationship to the application and to the goal of social change. Since the scenarios described user behavior, we placed them directly into the functional spec, which was not only efficient but also reinforced the spirit of social change. Therefore, any developer that can satisfy the specification in code will also satisfy the users connection the the application and to social change. Incorporating behavior into the functional spec means that the developer cannot ignore user behavior; however, it does not over-determine how the system functions. This allows the developer the freedom to code the behavior of the system in novel and interesting ways.

Continue Reading

Last time I talked about how models become shared tool which a design team can touch, talk about and share. They make data actionable by visualizing observations, which provide opportunities to design an intervention in a meaningful way.

Claim: Creating a shared story about a user’s behavior in relationship to the app forms a relationship to the change itself.

Everything put into the design of a prototype is a claim about a users relationship to the application. Our prototyping approach was influenced by Human-Centered Design practices, which focused on the needs and abilities of users. We used Behavior Driven Development (BDD) to describe these needs. It uses a simple syntax that all stakeholders can use to describe a user’s relationship with the application. As a result, it can be used to make explicit all the behavioral assumptions of the application. Since BDD is a testable framework, we are able to make design claims that we can prototype and test with users.

Continue Reading

Last time I talked about how observations are a way of testing your hypothesis/assumptions before building.

Claim: Modeling is the secret sauce that turns observations into actionable data.

Models are the common tool a design team can touch, talk about and share. They make data actionable by visualizing observations, which provide opportunities to design an intervention in a meaningful way. Modeling helps designers value the diversity of individual users and makes the case that system design should incorporate multiple preferences. We observed that the current food system did not provide relevant information to different users. Differences emerged in user information preferences in our modeling. We used polar graphs to map key values and a users’ strength of preference for each value.

Continue Reading

In part 1 I talked about how it is impossible to understand the complexity of a system you intend to change without a working theory which allows you both to observe the issue and describe it to others.

Claim: Focus on the repetitive actions within larger activities

Observing is a way of testing your hypothesis/assumptions. Also it ties back to being able to see the problem. Activity Theory (AT) provides a specific way to observe the current system that frames the issue of injustice. We find that AT and UX are quite compatible because they focus on how people engage and interact with their environment, and any HCI tool is a natural result of that process. AT focuses on the “why” by altering the “what” and the “how.” Activities (why) are motivated experiences (e.g., shopping) and mediated by tools. Actions (how) support motivated experiences and are usually unmotivated.

Continue Reading