Functional Task UIs: Instructions, Context Information, Data Capture

When implementing a BPM solution, your first objective is to make sure that you get the Right Tasks to the Right Participants at the Right Time.  That's often easier said than done, but let's assume that we've accomplished that goal...

Now we need to start worrying about how to enable the participants to actually complete their tasks.

When a participant opens up a task, assuming that the task is meant for a human rather than a machine, we need to provide them with a user interface for completing their task and interacting with our BPM system. Implementing these UIs often consumes most of your development effort - I've had clients tell me that they spend 80% of their time on the UIs for the tasks in their process applications.  That sounds horrible, but when you dig a little deeper you'll usually find that projects as a whole are taking a lot less time than they did before - but it's still worthwhile to try to reduce the time is spent building task UIs.

 A functional task UI contains 3 categories of elements:

1. Instructions for performing the task
2. Context Information that is needed to perform the task
3. Data Capture controls for information that must be gathered

I find it very helpful to create "starter" screens for my tasks that break out each of the above categories into separate sections - folks always always dive right into developing polished UIs and skip this step, but they really shouldn't.  Build a "starter" screen as I suggest and you'll identify all the integrations that you'll need - and avoid a lot of headaches later.

Instructions:
What is the user supposed to do?
Instructions "should" be easy... but you'd be surprised.  Even after process analysis some folks are confused what a specific task really needs to do.

Many of the user interface designers that I know hate the idea of putting instructions on their screens.  Designers strive for the "Self Evident" interface where the users just intuitively know what it is that they're supposed to do when presented with a screen.  That's a fantastic goal - but I encourage you to write those instructions down even if your end goal is to build an instruction-less screen.  Even if the end user never sees those instructions, it will help all of the interested parties grasp exactly what the task is that the end user needs to accomplish... it will help you validate the requirements for the screen itself.

Note that the Instructions that we seek are those that help the user accomplish a task, not instructions on how to use a screen. I've blogged elsewhere on the advantages of User Manual Driven Development, which focuses on "how to use" - but don't fall into that trap for your Task UIs.  Focus on "What must be done" rather than on "How to use".

Context Information:
What information that is specific to the task does the user need?

This is where you'll discover all the "Read" integrations that you will need.  You can't display context information unless it's been passed to you, or you can "Read" it from somewhere.  It may take weeks to actually implement those integrations, but once you define the interface to the integration you can create a placeholder and keep on going.

Data to Capture:
What information does the screen need to gather from the user to perform the task?

This is where you'll discover all the "Write" or "Update" integrations that you will need.  The information that you capture on the screen needs to "go somewhere"... and that means you'll either pass it along or "Write" it somewhere.  As with the "Read" integrations, it may take time to build the "real thing", but you've got enough to define the interface to the integration and keep on going.


A Functional UI is way better than an Unfinished UI:
If the UI  for your task has Instructions, Context Information, and can Capture the required data, then you really ought to move on to something else.  It may not be pretty, but it's functional, and you can't deploy your solution until you have a functional UI for every task (so go work on the next one).