The patterns of user experience for sticky-note diagrams in software requirements workshops

https://doi.org/10.1016/j.cola.2020.100997Get rights and content

Abstract

Software requirements elicitation workshops often make use of a widely used and, on the surface, highly informal, notational medium: the sticky note. Often, in such workshops, facilitators and participants collaborate to construct “diagrams” made up of sticky notes. Methodologies have been developed that prescribe the way that diagram construction can uncover and document software requirements. Because they constitute a collaborative diagrammatic notation, such sticky-note diagrams lend themselves to an evaluation underpinned by theories of visual notation. In this paper we apply an analytic framework, the Patterns of User Experience (PUX), to sticky-note diagrams from two workshop methodologies, “Big Picture Event Storming” (BPES) by Alberto Brandolini and “User Story Mapping” (USM) by Jeff Patton. Our evaluation considers the sticky-note diagrams and the collaborative social processes surrounding them.

Introduction

Notations used in software processes have varying degrees of formality [1]. As a familiar exemplar, the Unified Modeling Language (UML) can be used on paper as a precisely defined specification tool or as the basis for informal conventions in the way that software developers might suggest general ideas to each other whilst sketching on a whiteboard [2]. Whilst there has been considerable research into whiteboard sketching by software designers [3], there does not appear to be any systematic analysis of the widespread use of another familiar notational medium — the sticky note.

In many fields of engineering and management, workshop processes for ideation and brainstorming often make use of sticky-notes [4]. In software requirements elicitation, workshop methodologies have been developed that apply a degree of formality to the sticky-note diagrams that are developed collaboratively by workshop participants. Even though the formality of such diagrams is far removed from visual languages, their visual nature, and their methodological underpinnings, potentially lead them to being evaluated using theoretical frameworks that have been developed for notations that include such languages. In this paper, we perform such an evaluation using an analytic framework known as the Patterns of User Experience (PUX) [5], [6]. As concrete case studies, we analyze two different software requirements-gathering workshop practices — “Big Picture Event Storming” (BPES) by Alberto Brandolini [7], [8] and “User Story Mapping” (USM) by Jeff Patton [9], [10]. These two workshop practices have gained considerable attention in industry and are described in publications and in videos on the internet.

In the remainder of this section, we provide an introduction to the PUX analytic framework and an overview of the two workshop methodologies (BPES and USM) that we have considered for our case studies. In Section 2, we describe the evaluation methodology that has been used to evaluate the sticky-note diagrams in both workshops. In Section 3, we describe the results for both BPES and USM. We have divided this section into three parts corresponding to three of the PUX “social activities” and we trace each of these patterns through their supporting experience patterns. We reflect on our overall findings and recommendations in Section 4, and we describe our conclusions and suggestions for future work in Section 5.

The “Patterns of User Experience” (PUX) [5], [6] is an analytic framework that has been formulated as a “pattern language” of the experiences that users have with visual notations and other cognitive artifacts. PUX describes a “pattern language”, in the sense that was originally proposed by Christopher Alexander for architecture (of buildings) [11], [12], and it builds on Thomas Green’s Cognitive Dimensions of Notations (CDN) [13] and various other analytic methods derived from that. The Cognitive Dimensions of Notations (CDN) framework has been developed and documented extensively over the past 30 years. In addition to other publications cited in the present paper, interested readers can refer to several papers in a special edition of the predecessor to this journal in 2006 [14], and to a 2017 review [15] that profiled over 1600 publications influenced by the CDN framework.

The CDN framework aims to represent a cognitive scientist’s critique of a design process in language that is accessible to a designer rather than language that is specific to experts in human computer interaction (HCI). Its theoretical underpinnings originated in the psychology of programming languages and it particularly deals with the processes and activities involved in constructing design artifacts​ rather than being solely focussed on the artifacts themselves. The seminal paper by Green and Petre in 1996 [16] applied CDN to discuss and critique visual programming environments and demonstrated that the benefits gained from their analysis were both useful and complementary to those offered by HCI techniques such as GOMS [17] and (programming or cognitive) walkthroughs.

