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.
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 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.
Naming services is an important part of digital transformation. Service names need to be clear, concise and related to the task people are completing. But this can become harder when the situation becomes more complex.
The thrust of the post is about using dedicated workshops to get all the key people together:
An engaging naming workshop is a way of making sure that everyone has the same level of knowledge of what’s involved in this task, and the importance of it. Getting important stakeholders involved and as close as possible to this work will set you up for success.
I have one extra tip on naming your service. I learnt this the hard way last year. Before you start telling people your new service name, remember to carry out a quick check to make sure that any inevitable acronyms are not, well... a bit rude. Cripes.
