It’s week 5 on NHS Jobs, working with Difrent and NHS BSA as a service designer. I have already had four weeks helping and just come off a couple of weeks away. I can highly recommend this tonic: Spend some time absorbing and getting to know stuff, have a break, come back after a bit of away time and brain soaking time, and get working through problems. I also thought it’d be a good time to get back into getting some week notes out in the open.
I came back into work with ideas of I will respect lunch breaks and I will plan stuff in my lunch breaks and I will end on time. First few weeks everyone wants a bit of you so it is hard to maintian that order. FIrst week back, let’s give it a go. Day one back: failed. There is always a lot going on, a lot to dig into, but disappointed myself with my own self management – but there was stuff to catch up on and the work going on was worth it. At the end of the day I noted to make sure I at least went for a run the next day. (I did. It was good.) Today (Friday) I made sure I shut down at 12:15pm to go for a run and am aiming to close up around 5:30pm. Next week I will do better.
I wanted to start back off with some order (with the usual flex), so started the week setting up a board (on Trello) and brain dumping into it to capture a backlog, then draggin out of that what I need to do in the current sprint, what I am on with, and what’s done. It’s small enough to keep track of the service work, the product work, and the team work, but helps me stay focused and prioritised. And as stuff pops up I just add it in. Some of it is small tasks, things can be more thematic, but it helps keep some order.
If you start a new project I always totally recommend something like this, somewhere – Trello, Evernote, whatever – to store anything you hear, see, read, useful links, things you need to delve into, things you have to do – then take some time to shape that massive brain dump. Joining projects that on-the-go is tough stuff. Over the years I’ve only joined one project that treats their wiki as “if you join this team you will get what we are doing and how we doing by starting on our wiki home page”. At some point you might be able to rewrite that wiki home page from your notes. :-)
Pattered throughout the week were chats about ways of working, how can we be consistent across three squads, so we get the point the majority of problems we are solving are products ones not team flow ones. Make sure the team members are focused on their role and the problems they have to solve. But also be respectful and mindful of where people are in their time on this project and in their career. I drew lots of diagrams basically, some more familiar than others, like this one:
As a service in private beta the most regular reminder is to remember we have started with key end to end journeys, we are clear what they are, and we’re learning how to design on and around what is out there. Also, as a web-based product that has started off as an minimum viable product, it’s good to find a team that focused that viable means valuable and usable, not just putting something out there because something is better than nothing. The shape of the MVP has had some thought put into it and there needs to be continual learning. The launch is just the start, eh. I’ve said before that a deadline isn’t the worse thing, it’s the expectancy of what you put out for that date that causes the grief. There’s an idea of mass here – the actual volume is being worked out, but with some agility. Yeah, we have to do x, y, and z but how those things actually work is up to us.
I’ve started to pull together some central references for the squads in the team to refer to, around journeys. Within that I want to bring in some detail from the team around where our journeys and features are at: Have we made compromises to get something (say, a feature) into the private beta of the product? Before I went away we made a start on this, having a light exercise as a team around a particular user journey, printing screens out, sticking them on the wall, to get an understanding of what we have made and how that compares to what we have designed. There are no silly questions and any questions we will get the answers to, now or later. A couple of hours over everyone together is all it took and it produced a lot more shared understanding - and empathy across the team between roles. Sharing together to avoid the silos of people in the silos of their roles in the silos of squads in a team. Bring the team along.
Every chance I can I am nudging the team to emphasise the value of thinking, working things through, appropriately as an individual, but also with other members of the team. Thinking is working too. And also get your thinking down and worked through with your colleagues. Be an effective practitioner and an effective collaborator. Some of this is just getting people to hold off from diving into prototype kits and banging out tickets in Jira, to go through something together. Do we all understand the problem in the same way? What is the problem? How wide have we thought this through? Have we narrowed our focus to help move on our design work? What are the gaps? Can we address those? If we can’t let’s note them so we can. Will any of that stop us progressing? What is possible? How can we help the product owner make decisions? The team are a good crew though, with lots of mutual respect and wanting to do the right thing but also a sense of pragmatism.
It’s the summer holiday so with people away on their breaks a good chance for me to understand the product (and therefore the research around the service) deeper by helping out, getting my hands dirty with some research and interaction design work, and work closer with other members of the team. Also a great chance to avoid floatyitis, that consultanty air that some service design roles feel reduced to. Hover, do “the service design”, float back out. No, no, no. More on that next week.
To lead out, if you’re working or have worked recently on a service or product that helps people find a job and/or helps bodies (particularly public ones) fill vacant positions I and the team would love to hear from you. Get in touch!
Random thoughts that there was not a lot more to
Do in-browser prototypes remove transparency of the maturity and fidelity of thinking? (This also extends to There Is A Website Made In Code So That Code Can Be Lifted To The Proper Thing.)
How do you highlight things that have gone well without making the people feel involved feel like they are on a plinth?
Next week
Next week prep for a ways of working session (agreement on a consistent way of working across squads and a team), a half hour show and tell session on What Is Service Design?, delving into some interactions and interaction design, and continue the journey mapping work.
End note
I removed Slack from my mobile phone before my time away. I haven’t reinstalled it. Life is more peaceful.
This post tagged with:
weeknotes