Iain Broome
Sheffield, UK
Freelance content designer and founder of Clear Language Club.
81 posts
Posts by Iain Broome
Earlier this week, I shared an article on documenting design decisions. If you and your organisation use Confluence to manage all of the things, you might want to take a look at its very own design decision template.
Use our design decision template to organize your ideas and explain your design solution. Once you’ve brainstormed creative options, use the template to exchange feedback with your design team.
That last bit is worth thinking about, actually.
It doesn't have to be Confluence, but a tool that other people can easily see and contribute to is really important. The alternative? A document that festers deep in some long-neglected folder structure, never to be used by anyone but you.
We've all been there. Come one. Gets your docs out. Make them easy to find.
My primary advice on AI is to be highly sceptical of anyone who tells you they know exactly what they are doing. Or what the future looks like. Instead, read posts like this one by Matt Tyas, Head of Design at the Co-op, which explains how an experienced team is talking, sharing and learning about AI together.
A short and handy intro to design documentation from Colin Baird:
Design documentation is an important part of the design process. It records the thinking behind the designs. It preserves knowledge for future team members. It gives you evidence when stakeholders challenge design decisions. A screen-by-screen explanation ensures that you don’t miss anything. A decision log gives a high-level overview of the who and why of design decisions.
I'm in the process of documenting some of my design work at the moment. For example, I recently updated some content based on feedback from the clinical assurance team. So I made a note of that in our shared decision log.
Having that decision documented will help anyone new to the project understand that there is a very good reason why things are the way they are. They can be reassured that the design work was based on sound clinical guidance.
Read Baird's post if you want to get started with this kind of thing yourself. There is even a useful four-column example you can swipe for your decision log. Lovely stuff.
I'm not sure how I hadn't read this before, but if you're looking for a handy guide to content journey mapping, this is for you.
When we start working on an end-to-end service, we define the users, then map out the journey. This process shows us what tasks users need to complete and highlights where the content doesn’t help them to do this.
What follows is pretty much a step-by-step to get you started. Of course, you'll need to take your organisation's specific circumstances and constraints into account. But hopefully it should be easy to get the right people together and start mapping those content journeys. Also, you can do all this at the start of a content project, not just when things already exist and are ready for an update.
This is a brilliant piece of work by the team at Scope. And of course, almost all of this guidance can be put into action for any user research, not just when its done specifically with disabled people and their families.
I suggest you first read these recommendations by Ema Thornhill, which provide a good introduction to the guidance.
I can really recommend this post on web accessibility by Andrew Tipp at Suffolk County Council. It provides a good introduction to some accessibility basics, but it also includes some good reminders for those who've been doing this stuff for a while.
