My Design Process
Over the last couple of years, I have been asked to design several large software systems. While each project has been radically different, I have found myself standardizing on a design process that, at least for me, seems to work regardless of the problem that I am trying to solve. I thought that I would take the opportunity to write up my process for two reasons: first, so that I can check back in on this in a couple of years and see how much I have changed and second, to share with developers that are stepping into a design role and might find my process to be a useful starting point.
In general, I design an application in a series of stages. Generally, the phases are sequential, but there is often a great deal of looping back that happens toward the end of the design process as early assumptions are proven to be incorrect or additional requirements are revealed by the design process.
While this process may not be the poster child for “agile” design processes, it does give us the flexibility to employ a wider array of skill levels during the build phase than would be possible if every developer was responsible for designing as they went. Also, since it is the product of one person (supported by many others), this process tends to lead to designs that are more cohesive than other methods that I have tried in the past.
This is often the first step of my process and can preceed the others by weeks or even months. In this phase, I try to lay down the high level actors in the system and how they might interact to provide the desired functionality. This stage is often kicked off when a project is still being proposed and is used to help the customer understand how we might solve their problem. It can also help inform budgetery estimates by identifying what software platforms and addition infrastructure might be required to support the design.
I know that this is often seen as the realm of a Business Analyst, but as a software engineer, I have found this to be a critical step for me as well. Even if the requirements are known by someone within the development team, I need to internalize the requirements so that I can ensure that the design meets each of those. This phase is also critical for helping me to identify requirements that might be mutually exclusive so that I can bring up the issues to Program Management as quickly as possible
After the requirements have been identified, I move into creating simple use-case diagrams. While I am still exploring these diagrams to see how best to use them, I think I’m getting close. Basically, I use the use-case diagrams to identify the use cases that will meet the requirements (identified above) and what members of the system (from the component diagram) will probably need to take part in filling that use case.
Activity Diagrams and Wireframing
This is the phase where the components are joined together with messages to show how each use case will be implemented. I know that wireframes are the realm of the graphic designer, but I cannot find a way to decouple these in my design process. I use the activity diagrams to show how information flows through the system, including points where people need to provide input. The wireframes allow me to communicate to the graphic design team what information I envision being presented to the user and what actions I need them to be able to take. The structure and style of that presentation is not decided here, only the content itself. I have found that this provides the graphic designers an excellent starting point when they being the “real” wireframes later on.
Depending on who will be writing the software, this step may, or may not be taken. The intent of this stage is to create the detailed design of the structure of the components (e.g. packages, classes, methods, …) and how they will interact. This is, by far the longest phase to execute since almost every member of the application will be created via UML tools. This does, however, provide excellent guidance to external build teams, when they are being used. It also ensure that design patterns and company standards are adhered to.
Over the next few weeks, I plan on expanding on each of these topics to explain in more detail what work I do in each stage with some example of the output. Stay tuned…