I'm having a slight disagreement (with an engineer) as to what defines workflow in our software. Any thoughts or experiences on how you've defined / implemented it in your products?
Your perspective, I assume, is the user's workflow. The developer's perspective is more architectural. I generally create two types of workflow diagram, one based on user research and the second after consultation with the developer.
The first is a standard workflow diagram that we all know and love. The second contains stages of interaction, not specific steps. It also captures software architecture aspects that the user touches upon (files, states, modes etc) and overlays the paths that the user takes through the software. Think of it as half way between a UML diagram and a standard User workflow diagram.
I dont have a software specific example that I can show you (IP restrictions). However, here's one for a device that I worked on a long time ago. It's a combination of Presentation Layer and the parts of the system directly hooked to the presentation layer - no more.
Swap the UI controls for what ever you are working on and you have a diagram that both you and the developer can look at, it's a union of your perspectives. I find great value in creating these diagrams... primarily because I'm a visual thinker and find it easier to communicate design intent with diagrams but more importantly it often clarifies misunderstanding between what the user wants to do at a given point and what the software is designed to do.
hope this helps /pauric
In my experience, software engineering people tend to use "Workflow" to describe all kinds of interaction processes between users and a piece of software. Usually this is represented by Swim/Lane or sequence diagrams, often in conjunction with business process definitions. They are used to derive object states, role definitions and individual tasks.
However, these time-oriented concepts fall short of describing non-linear interactions where users jump between different states or use a flexible combination of tools. Then there is no particular sequence or order imposed, making the process analogy difficult - in that case, I prefer the term "scenario" to describe some individual interactions out of a very large set of possible ways to do it. A developer's equivalent would be "use case".
For collaboration processes, for example preparing a report using input and reviews from several people in a sequential order, Workflow is a term that describes pretty well what is happening. But not every software involves such a workflow.
I'm not at all surprised! Workflow can validly mean many different things in different contexts. Among them are:
- the activities that someone (or a group of people) does to achieve a goal (with software or not)
- the way that a goal is supported through activities within a particular piece of software
- as Milan and Pauric describe, the way in which software objects or enttites are passed around and transformed during a process
- a particular method of enabling long running tasks to move through various states over a period of time, without explicit control (c.f. Windows Workflow engine, and others)
There are probably more things that workflow could mean that don't occur to me right now. I would say the key thing would be to sit down with your engineer and agree which of these you are discussing (and which you aren't discussing).
I think one of the most effective way to reconcile these viewpoints is in rich swimlance...and nForm has done some of my favorite work in this area:
It combines personas, scenarios, user flow, system flow, and details effectively. Plus, they have a Visio template you can adapt in Visio or OmniGraffle.
Just a thought.