Next -- Really, that’s Next? – Communicating Workflow

From DevSummit
Revision as of 21:30, 20 May 2015 by Vivian (talk | contribs) (1 revision imported)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Facilitated by Mary Chant UI and Me

A major component of a usable application is that it matches the way users work. Getting workflow right is difficult and yet very rewarding. This session offers participants an opportunity to discuss designing for workflow, and explore the value of adding activity diagrams to the list of deliverables used to communicate workflow and increase product usability.

Notes

How you establish workflow for a traditional application or a web application

Workflow is sometimes the stepchild of usability

Activity Diagrams/Flow Charts

  • Come from UML (unified modeling language) and OO (object oriented)
  • Outlined from use cases

What's the best way to turn requirements into a usable diagram?

  • Record what people are actually doing now in a diagram. Then create a second diagram for how you'd actually like it to work.

How to optimize data entry? Will post links - there are best practices

  • minimize clicks.

How do you get clients to buy into talking about activity diagrams instead of focusing on the actual look and feel?

  • explain that by starting with diagrams prior to wireframes they can save money
  • make the diagrams of tasks and workflow part of the sign-off


How does an activity diagram transfer to a developer?

  • Give them the diagram for sure, a use case, and a functional/design spec

Minimal set of workflow to give to a developer to have a successful projects?

  • Some sort of task representation
  • Some sort of user-task representation
  • Some sort of narrative

Fun New Words

  • Personas (descriptions of different kinds of users)
  • Roles
  • "swimlanes" - matrix of roles with steps for each role (combines role/state/workflow)
  • "guard conditions" - conditions in the workflow that where "this can't happen unless this happens"


Classic Problems

  • Pre-delivered designs that has no workflow behind it
  • Client wants developer to "be creative" - but that can lead to disappointment on both sides
    • Maybe developer should be creative in the diagramming phase - at a higher level
  • There are often no "product managers" in the nonprofit space


Takeaways

  • Even though activity diagrams seem fancy and hard, they can save you money in the long run (don't be afraid of diagramming)
  • Tie in your activity diagrams early in the process
  • Having communication is usually better than not
Retrieved from "https://devsummit.aspirationtech.org/index.php?title=Next_--_Really,_that’s_Next%3F_–_Communicating_Workflow&oldid=956"