The strand of CDN development followed in the Patterns of User Experience (PUX) originated in the observation by Sally Fincher [18] that the ways that the CDN framework was being applied and extended corresponded to the design patterns theory for architecture (of buildings) proposed by Christopher Alexander [11], [12]. As later argued by Fincher and Blackwell [5], the CDN framework is closer to Alexander’s original intent than the now commonplace use of the concept of “design pattern” in software engineering. In the development of PUX, Blackwell has created a refactored “wrapper” of Green and Petre’s 1996 work, together with many of the extensions to CDN that have been contributed by a range of authors since then. This material has been formulated as a pattern language of user experience presented in the style of Alexander, but oriented toward visual notations and other cognitive artifacts.

As with the CDN framework and Alexander’s original pattern-language texts, the purpose of PUX is not to prescribe a single way of doing things, but to present a systematic vocabulary of the kinds of experience that users have when working with tools and notation that are designed in one way rather than another. As with all of the CDN analytic tradition, it is essential to understand that a pattern language offers a basis for critique and discussion of design options and trade-offs, and not simply a usability checklist or set of benchmarks for performance comparison. The key principle is that different users, at different times, need different kinds of tools that offer different kinds of experience. No single product could be the best tool for coding a device driver, sketching a user interface, specifying a commercial contract, negotiating a project workplan and capturing system requirements. The PUX framework offers an analytic approach with which to capture what is distinctive about all the different kinds of activity that are involved in developing notations for a software (or any other) project, and then to prioritize​ the design of such notations for the kinds of user experience that are most valuable in that context.

In the case of software requirements engineering there is a very distinctive set of properties that are desirable for the supporting tools and notations. Although they are different in appearance to most cognitive tools, workshops like BPES and USM, have become widely used precisely because they are well designed for their context. Although each has been developed through the practical experience of their inventors, it is not straightforward to describe why, and how, these sticky-note-based methods are different from, say, the user interface of the Eclipse software engineering environment. Without an analytic framework, it is also difficult to say why one workshop method has taken one design decision, while the other has taken a different one, or even to say which combination of design elements might be chosen if a new technique was being created. This is where a pattern language approach becomes valuable, as a way of structuring the discussion of design options, allowing us to understand what is distinctive about a particular class of software development tool, and also to understand the ways in which tools in this class might be modified or extended.

We will provide more details of PUX, and will discuss the methodology followed in the analysis presented in this paper, in Section 2.

Alberto Brandolini has created workshop processes for use by software development teams and stakeholders, particularly, though not exclusively, relevant to the methodology of Domain Driven Design [19]. His workshops start with a “Big Picture Event Storming” (BPES) requirements-gathering workshop [7], [8], followed by subsequent workshops that focus on software design. His workshops follow a collaborative process, employing sticky notes as an element of the representational formalism. BPES emphasizes “domain events” as a common unit of discourse that are recognizable to all stakeholders and that are able to be applied as a universal language through which business events can be related to user commands and elements of software architectures. As shown in Fig. 1, a description of a domain event could be something like “invoice prepared”.

There can be up to 30 people with one facilitator at a BPES workshop. The workshop starts with a large modeling surface of blank paper, onto which participants will place sticky notes that describe a business process that progresses in time from left to right along the modeling surface. A collection of sticky notes and marker pens is available and, as the workshop proceeds through phases of increasing complexity, the meaning of sticky notes is recorded on a visible legend to remind participants. The first substantive phase of a BPES workshop is one of “chaotic exploration” [7] where participants annotate orange sticky notes with descriptions of the domain events that they represent and place them, in left–right time sequence, onto the modeling surface. Because workshop participants are likely to have specialized expertise in different parts of the business process, the chaotic exploration phase will likely result in a collection of different, locally-ordered clusters of orange sticky notes.

In the next “enforcing the timeline” phase of the BPES workshop, the orange sticky notes are sorted and moved around to yield a new diagram that shows a consistent description of the business process. Brandolini describes a number of patterns that can be used to enable this sorting and moving [7] including the use of “pivotal events” (significant events that synchronize the flow of the business process), “swimlanes” (horizontal divisions corresponding to events related to different actors), “temporal milestones” (key times that synchronize the business process) and “chapters sorting” (where a separate diagram is extracted that provides a coarse-grained view of the business process). These patterns introduce new graphical symbols: large yellow sticky notes for chapters, blue sticky notes for temporal milestones, tape adornments for pivotal events (vertical tape adornments either side of an orange sticky note) and tape labels for swimlanes. Not all of these patterns need to be used in every workshop and Brandolini recommends that new symbols be introduced “incrementally” so that the graphical notation remains understandable to the workshop participants.

