Designing forms depending on workflow process
At this point, you've implemented a simple category form and a parent-child product form. By now you should have a good idea of how to design forms in the form design perspective. Also, you should have gained a basic understanding of process design and action design. Now, let's get started with order process -- the last of the functional requirements for our example application.
In this section, we will focus on the implementing the form requirements for the order process. Ordering process represents the transaction that our example application is designed to automate.
Ordering process in our example application?
What are the UI requirements for the ordering process?
- Sales team (call center representatives) can create an order for a customer.
- Customers can login using their registered mail id and confirm, amend or cancel their order.
- Product team must review the orders confirmed by the user.
- Customer relations team must close the reviewed and cancelled orders after getting the feedback about the service and product from the customer.
The easiest way to identify the UI requirements for a model that has a process associated with it is to first create the workflow diagram for the model. Once the workflow activities are identified and the workflow process is designed, determine how instances in each of those workflow activities will be accessed, who will be accessing it, and what actions need to be performed in each of those workflow activities. Let's represent the above information for our example application in a tabular format.
|Workflow activity||Activity owners||Actions allowed||User IDs/User Groups|
|Create orders||Sales Team||Create order||Sales Team|
|Customer review||Customers||Confirm order, Cancel order||Customer's email|
|Product team review||Product Team||Review order||Product Team|
|Customer relations review||Customer Relations Team||Close order||Customer Relations|
|Closed orders||Customer Relations Team||-||Customer Relations|
The above table provides all the details necessary for form design, process design and action design. There are two different ways of designing the forms for the order process. You could either create a separate form for each workflow activity or create a single order form and configure permissions to hide/show relevant data in the form. On reviewing UI design requirements and form elements, it can observed that the same set of elements are required for each workflow activity except for permissions and the actions performed in those activities. Hence, you could create a single order form and configure permissions.
Re-using forms when creating multiple forms
"Forms" widget in the form design perspective provides the option to reuse forms i.e. a form can be directly included in another form. Also, any changes made to a form gets reflected in all the forms where it is included.
Now, let's get started with building the order forms.