I’ve just finished up at Patterns Day run by the brilliant Clear Left in Brighton.
If I’m honest, I didn’t really know what to expect given this was advertised to web developers. I have an interest in design systems (we’re trying to get clients to think about these over brand or UI books), worked with the on a few digital jobs, and I’m intrigued how service patterns can be documented and continue to live. But what goes into them? How do they sustain? What do they look like? How are they created were all questions I have hunches about and some experience but I wanted to see how others are doing it and the variances across them.Just for clarity, patterns are evidence-based solutions to common design problems.
The Government Digital Service service manual says following design patterns means you:
Design patterns are evidence-based solutions to common design problems.
– avoid repeating work that’s already been done
– avoid making mistakes that others have already learned from
– build on the research and experience of teams across government
– make your service consistent with other government services
GDS Service Manual
I knew today might be quite technical given this is being led by digital industries, and some of it may be quite code-centric but I’ve enough knowledge and basic code comprehension/skills to understand the context so I was ok. My real reason for coming is something people know I’ve been brewing for some time. It is less explicitly digital related but it still crosses over. For the last few years, Snook did lots of research and digital build projects in the mental health space. With young people, adults, around employment, digital services and more. And as we’ve gone about the work we’ve met other awesome agencies who have done the same, health boards who have depths of experience, charities who are looking for help.
And so – I’ve wanted for about 18 months to put on a mental health unconference but with the specific focus of documenting patterns (of various varieties). The ultimate aim being, anyone building or working in this space can learn from what’s been before or be inspired by repetitive user needs that need to be solved. For example, a charitable startup with little funding building a meditation app. Could we have examples of other companies who have figured out mindful notifications and an onboarding process that works so they don’t have to repeat this?
On the less digital end, simple principles for positive environments.The information exists out there, but it’s expansive, and some of the more design-led research (research that proactively supports moving into a design phase out there like user stories) exists in the closed reports of agency and client land (us included). In 2016 we got some of the way of convening a group and in the last year, I’ve been sent names (and met with) lots of people interested in this space.
The reason I’ve taken the time to do this and not rush into it was I wanted to develop a comprehensive understanding of where and how patterns and pattern language could form a viable solution to sharing common insight and learning in a more pro-active way, rather than a lengthy ‘best practice’ guide.It’s not a hack, it’s not a conference, it’s something in between. Like a public design principle library (the product) and a way to bring people together to collaborate in a short time (the network) to build a framework for patterns around a given topic. Or something like that. Simpler call out to come on that later, we’ll be starting up a sign up of interest and collaboration list. I promise! So today – I went in with a lens on how #patternsday could help me think this through. Here are my conceptual takeaways:
- Even if we have a great set of patterns, it doesn’t mean the design will be great
“No pattern library will fix bad design. Patterns can still be badly designed, misused or combined in ways that don’t work as a whole”– Alla
KholmatovaIt’s down to the culture of the team (and organisation) and how they use the patterns, the tools they use to deploy this. No matter how good your patterns are, the ending result might not result in good design. This means, think through who will use your design system and patterns and how.
- Patterns and design systems can be restrictive
The idea of modular designs, the templates you use on the interwebs for your ‘get millennial rich quick’ wordpress all look the same. Paul Robert Lloyd warned about the danger of tight systems that don’t allow any space for creativity. There were some good examples of services like Spotify who have defined design systems but allow for unique collaborations of modular components. This can result in unique branding and marketing that still feels it can break ‘the pattern mold’ but often, we’re beginning to see a lack of creativity with scaled up design systems.
- Patterns can help others solve problems that are conceptually similar
This is the intent for my unconference to uncover common patterns that will help other people solve problems, especially those who don’t have the budget or time to work it out themselves. It’s not restrictive, nor is it about saying ‘this is the only way to do it’ but it’s a proven track record of where things have worked, validated by many.
- Pattern library as a source of truth
Patterns should be validated by various sources and thoroughly tested. They are a place for validation as well as learning. Sarah Heidari talked about this from her work on Grandstand, the BBC’s internal design system. I’d like to think, a shared resource built by lots of talented people who have found similar results from testing apps, trialing services, undertaking research could validate one another’s work.
- Documentation isn’t hard, it just takes time
Ok so the Alice Bartlett talk (mini fan of her slides) was technical but enlightening, I kept up but it was the thinking around documentation that came through for me.When she first joined the Financial Times, she did some user research on Origami. This is a group of services, modules, and tools to help build websites inside FT. Origami helps teams to create a unified style and experience for all FT websites. She found the documentation was boring and confusing. So, she re-wrote the documentation for Origami using the principles used to write Django’s documentation.Her point, documentation isn’t complicated, it’s just hard. But it’s a real part of a living design system, that and communicating regularly with the people who matter, those who use it.
- Systems live, they need to be nurtured and developed
It’s not like patterns will be born and remain static for the duration of time. I know this is a really obvious observation, but when thinking about this in a knowledge transfer context, there needs to be a network of people maintaining and updating information.
- Patterns can be good and bad
Dark Patterns is a great site that highlights the tricks used in websites and apps that make you buy or sign up for things that you didn’t mean to. Time well spent is a site helping you ‘take back control’ of all the nonsense machine notifications and more that has crept into our devices and interfaces to combat this. It reminded me that possibly, some of what I’m thinking about is design principles and ways to combat bad design. We don’t just have to validate the good, it could be the bad and what ‘not to do’.
- Design Systems are flexible
A strong voice in the Design System community, Alla Kholmatova who’s just written a book called Design Systems (purchase!) talked about three sliding scales of design system approach from organisations.
- – Strict to loose
- – Modular to integrated
- – Centralised to distributed
- She compared the strictness of systems from Air Bnb to Ted’s looser approach of building user interfaces and the results, neither being right or wrong, just different approaches. She built on this to compare their organisational approach from centralised to distributed and the positives and negatives this brings. What it brought home to me, is to consider the community around public design patterns and how you maintain them. Distributed (like open source) lets you lose on occasion quality control but it opens up a mass of possibility in creativity and improvement capacity.
- Let’s talk about service patterns
- Overall, I’ve got a bit more thinking to do on my pattern thinking, and define whether I’m using the right language, framework and approach. There was a lack of discussion on Service Patterns, if done again I’d love to have someone from Government Digital Service talk about their approach to service patterns and others working in this space.For me, I’m continuing to interrogate this space too. How we can document positive service patterns around mental health services, so we move away from just discussing this in a digital context?
Overall though, great day and wonderful for me to actually spend time out the office thinking about this.
