Defining graceful degradation, Patterns Day, journey mapping, question protocol mapping
I haven’t written weeknotes in a little while because I don’t always have loads to say. So I think I’ll say things when I have something worth saying. Seems sensible to me.
In defence of graceful degradation
Jeremy Keith commented on my article and said he thinks graceful degradation, the ‘approach’, is different to graceful degradation, the ‘result’.
This in itself captures the problem I was trying to tackle.
I’m not an expert in words, but I do know that words are complicated. They often have several meanings that depend on the context in which they are used.
But what Jeremy said does leave me thinking there’s plenty of room for confusion.
<noscript> to expose a shortcoming—or making things work in new browsers first doesn’t result in a graceful degradation.
Secondly, it probably doesn’t matter that much. If people avoid using the
<noscript> tag and make sure to provide a baseline experience before enhancing, then great.
Call it what you want.
Patterns Day 2
I got to see a bunch of brilliant talks at Patterns Day. The day was really fun. From the content of the talks to watching Heydon operate a keyboard wearing lobster claws.
My favourite talk was Amy’s. She spoke about the role of content design in the context of design systems. This is not only a crucial subject, but is one that’s not talked about very often.
And Amy’s content was executed with absolute clarity and a whole bunch of jokes that kept the audience entertained throughout.
A few weeks back I started a new role. On my first day we had a project kick off with the need to go live in 7 weeks. That’s nobody’s fault but sometimes this is how it goes.
Normally each phase (discovery, alpha etc) lasts longer than that.
I was asked to create some journey maps for our main user types to get everyone on the same page, to spot gaps, and understand the end to end journey as best as we can.
While I’ve helped fill out journey maps in the past, I’ve never facilitated the sessions myself. I was pretty nervous.
But with some help from my friends, I made a plan and created the maps with the content designer, service owner, researcher and business architect.
And it was nice to get over my fear of mapping. There’s no one way to do it and you just do your best and refine as you go.
Maybe I’ll share my, ahem, journey in a separate article.
Question protocolling the shit out of a form
After creating the journey maps we began working on the digital form.
One of the common points of friction in form design, is thinking you need to ask lots of questions to the user in order to run the service.
But we should know why we’re asking every question. If it’s not absolutely necessary to run the service and stop fraud, then we shouldn’t be asking for it.
We’ve been struggling a bit here, so we used the guidance in the service manual by creating a question protocol map in Google Sheets.
We mapped policy guidance to operational needs with different ways to get the data. Importantly, we did this as a team with policy and operations.
After getting to the bottom of how the data will be used, designing the form became a lot easier for us and a lot better for users.
For us to justify asking questions to users, we need to first justify asking questions to ourselves.
Agile family updates
We’ve now been using the family kanban board for enough time for Danny to fill up his points board.
He’s now completed his morning checklist enough times to get himself a new lego helicopter.
He seems chuffed so hopefully the reward is enough for him to continue doing his thing. He’s even asked for some things to be taken off his list and new things put on. Pretty good for 5 years old.
It’s worth noting that there’s a lot more to agile families than just the board, the checklist and family meetings. We’ll be introducing more things when we have the energy to implement them.
New article about form design on the way
I’ve got an article ready to go, subject to a review and edit. It’s an article that tells you everything I know about the fundamentals of form design, so that you can avoid all the mistakes I’ve made when designing forms in the last 20 years.
- Matthew Strom’s delight comes last