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.
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.
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.
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.
Designers using UX techniques are in a great position to leverage their user-centered approach to design applications that not only affect users but also social systems as a whole. Still, there exists significant room for UX designers to help expand the reach of these technologies that carry the capability of transforming systems and there embedded politics.
Baked Potato is a mobile web service geared at addressing the imbalance of power between those who market and those who consume food products. Food marketers rarely provide a detailed range of information about products that would allow consumers to understand how a product and its company connect to their cultural values. The main goal of this application is to connect people in a way that celebrates their differences and gives them agency by helping them make better decisions about their food purchases.
For some time, our design team has been working hard on an HCI design that would transform the activity of shopping in order to help people make more informed decisions. Activities surrounding food are some of the most fundamental activities that we make as human beings. Despite the variety abundance of food in modern grocery stores, people are not able to make informed decisions about the food products they buy. Political, social and business forces massage the information people use to make decisions about the food they buy.
Food as Social Justice
As a result of this extraordinary influence there is imbalance of power between those who create the food, and those who buy it. This is particularly true for younger audiences who may not have the experience negotiating the variety of advertisements, labeling and other distorted prices of information. For these reasons, we believe that this is a transformative area of innovation whereby we can develop an HCI design that could move shoppers from being uninformed about their about the purchasing decisions to being more aware.