The process of using the “design document” is genius. It helps to turn all projects – everything from a simple shopping cart to complex marketing software, into a simple, defineable, and most importantly, executable and (within budgetable — if that’s a word) project.
Without the design document, no matter how good your project management software is — I don’t care if you’re using Attask or Basecamp or anything in between. If you don’t have a design document, you don’t have a project. And it’s impossible to get a project done on time and on budget if you don’t even have a project!
Below is the article on the “Design Document” from Rex’s website: http://streetsmartinc.com/design_doc.php
The Design Process
Imagine for a moment that you want to construct a building. What’s the first step? Conceptual drawings right? Once you agree on the conceptual drawings what’s next? The Construction plans right?
Well imagine for just a moment what would happen if you skipped the first two steps went to a general contractor and said, “Start building here and I’ll tell you how I want it to look later.”
Do you think the building would ever be finished?
How could you know if you were done? Would the building be built in on time and under budget? Would the building be constructed according to any specifications? Would the building have any structural integrity? Could you build such a building within a budget? Could such a building ever be built under these conditions?
The answer to all of these questions is a resounding NO!
And yet software is often just as complicated as constructing a building, but most people skip the first two steps of software development. When you start fixing software that was built under such conditions it looks just like a crumbling old building!
The design document is the most important ingredient in the process of programming a web site, database, or software application. It serves the same purpose as construction blue prints. It must describe the problem and its solution in detail including the interface, database design, and any special problems that might surface while building the software. These problems could be technology related or problems within the company itself that need to be overcome in order to get a finished product.
The process of writing a design document
Before the programming ever begins we get the client’s agreement to work through the design process.We explain that we will be using the design document to build the software, and so the more time spent designing, the less obstacles we will encounter when we build the software—mainly because we will spend less time guessing.
The first step. The first step in design is the overview, which summarizes the purpose and the scope of the software program. The purpose is the reason for creating the software, its objective—the problem it is going to solve. This must be kept in mind at all times while designing software.
Once the overview is written the next natural step is to visualize what the end user will see, and how the end user will interact with the software. This visualization is the first step in designing the interface. We mock up forms and reports to see how and where they’ll be used, and these go into the design document.
As we do this we begin to see what the end user will see, and the designer actually takes on the role of the end user, asking himself, “Does this make sense?” “If I were seeing this for the first time would I understand what to do with it?” “Would I understand what to do next?” “If I were looking at this report would I intuitively know what it’s for? Would I want an additional report? Would I want to change this report to reflect another perspective?”
This is a crucial time for the designer/developer because not only does he become intimate with his own lack of understanding, he also becomes intimate with the internal constraints and unwritten policies of the company.
The objective. The real objective here is to make things self-evident. The designer must pick the right words to describe things. He tells the story of the software in the forms, reports and menus as much as he can. During this phase he must ensure that he covers the basics: how records will be added, edited, updated, and deleted, which forms can be accessed by which end users, and why? This brings up menus, logins and security features.
By doing this we are able to insure that the end user will understand what he is doing because the forms and reports are an extension of his role in the company.
Once the forms and reports are mocked up we go back and allow the client to challenge his assumptions. Usually the client is very agreeable and often we have to teach him that his role is to critically analyze and not merely agree. We often have to teach the client how to think and look at problems within the company analytically and critically; otherwise, we won’t get the design right.
All the forms and reports have to be challenged until they meet the needs of the client. Once this is done we can continue with the other parts of the design document.
Database design. The next step is doing the database design including each table and field, what data types, for example: how many characters need to go into a text field and so on. If there are any relationships between tables that are crucial, they have to be documented.
Once we are through with the database design we go through the design document again and again to make sure that we have looked through every function, every form, and every report to ensure everything is in harmony.
For example: the designer must ensure that the database design includes every field, and can produce every conceivable report the client will need.
This process can sometimes reveal even more holes and/or constraints, either in the company or computer technology, and these have to be documented as assumptions and eventually get approval.
Final approval of the design document. Once we are done with these steps we go to the decision maker who must read each page and initial it signifying they have read it, thought about it and understand it, thus giving their agreement and approval.
Going through the design document page by page is crucial and revealing. Sometimes things are missed, and they have to be added. Sometimes things are misunderstood and must be changed. In both circumstances the designer goes back to his office and reworks the design, and then he goes back to the client and goes through it again. It takes as long as it takes. There are no time constraints. The designer must do this until everything is in agreement, until everything is right, because this document becomes the blue print for building the software.
The next step is to get approval for the entire document by getting the last page signed, and the design document becomes part of the contract to build the software.
The results of having a well thought out design document are numerous:
1. The programming goes smoothly. By thoroughly researching and documenting everything that will go into the programming of the project, whether it is a web site, software program, or database, is built according to a specification, and the whole thing comes off smoothly.
2. Costs are within budget! Since everything is evaluated in advance there are no surprises, and costs are kept within a budget.
3. There is confidence that everyone is on the same page because you have received agreement from everyone in the loop.
4. You get exactly what you expect. The whole process has been thoroughly exhausted so that everyone knows all the parts that will go into the final product and why each part is needed.
5. There is trust because everyone can see from the design document that everything humanly possible has been done to ensure that the software will solve all of the problems that it was intended to.
Rex Parker
President, StreetSmart Inc.
0 responses so far ↓
There are no comments yet...Kick things off by filling out the form below.