The “enforcing the timeline” phase introduces new “purple” sticky notes that can be placed close to “hot spots” of the business process where problems can occur. This phase also introduces yellow sticky notes to reference important actors associated with events and large pink sticky notes to reference important systems. These sticky notes are placed close to the relevant (orange sticky note) parts of the timeline.

The final phases of a BPES workshop explicitly walk through and refine the diagram and add sticky notes to represent potential opportunities (green sticky notes) as well as any further hot spots (problems) that come to light. Finally, participants are given the opportunity to vote on which problems and opportunities would be most useful for further analysis by labeling these with small blue sticky notes that have been marked with an arrow. (A large clustering of arrows shows a region of the business process that demands further attention.)

As shown in Fig. 2, full-blown BPES diagrams can have considerable complexity. A simpler BPES example is shown in Fig. 3 for part of a business process to manage the submission and examination of theses at a university. In addition to references [7], [8], interested readers can find further details at the Event Storming home page [20] and there are readily accessible descriptions on many third-party blogs on the internet, many of which are associated with software development companies.

User Story Mapping (USM) is a requirements-gathering workshop method created by Jeff Patton [9], [10]. The method is widely used in agile software development to capture key software requirements and to translate them into a backlog for development. A USM workshop involves a core team of developers and stakeholders and the number of participants seems to be between 5 and 10 with one facilitator. According to [10] there are five main steps to USM:

  • 1.

    Frame: Prior to the workshop, develop a “short product picture brief” including the key features the product will have, the key users who will use it and the business rationale behind it.

  • 2.

    Map the Big Picture: Construct a wide and shallow view of the typical use of the software. Start by imagining a “typical day” in the life of one key user and write down the tasks that they would undertake in a narrative order from left to right along the story map. Add other important users and tasks as they contribute to this main picture. Group collections of tasks as activities underneath goals.

  • 3.

    Explore: Fill in the body of the story map by breaking up tasks into smaller tasks, by imagining additional details and exceptions and by generally workshopping.

  • 4.

    Slice out Viable Releases: Slice up the story map into holistic releases and develop metrics for their success.

  • 5.

    Slice out a Development Strategy: Slice out a strategy to develop and deliver the first major release.

In the present paper, we focus on the use of sticky notes in the “big picture” steps 2 and 3 of USM. The following brief description can be illustrated by reference to Fig. 4 which shows a USM version of part of a university thesis examination process (the same process that was shown in the BPES diagram of Fig. 3). Interested readers can also readily find other images of USM in [9], [10] and in many blogs on the internet.

Step 2 of USM starts with participants imagining a “typical day” in the life of one “key user” and writing down brief stories describing the “goal level” tasks that this user would undertake. The sticky notes are arranged on a wall and one or more key-user personas (yellow sticky notes in Fig. 4) are placed on the top left of their block of stories (possibly annotated with a stick figure). Immediately under these personas there will be a row of purple sticky notes representing activities or goals. Under this row there will be a row of green sticky notes that represent the key, goal-level tasks for those personas. This row of tasks is arranged from left to right in “narrative order”, which is defined as being the order that someone might describe the system. The tasks are written as active verbs and they can be combined together with the activity and persona labels to build a story in a widely-used format for agile software development: “As a <user> I want to <task verb phrase> so that <activity or goal>”. For example, in Fig. 4 it is possible to read off the story “As a Delegated Authority [yellow sticky note] I want to Approve the NOE Form [green sticky note] so that I can Launch the Examination process [purple sticky note]”.

In USM, the row of green sticky notes is called “the backbone” of the system. Once it has been agreed upon, then the goal-level tasks are split up into smaller tasks, exceptions, and other details (these other details can also include user-interface design). These smaller tasks and details are written down on yellow sticky notes and are placed next to each other, if they are sequential tasks, or underneath one another, if they are alternate tasks (see Fig. 4). As with BPES, there is considerable flexibility in USM workshops and additional notation can be introduced if needed. This is important to bear in mind when considering the analysis below.

