The Pragmatic and Practical Design Template

The Pragmatic and Practical Design Template

For discussion/background see this post.

Note: any answer here should be less than 3 sentences, the shorter/clearer/more concise the better – 1 sentence even being optimal. If it requires more, then you probably aren’t using understandable & clear user-focused language. Avoid references to specific technology as much as possible –e.g. instead saying “XML” just say “a file” or “a format” – terms everyone is going to understand. Not all of these questions below are applicable to every case, so don’t try to answer if they don’t fit/apply.

1.           What problem are you solving?

a.            Was something not possible before that should be possible now? Or that you couldn’t do another way? What do you hope to gain?

b.            What is it for? Who benefits? What is the motivation behind it?

2.            What is your high-level plan for solving the problem?

a.            What is your plan?

b.            Commitment: When (what specific date) are you committing to do this by?

c.             Show your high level diagram (typical Level of Detail expected: whiteboard/back-of-envelope/napkin)

3.            Why are you doing things this way?

a.            What are the primary drivers?

4.            Is what you are creating adding value?

a.            Can someone get more out of this approach/thing than they could before?

5.            Will this change behavior?

a.            Is what you are working on really going to change anything? Will someone *want* to use this because it makes their life simpler/easier/more productive?

6.            Is there any alternative or easier way?

a.            What are the alternatives? Are they easier? Cheaper? Quicker?

b.            Does something similar already exist?

c.             How are you able to get more value out of this design than you could with something simpler/easier/quicker?

d.            If this is something hard-to-understand or explain above: What is driving the complexity of this design and is this really the simplest way? Are you using customer-focused language? Have some steps been over-complicated?

7.            Is this actually useful?

a.            Are you making something useful or just making something?

8.            Is what you are doing really worth it?
Remember: don’t go throwing good time after bad work and you can’t get back the money/effort you already expended, so don’t necessarily consider the resources already invested (“sunk costs”).

a.            Is the time, energy, effort, cost, etc. worth what you hope to gain?

b.            What do you hope to gain?

9.            Are there any other dependencies or risks to consider?

a.            Does what you are doing depend on anyone/anything else at all? What are these dependencies / risks? Can they be minimized (by isolating some part of the system)?

10.          Is what you are doing usable in different environments? Is so, what are these things that won’t change in this new environment?

a.            Note: This is the lowest priority for getting work done quickly, but remember to focus on what won’t change as this project matures/ages: good workflow, data model design, portable data – these don’t change & can be useful and used anywhere.

b.            For example, if you do something in .NET, is the design still solid/applicable and is the back-end data still useful if I have to implement this in Python or JavaScript? Code itself is actually fairly useless, but good design, data, and concepts apply anywhere.


These questions together add up to what is frequently referred to as a “Concept” or “Design” Document – but really it is just a set of questions that people have about any endeavor. Put even more simply what they usually want to know is


  • “Would you spend your own money on this?”
  • “Would you do this yourself?”


  • “What are you doing?”
  • “Why are you doing it?”
  • “How much is it going to cost?”
  • “How will I benefit?”
  • “How are you going to do it?”
  • “When are you going to be done?”
  • “What is going to stop you from getting it done on time?”
  • “If you have problems when are we going to know whether we should stop trying to do it”
  • and so forth.

Keeping the language clear, concise, simple, and universally understandable is the hardest part. Avoid technical terms and instead remember to write from the perspective of someone who knows very little about that thing and wants to quickly and easily learn. That is your audience. Especially don’t write from your own perspective, or from someone who is like you and already knows the subject, that person doesn’t even need such a doc.

For discussion/background see this post.

References: heavily adapted from, but inspired by, 37 Signal’s Book Rework “When to Quit” Chapter. Great set of graphics from this book here.


Design Tools

Design Tools (CC2 – Paul Stein – Original Image:


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: