My part in the AgShare project is to explore the potential of feedback loops to inform and sustain the AgShare project. What this means to me is understanding what feedback loops are already in place and consider what existing infrastructure can support potential social, physical and technical feedback loops.
One of the potential loops I am interested in is mobile based platforms. Although African is one of the least connected areas, mobile use is sky-rocketing in comparison. This makes sense since physical land lines have traditionally been difficult to deploy, and mobile phones leaped over this already. Mobile internet use seems to be following this trend.
Despite the App Store having thousands of applications to choose from I only use about 5. Brushes is a popular painting application for the iPhone and iPad, which I have been using for some time as a portable sketch book.
Besides the intuitive user interface to select color and brushes, Brushes has a unique feature which I have come to love, playback. A video of each sketch can be downloaded along with a high-res version of the image. As a studio artist I find it invaluable to be able to go back and watch how a sketch is composed over time.
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.