Design, UX, Flow, o dear.
Blog: Process transformation - interventions for meaningful change
I have gotten myself into a discussion @ twitter, and found myself with the following question, asked by Charles Webster MD: “ what is the relationship between interaction design, user experience, workflow & process-aware technology”
It’s a broad question, but I like it, because it forces me to create a coherent view on a number of items I have closely been working on in the last years.
A challenge is that by reading Charles’ blog, I noticed that certain concepts we use might have different names and definitions. And, that we had another discussion going through this, dealing with the limitations of ‘workflow’ versus case management.
For starters, I encountered the definition ‘Workflow’: Workflow is what actually happens when work is done. It is a series of steps, or tasks, that consume resources (money, time, effort, attention), and achieve one or more goals (see here). In my eyes this is a perfect definition for ‘Business Process’. Perhaps due to my BPM-technology background, I typically associate workflow by a process that has been implemented and can be run in a BPM-Suite.
And a later definition of workflow came along by a reaction to the discussion by InformIt:
First Sketches of an App: Planning the Design of a Mobile Application.
Using a BPM-suite, this means that a large part of the software design is fixed (the building blocks, such as the portal, modelling facility, process execution engine, human activity coordination – inbox, form handlers for activity screens, document management module for documents, etc).
Action | Deliverable | Context Expertise | Subject Matter Expertise |
---|---|---|---|
1. Understand the medical staff and their the working context | Empathy maps persona’s, contexts of use | UX | Medical Staff |
2. Understand the activities that needs to be done, when, where, why. Understand the processes, triggers, exceptions. | Process maps | Process analysis | Medical staff |
3. Understand information usage – for each activity, determine information needs, information produced. Understand information requirements from compliancy and management needs. |
Objects/attributes | Information analysis | Medical Staff |
4. Design the ‘workflows’: the series of activities that the system should support. | Executable Process models | Process designer | Medical Staff |
5. Design the user interaction in general: how do people work with the system in general, in terms of access to patient information, inbox of work-items, search, etc., using the contexts of use (mobile workers, administration behind desk, operating room, etc) | General UX concept | UX | Medical Staff |
6. Design the activity forms: when performing a certain activity, how should information be presented, accessed, entered. | UX design of activity | UX | Medical Staff |
5. Design the technical interactions (activities or process fragments that need to interface to technical equipment) | Technical interfaces | Integration expertise | Technical staff |
With the emergence of ‘Business Technology’ we see the trend of ‘The specification/model IS the application’ as I wrote about early here.
– the process/workflow: is the set of activities correct in terms of flow, exceptions, decisions?
– the user experience: can I as a user, in a certain context, perform the activity in an effective, efficient way, and does the system support me in a pleasant, perhaps even motivating way?
– the technical integration
Now, part of the discussion I have with Charles dealt with the notion ‘ Human Centric Design is dead’, pointing to sources such as here and here. First of all, I don’t disagree with the notion of activity centered design, as my actions above clearly show.
The activity centered design is for me a (welcome!) merging of BPM-expertise and UX-expertise.
The BPM-perspective has always placed activities as the center. What needs to be done when, why and by who. And.. what information comes in, is needed, and goes out. But what we have missed as BPM-specialists is often the UX: really understanding the people using it, the context of use (where? how?), e.g. taking a more psychological perspective, in terms of quality of use. As BPM-specialists we dropped BPM-suite driven applications to users, based on sound process analysis and information analysis, that were logically correct. But often not user-friendly. Too rigid. Too complex.
In my last program (a flexible BPM/Case management solution for a Ministry – with lots of adhoc processes, for 1200+ users) we involved a UX-specialist. The value of this UX-perspective (understanding users, their context, ability to prototype, test, and bringing in other ways of looking at forms-designs) has brought enormous advantages.
My notion of Human Centric Design has been formed by my work and various trainings of IDEO and other organizations (Service Design), see for instance here and here.
I think these HCD-approaches did not evolve from a strict user interface design perspective (as I would position D Norman), but much more from a holistic view on people using artifacts and services to collaborate and reach certain goals. These HCD-approaches have a rich toolkit, in which context-of-use, design for emotion and motivation, journeys/jobs to be done and process/workflow perspectives are all seen as essential elements). So from that notion I would be far from declaring HCD as harmful. Activity Centered design is essential part of HCD.
In the end, I think Charles and I are in agreement.
To conclude: a small dive into the limitations of many BPM-tools. In the whitepaper (with the model I designed, positioning various types of processes and associated forms of coordinations), I showed that there are types of processes that are more structured and predictable (doing your expenses) versus more adhoc/less predictable processes. Actually you could see a scale:
1 Structured process, where the full process model is known and all execution paths are known at design time
2 Less predictable, but the activities can be predicted/predefined, just not the sequence/possible paths
3 Even less predictable, the process might even require activity not predefined
The key issue with certain workflow technology or BPM-suites is that they can only support type 1 processes. I predict that in health care many type 2 and 3 processes exist. So to integrate a BPM-engine in an EHR, that supports type 1 only, will severely limit the EHR’s value! And however great the process or UX design, it won’t fix the key issue: users will be locked in ‘ hard’ workflows that will not support all the possible events and paths.
Leave a Comment
You must be logged in to post a comment.