Defining the Feature Specifications
We had an extensive list of features that we wanted WorkflowLab to include, but we knew that we couldn't get them all into the product within the available budget and timeframe. We decided to prioritize our feature categories, tackling the top-priority items to make sure that we could get them into the product, and taking on other features we labeled "opportunistic" if we had enough time available.
When we created our feature specifications for WorkflowLab, we wanted to start by defining a customer problem and indicating how a feature would address that problem. This approach makes giving the appropriate scope to a feature much clearer, ensuring that you don't over-engineer the problem.
Next, we defined each feature's use case[md]a step-by-step walkthrough of how the feature should be used in the product (see Figure 4). The use cases helped the design process by telling us which user interface elements needed to be designed; they also helped the developers to know which components and logic needed to be in the application code.
Figure 4 Example feature specification for including discipline maps in WorkflowLab.
To help streamline the architecture of each feature, we included a section dedicated to identifying future enhancements. This plan helped the designers and developers on the project to avoid making future enhancements overly difficult.
When the feature specifications were finished, our design and development team estimated the time and cost of the work to include each feature. Based on the estimate, we could adjust the scope of the feature, or we could defer the feature to a future version in order to stay within our time and cost budgets.
Once we had an agreement and sync between the design team, the development team, and the product manager, we were ready to go!