Building Adobe WorkflowLab, Part 2: Planning for the Design of WorkflowLab
In part 1 of this series, we delved into the creation of WorkflowLab (initially codenamed Cascade). We started by condensing our project's big ideas into a high-level vision that could be expressed in one sentence: "Build a consistent communication vehicle for workflow, disciplines, tasks, users, products, and technologies that constitute a complete workflow for a project type."
We were trying to create something pretty powerful and all-encompassing. To make it demonstrable and understandable for a two-day presentation to Adobe management, we used Fireworks and Flash Catalyst to build a prototype of the user interface, simulating some of its basic functionality. After getting management's greenlight and a starting project budget, we whittled down our long list of desired features into the top-priority items that we thought we could complete in the designated time schedule, and we created a use case for each of those features.
Next, our design and development teams estimated the time and cost of the work to include each feature, so that we could adjust the scope of the feature or defer it to a future version. We worked until we had a final agreement and sync between the design team, the development team, and the product manager as to what would be included in the initial product.
With the features defined, it was time to start designing, right?
Nope! Not even close.
In fact, as we explain in our book Adobe Flash Platform from Start to Finish: Working Collaboratively Using Adobe Creative Suite 5, there's an important planning step that should come before you do your full-fidelity designs for a project. In the case of WorkflowLab, we were defining a number of features, but we didn't have tangible proof that this was the best option for the product or feature. So we needed a way to test and see visually how the various features were coming together and how they would interact.