INTRODUCTION

This chapter covers some additional topics that are not part of the syllabus for the BCS Foundation Certificate in User Experience. This is background information that will prove helpful when using the core techniques in practice. It is largely concerned with how to reconcile the model of system design activity presented in the earlier chapters with other prevalent models.

First, we look at the Agile development approach. We then discuss design thinking and the double diamond model. In each case, we show how the model is basically consistent with the user-centred design cycle but requires some adjustments. We also consider how UX work fits in with the Agile delivery life cycle as promoted by the GOV.UK service manual.

Finally, we look at some approaches to systematising the preparatory work that needs to be done to get either user research or UX design work off the ground: style guides, design systems, ResearchOps and DesignOps.

The syllabus for the BCS Foundation Certificate in User Experience is covered in Chapters 3–11. The material in this chapter is supplementary and is not examinable.

UX AND AGILE DEVELOPMENT

The Agile approach to software development includes the following features:

• Multidisciplinary, ideally co-located teams.
• A strong emphasis on continual, face-to-face communication.
• Instead of formally documented requirements, a continually managed and prioritised backlog of user stories and an emphasis on prototyping.
• Iterative development organised into short (usually two-week) fixed periods, known as iterations, sprints or timeboxes.
• Frequent incremental delivery of software as early as possible.

The overall result of these measures, if done properly, is a dramatic reduction in the likelihood of delivering a product that is not fit for purpose. This is mainly because the iterative development approach allows for frequent feedback, ensuring that the project does not go too far off track in terms of delivering what users need. This is contrasted with the so-called waterfall approach, where an attempt is made to agree and document all the requirements before development is started – an approach with very little scope for feedback and hence learning.

In Scrum, the most well-known variety of Agile, there are three fixed roles: Development Team Member, Product Owner and Scrum Master. The Product Owner is the single individual who is responsible for managing and prioritising the backlog. In common with other well-known Agile methods, Scrum does not define the method to be used for finding out the users’ needs or evaluating how well the product meets them at any stage.

Agile thinking is deeply ingrained in many software product development organisations. In one way, Agile and user-centred design complement each other beautifully: both are based on continuous iteration and prototyping, recognising the importance of validated learning and short feedback loops. However, in practice there can be tensions and difficulties that arise from the variations in approach between developers, analysts and designers.

The most popular Agile approach, Scrum, is often interpreted as enshrining the principle that a project should start delivering usable software from the end of the very first iteration. This can be a problem for user researchers, who want to carry out user research before creating any prototypes. Not only that, but if the development team rushes into building software before a coherent design concept has been created, the result is likely to be a product with an incoherent user interface and many usability problems.

Possible countermeasures for this are:

• Insert design spikes into the process, where design issues can be explored outside the constraints of the sprint schedule.
• Have the UX practitioners keep one or two steps ahead of the developers by working on the sprints that are due to be developed later. This compromises the Agile ideal of a multidisciplinary team working together to create solutions for the user stories in each sprint.
• Make a UX specialist the Product Owner.
• Be as well prepared as possible for the work on interaction design and visual design by putting in place a design system (see below).
• Have a Sprint Zero before development commences, where research can be done and a style guide created. However, this is unlikely to be sufficient.
• If the team uses a method like Dynamic Systems Development Method (DSDM), this includes a Foundations phase where research can be carried out; but what is really needed is a way of carrying out all UX research and design activities continually, throughout the project.
• Treat research, design and development as separate projects or sub-projects and create opportunities for them to inform each other as the work progresses.

Since one of the proven strengths of Agile is its insistence on multidisciplinary teams, arguably the most productive approach is to keep the whole team together in a single project but ensure that the objectives of each iteration are not defined in terms of getting functionality ‘done’, but rather with reference to the validated learning approach described in Chapter 6, in terms of creating understanding.

UCD AND DESIGN THINKING

Sprints in Scrum should not be confused with design sprints. A design sprint (Knapp et al., 2016) is a process defined at Google Ventures for exploring a situation, generating a problem statement and creating a prototype solution within one week. This is an example of design thinking (Brown, 2009), which aims to apply a design mindset to enterprise-level situations.

A well-known metaphor in design thinking is the Design Council’s Double Diamond (Design Council, 2007). This shows the project process graphically in terms of two phases: an initial discovery phase of divergent thinking, which narrows down to a single point where the problem has been tightly defined; and a later phase of solution creation, where divergent thinking is again employed to develop a range of design concepts for solutions to the problem, before converging again for delivery. Figure 12.1 shows the double diamond with its four associated design activities: Discover, Define, Develop, Deliver.

Figure 12.1 The double diamond