The BPES and USM workshop methods discussed here have an extraordinary internet presence and many explanations of their practice, tutorials and other resources have been presented online by practitioners and software companies. The scale of interest in explaining how the two workshops work in industry is quite astonishing. Because of this vast and accessible literature, we have elected to focus on only a small number of references linked to the original authors [7], [8], [9], [10] in the present paper. However, in this section, we will briefly consider the wider online presence of the two workshops to provide further avenues of exploration for the interested reader.

Table 1 shows the approximate number of search results obtained for string searches related to “event storming” and “user story mapping” using the Google search engine in private mode on Firefox 78.0.1 (as of July 2020). Although absolute numbers cannot be relied on with such an exercise, all of the searches in the table return many pages of results with the top ranked web pages and videos appearing to be very relevant. Most of the “event storming” search results include the BPES phase of event storming. The relativities between event storming and user story mapping in Table 1 is as expected, because USM is a more familiar workshop process of longer standing in the agile software development community. The YouTube videos related to USM have titles such as “How To Write Good User Stories”, “A Guide to User Story Mapping”, “How to do User Story Mapping”, “Essentials of Agile User Story Mapping”, “User Story Mapping in Practice” and so on. YouTube videos related to “event storming”, include “The Power of Event Storming”, “EventStorming: From big picture to software design”, “Event Storming for Fun and Profit”. Both event storming and user story mapping videos include talks by Brandolini and Patton, respectively, as well as presentations by many other agile experts and resources are available in a wide range of (human) languages.

To give some impression of the many web-pages available from sources that are beyond the “big name” developers, book authors, and promoters of these methods, a random sample of the thousands of tutorial introductions includes recent examples such as the following:

  • Ref. [21] is a blog entry by Danilo Trebješanin for Croatian mobile and web development agency Locastic in which he recommends Brandolini’s book, saying that it solved many problems the company had with client meetings and workshops. Trebješanin reports what colors of sticky notes work well, what materials to have on hand, and how the process works out, with some practical tips on things to be aware of at each step.

  • Ref. [22] is published by Aspire Systems, a Polish software company whose website includes an educational article by Patryk Borowa, explaining their motivation for using BPES, an overview of the process and materials needed, steps to follow in a workshop, and a few points of advice on what to do and what to avoid.

  • Ref. [23] is published by the Open Practice Library, a community-driven repository of practices and tools associated with agile methods consultants Gabrielle Benefield and Ryan Shriver. An article contributed by Matt Takane and four co-authors summarizes the why and how of BPES, and provides a list of materials needed and facilitation guidance.

  • Ref. [24] provides blog entries by Jim Bowes at London-based design agency Manifesto that include a 900 word introduction to USM, illustrated with pictures showing typical stages in the development of a story map for a simple generic e-commerce website.

  • Ref. [25] is the company site for project management application Planio and includes a guide to USM by Jory MacKay, in which he offers ”User story mapping 101”, and a 7-step how-to guide with advice ranging from how to facilitate workshops, to how to translate the resulting user stories into an agile development plan.

  • Ref. [26], published by specialist travel and hospitality industry consultancy AltexSoft provides an overview of USM. Their site offers a ”Complete Guide to User Story Mapping”, outlining the advantages and practicalities of using USM, along with the steps to follow in running a USM exercise.

Section snippets

Methodology

In this paper we have applied the Patterns of User Experience, introduced in Section 1.1, to critique the parts of the BPES and USM workshops described in Sections 1.2 and 1.3 respectively. At its top level, PUX consists of (a) “patterns of usage” or “activities” that describe the different ways that users might interact with notations and (b) “patterns of experience” with the notation that users might find to be more or less valuable depending on the activity they are engaged in. Each activity

Results

Here, we present results for three of PUX’s social activities: Illustrate a Story (SA1), Organize a Discussion (SA2) and Persuade an Audience (SA3) each of which describes the social activities of people who use diagrams in a collaborative context. For each of these social activities, we discuss its enabling patterns and then provide an overall evaluation. The assessments described here also make some use of evaluations of seven remaining (non-social) PUX activities that are omitted for the

