What is a Technical Design (Or Why You Need a Blueprint)

Have you ever had a house built, or an addition added to your house? Did it go like this?

*****

“Good day, Mr. Architectman, I would like you to build a home for me,” Chris VonClient said.

“I would be happy to help, Chris. How big do you want the house to be?” Andy Architectman responded, tilting his head to the right so that he could hear Chris better.

“I was thinking we needed three bedrooms and two bathrooms. So I don’t know, two thousand square feet?” Chris was not really sure what he wanted, but he had a vague picture in his mind.

“Two thousand square feet, eh? Hmm. Yes. I can see it now. That’s enough for a big kitchen, vaulted ceilings, a den in the basement, a living room upstairs. Wait, you do want a basement, right?”

“Oh, that’s a great idea, Mr. Architectman. A basement is just what we need!” Chris was excited. He could see the house better already.

“Alright then. We can get started next week. How’s $150,000 sound and we’ll be done by September?” Andy was quite sure he knew exactly what Chris wanted.

“Perfect! Thanks Mr. Architectman!”

*****

I am hopeful that when you had your home built, it did not go this way. Somewhere in this process, Mr. Architectman built out a full blueprint for the project, perhaps even with visual aids like a 3D rendering of the home so you could walk through it.

Unfortunately, too many software projects are treated like the short story above. With a few descriptive words about the project, the developer is off and running and the client is left to wait for the project to be done.

Honestly, we have done projects this way at MINDSCAPE in the past. It was a long time ago, but still it happened. It was fairly standard practice in the software industry. There are two main ways to protect against this.

The first way is something called agile development. You can go ahead and look that up on Google if you would like, but basically it means that we work directly with the client through all phases of the project. The client asks for something small and we will deliver in a week or two. That thing is then evaluated, changed as necessary and we start work on thing two. It’s a great way to make sure the client gets what they want; but it has two downsides:

1) It is time intensive for the client. We’ll need your ear and your mind a lot of the time during development. That could be a month to a year of work, and not many clients have that time.

2) We don’t know how much it will cost because we are working collaboratively on it. That means we end up charging for all of the time we put into the project. Not many clients are willing to engage in that agreement.

So, we have taken the idea of agile development and married it to a more traditional process. Once we get to development, we make sure the client receives regular updates of what we are building and they will get to play with the software as we work. We do this by breaking up a large development into multiple milestones.

But to get to development, we first have to build the blueprint, and that’s where technical design comes in. There are three benefits to the technical design.

1) The client and the developer can look at words and pictures and sometimes even partially functional prototypes to make sure we see the same ideas.

2) The developer has a better understanding of what the client wants and how long it will take to build.

3) The client can take the technical design and have it quoted by other development companies. Sure, we’d like to have their business, but the technical design ends with a solid deliverable that will give other development shops a solid way to understand the project quickly.

So what does a technical design include? Much of it will depend upon the scope and complexity of the project, but it will always include one or more of the following:

Feature List
This is present in even the simplest design documents. It lists out the features that are needed with a description of what the feature does.

Wireframes
Often, we’ll pair the feature list with a visual representation of what each page may look like. This is not intended to be a final design, but rather a way to communicate how the feature will flow and look on the page. We often use a program called Balsamiq to help this process. Here is what a Balsamiq mockup looks like.

Prototypes
Sometimes, it is necessary to model interactions or complex use cases in a more dynamic way. In this instance we will build out a prototype. This allows the client to play with the proposed solution instead of just reading about it or seeing a picture. This is helpful when there is a lot of animation or fancy user interaction with the application. It is not the final solution, as it will not have any data or logic tied to it, but it is helpful for showing what the application should do.

No two technical designs are ever the same as we tailor it to the client, the project and the scope of work to be completed. However, the technical design should make the requirements clear to the developer and the client, should allow the developers to create a reasonable estimate of work and give the clients a deliverable that they can shop to other developers.

And it’s just a good idea to build a house with a blueprint and not an ambiguous conversation.

Aaron Brander is the VP of Technology for MINDSCAPE at Hanon McKendry.