The four activities can clearly be related to the four main threads of the user-centred design helix (see Figure 3.2), although the fourth stage, ‘Deliver’, does not explicitly include evaluation with users. However, the double diamond itself shows the project as being divided into exactly two main parts, with the first being orientated towards producing a single definitive problem statement, and the second towards delivering a solution that satisfies the problem statement. Therefore the double diamond has been re-thought by many designers to show that consecutive phases of divergent and convergent thinking are indeed employed on design projects, but these phases are not necessarily restricted to two in number. On the contrary, arguably there should be one pair of diamonds for each iteration through the user-centred design cycle. In addition, the iterations do not have to form a linear sequence but can branch outwards to create a more complicated pattern reminiscent of the knitting on an Aran sweater (Figure 12.2).

Figure 12.2 The Aran sweater

UCD AND AGILE DELIVERY

The Agile delivery process promoted by the GOV.UK service manual includes the following phases for designing and developing a service:

• Discovery: this is very much a research-focused phase, so in terms of the UCD cycle, the main activity here is Understand the Context. This includes finding out about the users and their goals, as well as the wider technical and social environment that the solution must operate within, and the policy intent – arguably a very specific type of high-level stakeholder requirement. No prototype should be produced at this stage.
• Alpha: here, the team focuses on envisioning and building prototypes, evaluating them with users and developing a solid understanding of user needs. The prototypes should be aimed at testing the riskiest assumptions, as described in Chapter 6.
• Beta: this involves taking an iterative approach to develop the service into something that will meet the success measures defined in the Discovery phase. Key techniques here are hypothesis-driven experiments and usability testing. The Beta phase starts with a private beta, where a limited number of people are invited to participate in evaluating the service, and then moves into a public beta, where anyone who needs the service can use it
• Live: the team will become smaller at this point, but the service is still iteratively improved.

This structure fits in very well with the approach described in this book.

UX PROCESS MATURITY

Design systems, or design languages, developments from the older idea of style guides, are formats for re-using design work across teams and projects in an orderly way. These provide a consistent and coherent basis for design work and encompass, to varying degrees, elements of visual design and interaction design. Notable examples of design systems are:

• The BBC’s Global Experience Language (GEL) (www.bbc.co.uk/gel/)
• The GOV.UK Design System (https://design-system.service.gov.uk/)
• Google’s Material Design (https://material.io/)
• Microsoft’s Fluent Design System (https://www.microsoft.com/design/fluent/)
• Apple’s Human Interface Guidelines (https://developer.apple.com/design/human-interface-guidelines/)

The websites associated with each of these examples provide an excellent resource for anyone wanting to understand how interaction design and visual design outputs can be documented and organised at scale.

ResearchOps (https://medium.com/researchops-community) and DesignOps are two evangelising movements concerned with bringing order and scalability to user research and design respectively, as well as playing a role in balancing out the influence of Agile with other perspectives.

SUMMARY

The principles underlying Agile development are entirely in tune with user-centred design. However, Agile projects are often focused on delivering ‘working software’ at too early a stage, when delivering improved understanding would be a more appropriate objective.

The double diamond activities – Discover, Define, Develop, Deliver – are compatible with user-centred design, but a truly iterative approach contains multiple ‘diamonds’, not just two.

The GOV.UK Agile Delivery approach is an excellent example of how to use user-centred design for developing a service in practice, at scale and at pace.

The design systems and design languages defined by major software companies and others such as the UK Government and the BBC are useful examples of how to standardise interaction design and visual design.

REFERENCES

Brown, T. (2009) Change By Design. HarperCollins, New York.

Design Council (2007) Eleven Lessons: Managing Design in Eleven Global Companies – Desk Research Report. Design Council, London.

Knapp, J., Zeratsky, J. and Kowitz, B. (2016) Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days. Simon and Schuster, New York.

Wirth, N. (1971) Program development by stepwise refinement. Communications of the ACM, 14(4), 221–227.

FURTHER READING

Battles, M., Black, M., Malouf, D., Whitehead, C. and Bernstein, G. (2019) DesignOps Handbook. Available from: https://www.designbetter.co/designops-handbook

Gothelf, J. and Seiden, J. (2013) Lean UX: Applying Lean Principles to Improve User Experience. O’Reilly Media, Sebastopol, CA.

Jones, J.C. (1992) Design Methods. Wiley, New York.

Merholz, P. and Skinner, K. (2016) Org Design for Design Orgs. O’Reilly, Sebastopol, CA.

Perri, M. (2018) Escaping the Build Trap. O’Reilly Media, Sebastopol, CA.

Ratcliffe, L. and McNeill, M. (2011) Agile Experience Design: A Digital Designer’s Guide to Agile, Lean, and Continuous. New Riders, Berkeley, CA.

Unger, R. and Chandler, C. (2012) A Project Guide to UX Design: For User Experience Designers in the Field or in the Making. New Riders, Berkeley, CA.