In object oriented design, the UML offers the use case approach. The design brief takes the information from the use case and documents the requirements in a simple format for developers/users. It acts as a bridge for the detailed logical design and develops a physical design, which documents the technical aspects that describe "how" as opposed to "what." Two briefs are needed - a batch (data warehouse) and an on-line (Java). The on-line brief here.
One of the key challenges in a custom software development effort is creating effective design specifications. A good design provides two key results. It serves as a specification for a developer to build the proper system. It also serves as a communication tool to the user community that the designers understand their business and have designed their business requirements correctly and succinctly. In Object Oriented design, the Unified Modeling Language (UML) offers the tried and true Use Case approach to design. This is an excellent tool to utilize for the high-level design of large systems. Challenges are often encountered, however, when the next level of detail is documented. The Design Brief has worked on many occasions to take the information from the Use Case and document the requirements in further detail in a format that is easier for developers and users to review and understand. It also acts as a bridge to take the detailed logical design and develop a physical design, which documents the technical aspects that describe the ‘how’ as opposed to the 'what'. In most of our engagements there is a need for two flavors of briefs–one for batch (data warehouse) and one for on-line (Java). We will discuss the on-line brief here.
An On-line Design Brief is made up of five sections:
- Overview–This section contains a high-level description of each screen. The description takes the user’s point of view and focuses on the business purpose of that particular screen.
- Screen Prototypes and Component Description–This section contains the screen prototype as well as detailed descriptions of each component (button, link, widget, etc) on the screen. It is important to review screen prototypes with the users early in the design phase in order to validate the concept, functionality as well as the look and feel.
- Mapping of Requirements to Original Use Case–This section cross-references the Design Brief to the Use Case, allowing designers and users to quickly refer back to the original Use Case.
- Glossary of Terms–This glossary is important to ensure that the designers and users are "in sync" with their interpretations and speaking the same language.
- Issues–This section provides an area for both users and designers to record and track all issues, questions and resolutions related to the brief.
Creation of a Design Brief assumes that the high level requirements have already been worked out with the users and the development team can proceed to flush out the remaining details before creating the technical detailed design. A workflow process needs to be created before beginning the Design Brief process. It allows the designers and users to work closely together to get the design finalized and approved in a timely manner. After the designer has identified the requirements to the best of their knowledge, the Design Brief is handed over to the project’s Quality Assurance team for review. This ensures a high quality work product and also gives senior designers an opportunity to review the design before giving it to the users. After IQA gives their stamp of approval, the Design Briefis handed over to the users for review. The user feedback is discussed in a Facilitated Session between the designers and the users. Designers and users meet to work through any open issues/concerns with the Design Brief. A helpful suggestion is to have a projector at the meeting and assign one person to making changes to the Design Brief 'on the fly.' In this manner, everyone can immediately see the changes and further refine the Design Brief as more input is given. The objective is to have an approved Design Brief at the end of the meeting.
There are three major advantages to the Design Brief. First, the development team has complete client involvement in defining the requirements–this reduces the risk that changes will be made later in the project when they are more costly. Second, it allows the team to leverage senior designers across multiple Design Briefs–this provides consistency in the design and allows more junior designers to contribute and grow. Finally, the review cycle is shortened because of its interactive development.
The development of the correct system is onerous, but the cost of implementing the wrong system is even higher. IT professionals today understand the importance of customer service to their user community. This includes not only providing them with a system that reflects their business requirements, but also communicating to the users early and throughout the development cycle that IT understands their business. The Design Brief is an excellent tool for accomplishing both of these objectives. Design Briefs forge a link between users and technical staff to enable better communication of business needs in the iterative design process. Better communication ensures that the correct system is built, while also developing a comfort level with the users of the system that the developers are "on the same page". Additionally, Design Briefs are structured in a way that provides a natural progression to the physical design. All of these benefits combine to provide better communication and better service.
