I took a yoga class last week where the focus was rhythmic, continuous movement with the breath. If you do yoga regularly, you may wonder “isn’t that every class?” but the core of this session was keeping the breath at the same pace throughout and learning to move around that tempo, rather than adjusting your breathing to match your movement.
At one point we were doing a very simple movement, bending and straightening one leg in cadence with our breathing. The teacher acknowledged that this was no fancy pose, and said:
“The movement is just a device. The movement is a device to tell the breath how long to breathe.”
How much of the work we do is actually a device to help us focus on what’s really important?
The kickoff meeting is just a device to understand the personalities on the team.
The deliverables are just a device to tell the organization what needs to change.
RWD is just a device to get information to the user.
Devices are important: they are the tools we use to guide our attention and unite our teams. Rallying around a concept like RWD gives me a way to introduce related questions about content, performance, and long-term maintenance. Design and consulting deliverables keep us all on the same page with regards to project direction.
But, not uncommonly, I find myself and my clients getting stuck on the tools: you need to do an audit, because the other agency was going to do an audit. We have to do Instagram because other organizations do Instagram. I said I would make a complete list of taxonomy terms, so now I have to create one.
The devices themselves are not the point.
When we get mired in a rigid process, or have written ourselves into a corner with an overly-detailed Statement of Work, we’re paying too much attention to the tools, and not enough to the goals. We’re gritting our teeth and making our knee bend just so while unthinkingly holding our breath.
I’m making a conscious effort to write more ambiguity into proposals, and to give myself the leeway to adapt my work to do right by each project. Instead of promising a hierarchical list of taxonomy terms, I’m promising an understanding of the taxonomy framework, which may include an actual list, or a flow chart for creating new terms, or some other representation of the system. Instead of promising two design comps with two rounds of revisions, we’ll present variations in design direction in whatever way makes the most sense: style tiles, or Pinterest boards, or a slide deck, or full comps. It doesn’t need to be decided beforehand, and it doesn’t need to be the same for every project.
(Can you just do that, though? My most heartfelt advice for anyone running a business in tech: there is no industry standard. Treat your clients well, help them meet their goals, and you can put whatever you want in your stupid contracts.)
Putting the emphasis on the goals rather than the tools keeps my attention where it actually matters, and frees me from having to build out deliverables purely for the point of contractual fulfillment. It gives me the flexibility to look at problems from a new angle, to craft custom solutions, and to breathe.