The Design Brief Process


If you want to build something you’re happy with, you first have to understand what will make you happy.

After we set aside the existential crisis associated with that, I’ve developed a process to try and minimize the amount that I invest effort in something I’m not that interested in. This process is an aggregation of a significant amount of feedback and support from friends in the space and their design processes, and I’ve tried to credit them where possible. Generally, I use this when I need to work with someone or have a build that has a lot of intersecting requirements associated with it and requires some degree of optimization. If I’ve done multiple builds of a type, or have a really good sense of what I want to build, this process is less useful, and I’ll generally just freehand out the things I want. My trackbike is a good example of something that had a very simple design brief: A light, high corner speed bike to try and go sub 2:00 at my local tracks. For my box van build, which has a stack of complex uses, this process is critical.

Step One: Write a design brief. (Thanks Richo!)

Step 1.1: What does that brief contain?

To start:

The experience(s) that you want to have. (Thanks Mike K!)

This is important because it’s extremely easy to feature creep yourself to something that doesn’t actually serve your needs, or that misses a critical component of what you’re want to build. As you define the experiences you want to have on a given vehicle, you can identify the things that are critical to having a good experience with that vehicle, and identify from there the requirements to achieve that experience. If you don’t define the thing you want to have up front, you’ll find yourself chasing iterations endlessly. If you’re still running in circles on what you want to do with it, any decision becomes pretty risky if your desire shifts.

Once you’ve established the experiences that define your goals, it’s time to sit down and think through what is needed to have that experience. I like to use XMind for this. With it configured in “Logic Chart (Right)”, I use the following rough template of “Experiences -> Subtype of Experience -> Specifics of Experience -> Things needed to have that experience”.

This is mostly about making sure you are pretty comprehensive about what you want to build, and really understand what things you would like in a perfect world. This is a time to kinda go crazy with the options. You can and will prioritize down later as needed. For the box van, I ended up with this after my set of brainstorming:

Each of these things then gets deconstructed into the sub-sections for what I want to do, and I enumerate what is important to me, and the things that are required for that to take place.

In some cases, where things are particularly detailed, I might add more layers to the area, but that’s the nice thing about the flexibility of XMind – all I really need to end up is with a list of all the things I need to have each experience. As an example, in the food section I wanted a space to define some of the common foods I’d want to be able to prep, and because there’s a lot of common tools there, I found it easier to specify the required things in a group.

As I’m doing this I’ll also consider what the Design Themes are likely to be, and any open questions I might need to answer.

The design themes are useful because they allow me to start to define the commonalities between what I’m doing, and identify any deeply conflicting requirements I might have.

Once I’ve gotten the full stack of experiences reasonably well defined, and I have the set of things I need reasonably well defined, I have a giant list of things that I need in order to support my experiences. From here, I can de-duplicate/identify common functionality needed between activities, and start defining the major projects to build that functionality.

Once the major projects are organized, it’s possible to sort them into groups, priorities, and then begin defining the phases of the build process. This also helps with situations where I need to do definitional work that touches all aspects of the projects. In the case of the box van, this is mostly around defining the sleeping space, and the location for motorcycle transport, as those are fixed elements of the floorplan and restrict my ability to do anything else in that space without significant work.

Usually there’s a bit of back and forth between defining the order on the build process, and the major projects, as I recognize that I need to gather additional information, haven’t adequately defined the details around what I want, or realize that some spaces should be multi-use or some requirements may not be possible in conjunction, and I have to decide what sacrifices I’m going to make / which ones will be least critical to my overall experience.

This also usually allows me to identify one-off projects that can be done without comprehensively re-doing the whole van (for example, installing the hitch), and it’s also critical at this point to take this list, and go trial run some of the experiences I’m trying to have and make sure my list of requirements is actually the things that are important to me. Getting a “minimum viable design” in place that is flexible and allows experimentation really helps when you start committing to certain decisions, like drilling holes in the chassis or building mounting rails for specific tools or devices. Everything can be fixed, but it’s nice to not have to redo things because you didn’t think through what you wanted. A quick retrospective on what you liked and didn’t like can really help clarify requirements. If you didn’t miss it, it probably isn’t needed.

At this point it’s also great to go talk to people who do similar things and get them to poke holes in your design, your requirements, or consider the different ways they might approach some of the problems. Everyone’s got their own stack of things that are important to them, though, so making sure you identify if they want something comprehensively different than you do is pretty critical.

Then it’s the easy part: Just build the thing you’ve defined. I usually dump all the task items into the Notion project I have set up for each build, which helps with knocking out one off items and avoids situations where I start things I can’t complete, or bounce around priorities too often and never focus enough to complete major steps forward.

If you want a custom bike or vehicle built by me, expect that I’m going to go through some kind of variation of this process for your particular build, just to make sure you end up with something that you’re happy with, and you have a reasonable sense of what you’re gonna end up with.

With thanks to everyone who has contributed directly or indirectly to helping me define this process over the years – Mike K, Mike C, Mike KB, Michael G, Jeff M, Jason G, Richo, Nuner, and others.