Overall results and recommendations

For BPES, the PUX analysis of the social activities provided a mixed result for SA1 (Illustrate a story), a generally positive result for SA2 (Organize a Discussion) and a mixed result for SA3 (Persuade an Audience). For USM, the PUX analysis of the social activities provided a mixed result for each of SA1, SA2 and SA3. Overall, the evaluation ratings for both workshops were quite similar to each other. However, the qualitative discussions of each of the PUX patterns has suggested some

Conclusions and future work

In this paper we have applied the PUX analytic framework to critique the way that sticky notes are used in two case studies of software requirements-gathering in workshop settings. Our case studies were based on specific steps in the Big Picture Event Storming (BPES) and User Story Mapping (USM) workshops as described above. This is the first time, to our knowledge, that an analytic framework has been applied to critique sticky notes as notations in workshop settings.

We found that the PUX

Declaration of Competing Interest

The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.

Acknowledgment

The authors wish to acknowledge Alberto Brandolini for helpful discussions and for permission to reproduce Fig. 1, Fig. 2.

Henry Gardner is a Reader in the Research School of Computer Science at the Australian National University (ANU). He holds qualifications in science and computer science from the University of Melbourne and a Ph.D. in theoretical plasma physics from the ANU. He has published about 100 refereed papers and conference proceedings on a range of topics including nuclear and plasma physics, computational science, virtual reality, human computer interaction, computer music, computer games and software

References (37)

  • BlackwellA.F.

    Ten years of cognitive dimensions in visual languages and computing

    J. Vis. Lang. Comput.

    (2006)
  • GreenT.R.G. et al.

    Usability analysis of visual programming environments: A ’cognitive dimensions’ approach

    J. Vis. Lang. Comput.

    (1996)
  • BlackwellA.F. et al.

    Formality in sketches and visual representation: Some informal reflections

    Creativity Res. J.

    (2008)
  • CherubiniM. et al.

    Let’s go to the whiteboard: How and why software developers use drawings

  • Software Designers in Action: A Human-Centric Look At Design Work

    (2013)
  • GrayD. et al.

    Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers

    (2010)
  • BlackwellA.F. et al.

    PUX: Patterns of user experience

    Interactions

    (2010)
  • BlackwellA.F.

    A pattern language for the design of diagrams

  • BrandoliniA.

    Event Storming

    (2020)
  • BrandoliniA.

    Presentation at Explore DDD Conference, Denver, USA

    (2017)
  • PattonJ.

    User Story Mapping: Building Better Products using Agile Software Design

    (2014)
  • PattonJ.

    Story map concepts

    (2018)
  • AlexanderC. et al.

    A Pattern Language: Towns, Buildings, Construction

    (1977)
  • AlexanderC.

    The Timeless Way of Building

    (1978)
  • GreenT.R.G.

    Cognitive dimensions of notations

  • HadhrawiM. et al.

    A systematic literature review of cognitive dimensions

  • CardS.K. et al.

    The Psychology of Human-Computer Interaction

    (1983)
  • FincherS.

    Patterns for HCI and cognitive dimensions: two halves of the same story?

  • Henry Gardner is a Reader in the Research School of Computer Science at the Australian National University (ANU). He holds qualifications in science and computer science from the University of Melbourne and a Ph.D. in theoretical plasma physics from the ANU. He has published about 100 refereed papers and conference proceedings on a range of topics including nuclear and plasma physics, computational science, virtual reality, human computer interaction, computer music, computer games and software engineering. He is co-author of the monograph “Design Patterns in e-Science” (Springer, 2007).

    Alan F. Blackwell is Professor of Interdisciplinary Design at the University of Cambridge Department of Computer Science and Technology. After a professional career in software engineering and software development tools research, he returned to academia to complete a Ph.D. studying the human factors of diagram use. He carries out practice-led and critical design research across a variety of technical and arts disciplines, and has developed a design curriculum that spans all years of the Cambridge Computer Science degree programme.

    Luke Church is an Affiliated Lecturer at the University of Cambridge Department of Computer Science and Technology. His research interest lies in the design of socio-technical systems and improving peoples’ experience of complexity in domains ranging from humanitarian interventions to buildings and to programming languages.

    View full text