The Beer Coaster Method for App Design

Like many of you, I work in problem domains that are bedeviled by complexities. New technologies are thrown into our problem solving mix with an accompaniment of overwhelming hyperbole on a daily basis. It soon becomes a case of struggling to see the forest for the trees.

The challenge, when designing software solutions for affirmative behavior change in such an environment is to devise a uniform, consistent, transparent and easy-to-follow method to manage the effort. Selecting the right tools and ensuring they fit into the product development processes used by the client tends to underpin the choice of method and its roll-out.  This article examines the front-end of a field method for fitting behavioral design into the regular agile development of an app that was built to connect at-risk exercisers with exercise clinicians using fitbit and digital health data.

As depicted below in this conceptual overview the method we are evolving in situ is referred to as The Beer Coaster Experience. It reflects our reality as a small team dealing with other professions in virtual operations charged with building behavior apps. Some key take-aways:

  1. Admit you don't know what you don't know when you start and be open to ideas.
  2. There are abundant, well research field-validated engineering processes that you, the behaviorist needs to fit in with; don't re-invent the wheel.
  3. You are part of a multi-disciplinary team; the UI-UX people will be your best friends or biggest hurdles so get to to know them, their pain, processes and value.
  4. It's a nascent field, changing fast so you need to be open minded and flexible when it comes to problem solving BUT
  5. Make an effort to capture and share knowledge to improve community knowledge and app efficacy-retention.
  6. Educate team members on the vital role of true behavioral measurement and evidence-based interventions including content; justify your inclusion.
  7. Get out of your comfort zone and learn UML at the very least and hands-on UI and coding at a stretch.
The Beer Coaster Method - an On-The-Fly Schema with Work-to-be-Done

The Beer Coaster Method - an On-The-Fly Schema with Work-to-be-Done


Behavioral Model

As my background is in the health sciences I tend to use evidence-based theories that provide validated scales as a starting point. Understanding your target population, their state of change in relation to the target behavior you are building the app for and deriving appropriate models for describing these behaviors, identifying key associations and influences is an essential first step. Scientists have their preferences for particular statistical techniques and tools.  In this circumstance, we need to provide explanations as clearly and plainly as possible, an imperative that shepherds us toward factorial analyses and PATH diagrams. The two prime benefits of structural equation models (SEM) are well understood;

  1.  Makes it possible to study complex patterns of relationships among the constructs in a conceptual model in an integrative fashion; and
  2.  the measurement of unobserved (latent) variables by observed fallible indicators can be modeled explicitly, and the effect of measurement error (both random
    and systematic) on structural relationships can be taken into account.

Irrespective of which techniques you use, a clear, communicable picture of what states of behavior exist in your target user population and why allows you to draw a line in the sand. It provides you with the communication content you need to help describe the target user population to ensure any app produced fits the problem space. Usually, categories of individuals will fall out of this analytic phase and its to these commonalities you should consider aligning your persuasive design elements. Let's take a real-world example. If you were developing an app to assist the primary and allied health care networks reduce the deprecation of identified individuals from an at risk state of impaired glucose tolerance (iGt) to full blown type 2 diabetes mellitus using wearable data, where could you start?

Let's apply for the sake of the exercise, the Transtheoretical Model (TTM), (DiClemente, 2007) to this challenge and identify the Stage of Change potential users are at. This model has been extensively used to guide effective exercise interventions in related clinical conditions; (Gong, Chen and Li, 2015) and (Song and Kim, 2011). It's also played a pivotal role in better identifying intervention alignment with behavioral state for type 2 diabetes suffers, (Holmen et al., 2016). It has the appropriate gravitas and relevance to our sample challenge. It is not however the be all and all; it's simply one of many established frameworks you can use and improve.

For the sake of simplicity let us say our goal in this stage of the project is to identify the Stages of Change present in the target user community and determine what factors characterize these stages before then applying an evidence-based set of processes for eliciting potential software features that could, potentially be instantiated as source code.


Once you have identified the spread of community members across the Stages of Change and documented the factors that characterize each, it's important to use a candidate list of potential software design features that may best support positive behavior adoption throughout the stage transitions. Populist practitioners of persuasive design processes, (Fogg, 2009) and (Oinas-Kukkonen and Harjumaa, 2009) provide a grab bag of potential software UI elements and techniques such as tunneling, personalisation and monitoring  to consider for teams charged with behavior app development. There have also been nascent attempts to articulate effective methodologies that combine behavioral science, choice architecture and persuasive models; (Laurillau et al., 2016) and (Mustaquim and Nystrom, 2017) which show a good deal of promise but require exhaustive validation in real-world settings before they can evolve and be deployed.

In the digital health example, it helps to create a table of potential functional design elements or mechanisms that will enable implementation of behavioral support processes known to positively support behavior change transition using the TTM approach. These design elements align with the Stage of Change profiles elicited through the modeling process. In the following table we look at the processes required to support the members of the target community classified as being in the Preparation Stage of Change toward the target behavior of adopting an exercise intervention that is monitored and managed through a wearable-based app. At each stage, it is worth considering a programmatic measure of decisional balance within the app. This is crucial in alerting the app to an individual user's preparedness and ability to move on. Decisional balance measures have been shown to be effective in TTM-based interventions for weight loss; (O'Connell and Velicer, 1988). Implementing decisional balance scoring may help enable the app to serve up more tailored user experiences including personalised persuasive content that align with the individual's behavioral state and self efficacy.  In the field, we have been able to move small scale theoretical design proofs to larger audiences, in particular the application of personalisation profiles to persuasive content including messaging. The work of (Kaptein et al., 2015) has been pivotal to our adoption of this approach although to date this has been confined to a meta-judgmental design method largely because of our conservatism around the ethical bounds of personalisation profiling.

