The overall process I follow for design is lean and iterative. Once initial insights are discovered using design research and analysis, it is crucial to craft conceptual prototypes that define the right "skeleton" for the solution. Then I rely on building things and putting them in front of people, to learn and course correct. Finally, we work as a team to prioritize and optimize the designs for the real world.
Before directing the implementation of a design, we need to make sure we have a GOOD design. This is more likely when we start with design research, to find the criteria for a successful product (according to the people who will use the process or tool.) In this case, design research means exploring the environment that people use products and follow workflow processes, in order to identify patterns of behavior, data flow, communications and other variables that can in turn be used to drive design. It is also helpful to try out early prototypes during this stage.
Then, we iteratively explore solutions, and make sure to put them in front of people, to pick the most promising approach while simultaneously validating the product concept. The iterative design process is related to the age-old concept of feedback loops, which has surfaced in many forms over the years. Here is one way to illustrate the overall flow of the design process I use, which I first encountered in a class with Kate Gomall and Laurie Vertelney:
As user experience becomes more integrated with lean development methods, specification is becoming less about exhaustive documentation and more about strong communication. In a lean development team, the specification is often simply the software and software documentation, in accordance with Agile principles.
At the same time, some products still require significant documentation, as shown in these examples.