Unsexy Design Work is the work you do as an individual on a daily basis that’s invisible to the people using your services. No one really knows it’s there. It’s very often a thankless task but it’s work that simply needs doing. Operational tasks.
Doing our best to work from home through the Pandemic of 2020 has brought to the surface the importance of doing the Unsexy Design Work. Conversations are happening in the open about working hours and what flexible working means to an organisation.
Many organisations will have already adopted a remote working approach. For us at the NHSBSA, it’s very new, and there are challenges ahead.
Organisations are moving towards asynchronous working – not working at the same time. Not getting into the office between 8 and 9 and leaving between 4 and 5 as typically expected in office jobs. To cope with the pandemic and other responsibilities that are being hurled onto people, working patterns are changing.
This is great and welcoming news. But with this culture shift, there will need to be some changes in how we go about doing our work. Some teams will already be doing this.
Side note: Realistically, this can apply to a wide net of professions but we’ll keep it contextually relevant to design for this blogsake.
Have you ever felt like it’s been a big problem when you’ve taken time off work, and when you return, you’re bombarded with messages, emails and meetings getting stuff from you? People needing to know things from you? Hearing that people’s work is getting blocked because you haven’t been present?
Have you had members of your organisation join the service and you’ve felt like there isn’t a good onboarding experience? You find it’s then taking longer than it needs to get people up to speed and helping them get their bearings before they can start doing the work?
It’s highly likely because you and the team are not in a rhythm of documenting work and making it easily accessible to members of the wider team. There isn’t an agreed workflow within the team.
This is a crucial element to creating an environment which can enable asynchronous working. The health, morale and well being of a team can be greatly improved through great documentation.
I’ve heard this with my own ears so many times. It’s simply not true. At all. Why and how has it become increasingly accepted to not document work under in the name of being agile? What happens when people leave? In places of high turnover, this attitude becomes very expensive and dangerous.
Of course, on the other hand, too much documentation can become documenting for the sake of documenting and then it becomes an overwhelming task which gets in the way of doing your craft.
Facilitate a talk with the team to get an understanding of what level of documentation will be valuable for the team. There is no ‘one size fits all’ framework here unfortunately. It’s entirely dependant on the context of the setup of the team.
As a designer, there are 2 main outputs that others will likely expect of you. 1 is creating designs ready to test with people (only if you’re user centred, gulp) and 2 is creating ‘polished’ stuff which are then ready to be developed.
You might use tools such as Sketch, Figma, Principle, Adobe XD or code to produce your designs. The tool here doesn’t really matter.
What does matter here is the documentation. Documentation a person interacting with your service will never see, but will help everyone on the team understand your work and create slicker working within the team.
Designing how we design is just as important as the design.
You might have a backlog with a series of questions and problems to investigate and you might pick these up as tasks within a sprint and sometimes you’ll create designs as a result to test.
Besides creating the output, you’ll likely need to do some of the following to get to a pretty straight forward design:
Once you’ve created a thing, you might need to ensure you’ve done the following:
The point is that there’s a lot of tasks here where the output is not generating pixels on a page that people using your service will end up interacting with. Sometimes they’re words. Answers which inform and contribute to a design. Add context to why a thing has been made the way it has.
These tasks are all necessary and it’s increasingly important to document this work while we’re working remotely.
It’s always been important, but it’s becoming essential. Not everyone is going to be present at the same time because the needs of the workforce is changing. People need flexibility and more balance. The key to this, is ensuring your documentation can speak for you while you may not be present. People knowing where to go if they need anything. Going to a person should be a secondary action if documentation and commentary has been provided within a tool.
Back in school, when doing maths exams, you might remember that you picked up marks for providing the correct answer as well as showing your workings out.
You couldn’t get full marks for the question unless you provided some documentation to show your workings out and how you got to that answer.
This has stuck with me and influences how we do our work within the team. It’s how I’ve come to assess the quality of my work. “Have I provided appropriate commentary (the marks for workings out) to the artefact I’ve created?” (the answer)
We’re taking small steps to gradually introduce small habits with the goal to leave a trail of our thinking with the aim of ultimately giving us more time to focus on designing.
We’re trying to embed a standard within the team before picking up design work.
There are different types of tasks you can be on with when a service is continuously being maintained and looked after
You can be making a change to a design due to a problem that people are encountering. You may have identified new needs which may result in new functionality to be created.
Before working on something, we’re getting into the habit to make sure the following is written down:
Once we have this, we then provide a high-level commentary of what we’ve thought, considered and who we’ve spoken to. We’re not being too prescriptive with this section.
We don’t want to be rigid here. It’s flexible. Whatever works best for the team. Keep it at just enough. Find out what works well for those who may need to access something.
It’s up to the team as a committee to agree what is a suitable level of documentation that should be expected from each discipline. If you say X is enough for your work, but many others on the team believes Y would be more suitable, then Y would be more suitable. Listen to your colleagues.
Having good etiquette within your team is sexy. Making decisions and thought processes open for others to read and digest is sexy.
It’s really valuable. Take time to ensure you aren't a miss if you're not around for a short while during a working day, or if you're taking time off.
If you’re reading this, and you’re nodding in agreement, or shaking your head in disagreement. Please do message me. I’d love to hear what we could change, start doing or stop doing from what you’ve read.