This table is by no means conclusive; it's simply a rough guide drawn from first-hand experience. I'd encourage others to actively recruit candidate UI and functionality that is well researched and tested before adding it to your team's Behavioral Design Repository (BDR). The BDR should comprise cross-platform UI elements (forms and widgets), code snippets, stage-specific content fragments including media and analytic phase findings organised by Stage of Change.  Bear in mind some of these elements may exist in collaborative design platforms such as inVISION and the like. The BDR needs to be searchable by the project team and integrated into the team Wiki and agile management platform such as JIRA. If you are going to be in the business of delivering multiple apps it may be worth considering coding your own simple platform and make use of the many API's. Within such a management and delivery system it may be of value to use  SLACK or FLOCK as the communications and organisational glue.

Remember, these functional  elements detailed in the table will form a part of the working app that must be assessed for efficacy and ease-of-use. As they will be part of the app proper, they will fall within the remit of acceptance testing. Learn what this is, how it works and what role you may play as it's key to proving your value and delivering on-time.

An example of simulation-rehearsal from the exercise wearable app


A Brief Note on the Beer coaster Box marked Spec Lang.

Given the ever tightening noose of time-effort-cash-market on product development teams it makes sense that if you can improve the linga franca of the project team when it comes to sharing an understanding of what it is you are delivering then you can reduce errors and loosen the noose somewhat. In line with this we have fiddled with a specification language tool

This enables you to pseudo-code the app requirements such that they are rendered operationally as acceptance tests which helps save a good deal of effort, cost and hassle. There are similar apps in this space including hipTEST  Somewhat erroneously these apps are marketed under the moniker of behavior-driven development or BDD. Yes, but no; goal-driven or test-driven development maybe. They allow you to provide a plain English set of invariants for goal-directed actions by the users of the app. An important consideration when considering the deployment of either of these tools is to work out exactly how they will fit into your overall product development platform including release management and defect tracking. The goal is always to do whatever you can to round-trip your behavioral models throughout the software lifecycle and ensure an auditable trace of definitions through to delivery and upgrade.

Summary of the Beer Coaster Method

Key Points from the Beer Coaster First Stubby Sessions

Key Points from the Beer Coaster First Stubby Sessions

Next time

We will look a vital process for quality assurance; Testing  and in particular the increasing role of emotional assessment. In addition, we discuss the use of Triggers in-app algorithms  that may help deliver self monitoring of behavior change and support user retention strategies. A discussion of Patterns and their role in re-use will be touched on briefly to finalise ths introduction to field-based methods of problem-solving and delivery.


DiClemente, C. (2007). The Transtheoretical Model of Intentional Behaviour Change. Drugs and Alcohol Today, 7(1), pp.29-33.

Fogg, B. (2017). A behavior model for persuasive design. In: Proceedings of the 4th International Conference on Persuasive Technology. Claremont: ACM.

Gong, J., Chen, X. and Li, S. (2015). Efficacy of a Community-Based Physical Activity Program KM2H2 for Stroke and Heart Attack Prevention among Senior Hypertensive Patients: A Cluster Randomized Controlled Phase-II Trial. PLOS ONE, 10(10), p.e0139442.

Holmen, H., Wahl, A., Torbjørnsen, A., Jenum, A., Småstuen, M. and Ribu, L. (2016). Stages of change for physical activity and dietary habits in persons with type 2 diabetes included in a mobile health intervention: the Norwegian study in RENEWING HEALTH. BMJ Open Diabetes Research & Care, 4(1), p.e000193.

Kaptein, M., Markopoulos, P., de Ruyter, B. and Aarts, E. (2015). Personalizing persuasive technologies: Explicit and implicit personalization using persuasion profiles. International Journal of Human-Computer Studies, 77, pp.38-51.

Laurillau, Y., Calvary, G., Foulonneau, A. and Villain, E. (2016). SEPIA, a support for engineering persuasive interactive applications: properties and functions. In: EICS'2016. Brussels: ACM.

Lee, Y., Park, N. and Kim, Y. (2006). Process of Change, Decisional Balance, Self-efficacy and Depression across the Stages of Change for Exercise among Middle Aged Women in Korea. Journal of Korean Academy of Nursing, 36(4), p.587.

Mustaquim, M. and Nystrom, T. (2017). A System Development Life Cycle for Persuasive Design for Sustainability. In: International Conference on Persuasive Technology. LNCS, pp.217-228.

O'Connell, D. and Velicer, W. (1988). A Decisional Balance Measure and the Stages of Change Model for Weight Loss. International Journal of the Addictions, 23(7), pp.729-750.

Oinas-Kukkonen, H. and Harjumaa, M. (2009). Persuasive Systems Design: Key Issues, Process Model, and System Features. Communications of the Association for Information Systems, 24(28).

Shih, L. and Jheng, Y. (2017). Selecting Persuasive Strategies and Game Design Elements for Encouraging Energy Saving Behavior. Sustainability, 9(7), p.1281.

Song, M. and Kim, S. (2011). Effects of a Transtheoretical Model Based Exercise Behavior Improving Program on Blood Pressure and Physical Activity for Older Adults with Hypertension. The



Dr Daryl Foy

Dr Daryl Foy is a Behavioural Scientist who specialises in the design of effective health behaviour change apps based on evidence including his own validated models for optimising persistent use. He consults to industry on how-to integrate persuasive design into LEAN product development as well as conversational UI. He can be contacted at