I’ve been lying to my clients.

I’ve been doing it for years, though maybe “lying” isn’t the right word. It’s not quite a telling of untruths, but rather a reluctance to lay truths bare. When I spot warning signs early in a project – a weary stakeholder, an overambitious writing schedule, a grandiose vision – I take silent note. I don’t bring the issue up, and in refusing to do so I create an untruth, a space where I know something but do not volunteer my knowledge, and I start to worry.

Mine is not a puppy’s worry, slobbery and bitey and anxious. My worry is a rigid juggling, a fluid set of movements that belie the contortions required to keep all the pieces in the air. I begin to rearrange schedules and adjust project plans to minimize the risk of fallout. I weave countermeasures into my strategy and deliverables, finding clever ways to protect success from misguided change orders. The juggling looks skilled, even graceful. I’ve had a lot of practice.

This worry comes from a place of arrogance, a place that says, “I don’t trust you to do this right.” It is an abuse of imagination, a subtle and belittling form of violence.

A few months ago I took an acrobatics workshop, where the physical safety of our partners depended on each of us being able to keep our balance.

As we were working through conditioning exercises, practicing unsteady positions on one leg, our teacher asked us to slow our movements down whenever we felt a wobble. The instinct is to speed up: to move quickly through the rough patch until you find yourself back in an area of strength. But to slow down, to stay with the weakness – it is hard, and humbling, and terrifying.

“Anyone can be steady when the body is all lined up and stable. Those places where you can’t hold it, and are starting to fall over – that’s where you need to work.”

So, enough.

This is where I wobble, this place where I work to minimize risks without ever sharing them out loud. This is where I need to spend time.

I started, a few projects back, an experiment. I decided to name my worries and write them down. I wanted to detail all the things I thought might go wrong, all the ways I could predict the project could be thrown off course. But of course I couldn’t share the raw list – it may have been true, and may have been helpful, but it certainly wasn’t kind.

Instead, I began to invert my worries. What did I want the project to look like? What could we all agree on, as a team, about the project’s guiding principles? Not the implementation details, or the content strategy, or the project plan, but the underlying philosophical approach.

Here are some lines pulled from these foundation documents:

  • Every question that we ask of a member needs to provide a benefit to them. If there’s data that we need (for reporting or administration purposes), we need to figure out a way to turn it into a benefit for the user as well.

  • Organization and information architecture should match the way users think about our services, rather than how we manage services internally.

  • None of the site content will be hidden behind a login. User data will be used to lightly customize the experience – for example, pre-filtering lists to match the user’s location – but an anonymous visitor should still be able to quickly find value in the site.

  • Not everything is a core feature. A core feature is defined as “without this, there’s no point in even launching the site.”

  • We are not trying to convince or cater to people who have low or no interest in environmental issues. Our energy is best used to reach people who are ready to take action, not to convince people that they should care in the first place.

I bet you can flip those declarations on their backs and see the soft worrying underbelly of each one. Hints of scope creep, of overreaching editorial plans, of unresearched user assumptions. These foundation documents hold a mashup of UX principles, editorial planning, and content and project strategy. They define what-is-not as often as what-is, and, the way I write them, are usually pretty blunt. This would fit right in:

They’re specific to the project, and are not intended to be – cannot be – exhaustive. A team that’s totally aligned on audience definitions doesn’t need a lot of guidelines around that topic. But that same team, very fuzzy on development planning, needs those core ideas and approach spelled out clearly.

These documents don’t take the place of a discovery phase. For me, they’ve become the strategy-before-the-strategy, a Deliverable #0. We go through the document with our clients, making adjustments and additions until everyone feels the foundation is solid. When, inevitably, issues come up later in the project, we can react with grace, knowing that we’re making decisions based on principles we agreed to when we weren’t under immediate emotional stress.

There’s no magical key that can force a project to run smoothly. But by dumping my worries into this document, and inverting each one into a hope and an expectation, I’m converting my fears into intentions for the project. I’m giving voice to our ideals, dragging risks out into the light, and trusting that my clients are right there by my side.

Dive Deeper

If you want to know more about the Pastry Box Project, you can read about the genesis (and goals) of the project.

Swim In The Stream

A stream of all the thoughts published on the Pastry Box Project is available. Keep it open somewhere, and lose yourself in it whenever you feel like it.

Meet Your Host

There are not only pieces of software talking to each other behind this website. There is a human, too. The Pastry Box is brought to you by Alex Duloz.

Stay Tuned

You can follow @thepastrybox on Twitter. For direct inquiries, get in touch with @alexduloz.