Paul Robert Lloyd – Time team: Documenting decisions and marking milestones
•Télécharger en tant que PPTX, PDF•
0 j'aime•235 vues
Exercise regularly; eat plenty of vegetables; floss your teeth. Tasks that feel like chores are often the most beneficial in the long run. The same is true of writing documentation. Documenting decisions, recording design iterations and explaining commonly used terminology means everyone on a team can have a shared understanding of a product’s design and evolution. Making this information public can increase accountability and build trust. Deliberately building institutional memory can prevent mistakes being repeated and lessons needing to be learnt over and over again. In this talk, we’ll look at how to record and recall design decisions and consider the role designers play in cultivating a fun yet inclusive culture within a team, and the potential pitfalls to avoid when doing so.
Recommandé
Recommandé
Contenu connexe
Similaire à Paul Robert Lloyd – Time team: Documenting decisions and marking milestones
Similaire à Paul Robert Lloyd – Time team: Documenting decisions and marking milestones (20)
Plus de uxbri
Plus de uxbri (20)
Dernier
Dernier (20)
Paul Robert Lloyd – Time team: Documenting decisions and marking milestones
- 1. Time team Documenting decisions & marking milestones UX Brighton 10 October 2023
- 3. Iterate. Then iterate again.
- 5. Becoming a teacher design history 6 years 630+ posts 7 services 30+ contributors
- 6. A design history looks forwards and backwards. New posts show the team where a service is going, older posts tell the story of how they got there.
- 7. A design history is a blog
- 8. A design history is visible
- 9. A design history is public Make things open: it makes things better
- 10. A design history is public …but it is not for the public
- 11. A design history is for the team – Product managers
- 12. A design history is for the team – Product managers – Delivery managers
- 13. A design history is for the team – Product managers – Delivery managers – User researchers
- 14. A design history is for the team – Product managers – Delivery managers – User researchers – Developers
- 15. A design history is for the team – Product managers – Delivery managers – User researchers – Developers – Stakeholders
- 16. Design can be a chaotic and messy process, but that doesn’t mean we shouldn’t clean up after ourselves once we’re done.
- 17. What to include in a design history?
- 18. A glossary
- 19. A story
- 20. A snapshot
- 21. A record
- 22. An interaction
- 23. A reference
- 24. The only design history entry you’ll regret, is the one you didn’t write. —Adam Silver
- 26. [Stickers] become tokens that represent something more – a shared experience, a shared set of memories that only people who worked on that project will remember and understand. A sticker, like a web page, can be a conscious act of institutional memory. —Giles Turnball
- 28. A mission patch uses a metaphor
- 29. A mission patch tells a story
- 30. A mission patch doesn’t only have to be analogue
- 33. “Who the hell is Brian?”
- 36. Pace layers in government
- 37. We shape our tools, and then our tools shape us
- 39. Fast learns, slow remembers. Fast proposes, slow disposes. Fast is discontinuous, slow is continuous. […] Fast gets all our attention, slow has all the power. —Stuart Brand
Notes de l'éditeur
- Time team: Documenting decisions & marking milestones Presented at UX Brighton, The Projects, Brighton on 10 October 2023
- The GOV.UK Design Principles (https://www.gov.uk/guidance/government-design-principles), a set of 10 values which government service teams are encouraged to follow. They’re a useful reference point when prioritising ideas, making decisions and communicating with stakeholders.
- One of these design principles states ‘Iterate. Then iterate again’. This encourages teams to release minimum viable products early, testing with users along the way. Features can get added or deleted, with services continually refined based on feedback.
- Teams in government tend to follow an agile process, with the design of a service constantly changing. But it’s not only design that changes. Policy decisions; business requirements, ministerial priorities; stakeholder expectations; a team’s understanding of users’ needs. And as team members come and go, research findings disappear, context gets lost and with it the rationale behind the design becomes less clear. It’s hard to keep up! I find it hard to remember what I ate for lunch yesterday, let alone what I was working on a few months back.
- My first experience of working in government, was working in a team at the DfE who were building services to recruit teachers. It was here that I was introduced to the team’s design history (https://becoming-a-teacher.design-history.education.gov.uk), started by my colleague Paul Hayes. This was his answer to that problem of remembering things. Since his first post in December 2017, this design history has grown to include over 630+ posts, covering 7 services written by over 30+ contributors. It stands as an amazing record both for those working on these services now, those that did, and those that will in the future.
- A design history looks both forwards and backwards. New posts show the team where a service is going, older posts tell the story of how they got to where they are now.
- That’s the fancy definition. What I’m really talking about is a blog, with a team committed to regularly posting to it. Blogs are by their very nature, archival, with posts dated and displayed in reverse chronological order. To aid discovery, authors can tag or categorise posts, and you may have a search feature as well. If you include an RSS feed, people can subscribe to updates as well. There are plenty of tools for blogging, and many of them are free to use.
- There are other ways to record decisions of course. A team may already have an internal wiki or some sort of document storage. There’s a number of problems with these however, not least trying to finding content. If you’ve ever tried finding a document on Google Drive or Microsoft SharePoint, you’ll understand this pain. Also, if content is hidden away, it’s tempting to be lazy, perhaps scrappily list a few bullet points which will become meaningless when read back later.
- A design history is not just visible, it’s also public. Making a design history public means posts can be shared, both within your team, but also with those outside it. This very much is in the spirit of another government design principle: ‘Make things open: it makes things better’. Writing in public also forces you to communicate ideas clearly, with fewer assumptions about the reader’s understanding of the context surrounding a decision.
- While a design history may be public, the general public isn’t the intended audience. In organisations which embrace complete openness like Mozilla, advertising where people can read about ongoing design work may make sense. However most organisations, including most teams in government, don’t have the resources to manage that level of scrutiny. So while our design history was public, we prevented it from being indexed by search engines. However it is still public, so anything that’s secret or sensitive shouldn’t be published, nor should any identifiable information about research participants be shared.
- No, the real value comes in addressing the team. For example, product managers may find a design history helpful when scheduling the development of a feature. Having a design documented means it can be picked up later.
- For delivery managers, a design history can be a useful resource when onboarding new team members, or shared with potential hires.
- User researchers can refer to previous entries when planning upcoming sessions, or when preparing a playback and needing to refer to previous findings.
- Design history entries can also give developers some context around a particular feature before they start to build it. They may already be doing something similar themselves. Perhaps they are using Architecture Decision Records, used to inform contributors to a codebase the reasons why certain choices were made, and why things are done a certain way. Git commit histories also perform a similar function, especially useful when reviewing a pull request or reverting a change.
- Having a design history can be useful when preparing presentations for senior stakeholders, too. In the context of government, phases of delivery conclude with a service assessment, part of which focuses on the design decisions that have been made. Pointing assessors to a design history, with its collection of posts detailing an understanding of user needs and design intents, can make the design section of an assessment a formality – or at least help assessors decide where to concentrate their questions.
- Design histories work best when a service is being actively developed, with the design constantly iterated. During earlier exploratory stages of a project, a simpler change log may be more appropriate. The important point is to record changes.
- Documentation is fundamentally an act of professionalism, and designers shouldn’t believe they are somehow exempt. Sure, design can be a chaotic and messy process, but that doesn’t mean we shouldn’t clean up after ourselves once we’re done.
- What you include in a design history is for you and your team to decide, but I’ll offer some examples of what I’ve included in past entries.
- When setting up a design history on a new project, one of the first things I’ll do is create a glossary. After all, there’s nothing civil servants love more than acronyms! Doing this helps me understand a new problem space, inviting deeper investigation into a policy area and the different users and organisations that it relates to. Once published, the team then has a useful resource, and one that can be shared with new team members, too.
- The most common type of posts will be those that provide the story of a design. This could be a post discussing a particular iteration, or documenting the journey to releasing a new feature.
- Simply keeping a record of what a service looks like at a point in time also has value. Some of the earlier posts included in the Becoming a teacher design history were a collection of screenshots of user journeys we had tested. We also added print stylesheets so that when these entries were printed, a screen would be printed to a page. These pages could then be stuck on a wall and annotated prior to the next design revision.
- Some posts may be recording something you know will disappear. For example, our team was replacing a legacy service, but it was quite difficult and lengthy process to sign up for – part of the reason we were replacing it! By capturing screenshots of the different user journeys, this was no longer an issue. It now serves as a nice benchmark, something the team can look back on now the legacy service has been decommissioned.
- Before passing a design on to developers, often consideration is for different states and interactions is needed. Again, we can use a design history to describe these. For example, on our service we need to ask candidates for their nationality. We wrote a design history entry that explained, how candidates can add and remove multiple nationalities, how the form should work without JavaScript and how we can ensure it’s accessible Note that I’m not advocating writing a detailed specification. Ideally, you are working closely with the developers on your team and are able to have discussions as a feature is being built. Maybe the result of those discussions can get added to the entry as well.
- Sometimes a design history can house other useful resources. For example, the legacy UCAS service asked candidates hundreds of questions. We had worked out which were required, which we could remove, and which we’d like to remove but couldn’t, at least not straight away. Colleagues in the policy team were finding it hard to keep track and explain these changes to teacher training providers. So we published a question protocol. This listed all the questions we ask in an application, why we asked them, where the information was to be used and how we would check answers for accuracy.
- When I talk about design histories, people will often ask how keeping one fits into the overall design process; this is a discussion to be had with your team. However, I’d argue that writing a design history shouldn’t be considered something extra, but an integral part of the design process. The main point to note is that it’s not important how or when something is written down, just that it gets written down at all. As my colleague Adam Silver said: The only design history entry you’ll regret, is the one you didn’t write.
- There’s another aspect of a team that is worth recording as well: it’s successes. During the early days of GDS, the team borrowed the idea of mission patches from NASA. They created stickers to mark the passing of significant milestones, so team members had a little marker of success that they could stick on their laptops.
- Giles Turnbull, who worked at GDS at the time, says that stickers tell a tiny story, that they: become tokens that represent something more – a shared experience, a shared set of memories that only people who worked on that project will remember and understand. A sticker, like a web page, can be a conscious act of institutional memory. (https://gilest.org/stickers.html)
- As an artefact designed to celebrate and memorialise a collective achievement, choosing what to include on the team’s mission patch is a brilliant opportunity to engage in a co-design activity. Vicky Teinaki describes a collaborative approach called sticker storming, where a team gathers to decide what to show on their mission patch (https://medium.com/gov-design/metaphors-we-sticker-by-4e4ecdbf8d64). Everyone gets 10 minutes to write some ideas down, one to a sticky note, before placing them on a board. The team then discusses each idea deciding if any should be disqualified, before a round of voting takes place. The winning idea gets turned into a mission patch.
- I ran this exercise with the Becoming a teacher team. We ended up choosing a beaver because we were building a complex service and delivering it in the “rapid-flowing waters of the ever-changing initial teacher training market”. Dubbed Brian, he became our mascot as different phases of the project were delivered. Midway through the pandemic, my colleague Duncan even purchased 60 stuffed beavers and sent one to each member of the team!
- The first mission patch celebrated the launch of our private beta. This took place in a nearby pub at 8pm as a power cut (as well as several fire alarms and a building evacuation) tried to prevent us from flicking the switch. To represent the idea of delivering regardless, the first patch featured Brian wearing a helmet with a head torch. Later patches featured Brian wearing a mortar board after our service opened up to university-based training providers, and another with him demolishing a building to celebrate the legacy service being turned off.
- Mission patches are also an excellent opportunity to flex your design skills and go a little wild with the design. This can be especially enjoyable if much of your time is spent working within the constraints of a design system. For example, I used Russian propaganda posters to commemorate the departure of a user researcher in one patch, and an old Southern Railway poster to mark the many days our policy team had spent on trains travelling the country getting training providers on board.
- With teams increasingly work remotely, it’s a good idea to extend the idea of mission patches into the digital realm. Alongside stickers, I’ve created corresponding custom emoji to use in Slack – these often proved more popular than the stickers.
- A service is only as good as the people working on it, so it’s important to ensure they are happy, recognised and well supported. Designers have a key role to play here, not only in designing outward facing products and services, but representing the culture of the team, and helping to celebrate its successes.
- However, this work should be treated with the same care and attention we give to users of the products we design. A culture can be fragile and fickle, and can work in either a positive or negative direction. When designing for a team we should acknowledge an inherent contradiction: helping it become inwardly inclusive can work to make it appear outwardly exclusive. Many are turned off by the stickers and sloganeering that’s often a feature of government design teams, for example.
- Brian had became a big part of our team’s identity, appearing on different stickers, slack messages and bots. But as new people joined the team, they asked why we had this fixation with a beaver – and why the hell was he called Brian? There’s not enough time to go into his name, except to say that it was based on an inside joke from the very earliest days of the project when the team was no bigger than 10 people. That itself is a bit of a red flag.
- This knowledge needed to be visible and owned by everyone on the team, so where better to document and publicise this than on a page in the design history (https://becoming-a-teacher.design-history.education.gov.uk/mission-patches/). This page not only explained the meaning behind each patch, but also provided high resolution versions that could be downloaded, alongside print specifications meaning patches could be reprinted as new people joined the team.
- The American writer Stewart Brand described the idea of pace layers and how these allow complex systems to learn and adapt (https://jods.mitpress.mit.edu/pub/issue3-brand/release/2). In this model, layers operate independently of each other, at different paces and timescales, each influencing and responding to its closest layer in a way that makes the whole system resilient. You can observe such a system operating within civilisation. At the outermost layer, fashion is frantic and always changing as new ideas are tried and tested. As you move further down the layers, each moves slower until you arrive at nature, which will outlast all before it.
- I think we can map this model to how the delivery culture works within government. At the outer layer, agile delivery tests out new ideas, yet further down this process is underpinned by the values and ethos that has evolved since the earliest days of GDS, and codified in the Design Principles. It’s fascinating to see this process at work, especially as it applies to the adoption of design histories.
- The design history was started by a single interaction designer, who saw a problem so tested out a solution. As more designers joined the team, they saw its value and started contributing posts as well as iterating the underlying tool. Other teams noticed as well. By making the code open source our tool gained wider adoption. Yet there was an underlying problem; we hadn’t spent time integrating it with a content management system (CMS) meaning non-developers were unable to contribute posts. We already had a preference for hiring designers who could code, and having a design history without a CMS further entrenched this way of working, preventing our team becoming more diverse.
- However, since I’ve left the DfE, the design function has matured to the point that a dedicated design ops team has been formed. One of their first initiatives was to build a service that lets anyone in the department create a design history (https://design-histories.education.gov.uk). Backed by an underlying content management system, not only can any team create a design history, but anyone on that team can contribute to it. Design histories are slowly being absorbed into the wider culture of design at the DfE, move into the infrastructure layer of the organisation. But not without the underlying cultural layer exerting itself first.
- Returning to the model of pace layers, Brand said “fast learns, slow remembers”. All durable and dynamic systems have a structure of layers moving at different paces. It is what makes them adaptable and robust to change. In terms of organisations you might describe this as its institutional memory. Recording decisions prevents later teams making the same mistakes, or having to learn the same lessons over and over again. It makes the services we design more resilient as they become the product of continued, sustained iteration and revision, built on the collected knowledge and experience of many. Perhaps the greatest value a design history holds is only known by those that follow.
- © 2023 Paul Robert Lloyd (me@paulrobertlloyd.com)