This post is the second in a four part series about how to make smarter, better, faster, and stronger workflows. Each post will focus on a certain area. In this post, I’ll discuss how to design better workflows.
You're now smarter about your process, but let's make it better. The current state of the workflow is not an Adonis - meaning it's not perfect. There's lots of room for improvement. When I talk about better workflows I talk about gaining efficiencies and resolving pain points. But better also does not mean perfect. We're taking steps towards having that Adonis workflow, but we're lying to ourselves if we think the process will ever be perfect.
There are two important things to keep in mind when you're designing a better workflow.
- Don't ask "What do you want?"
- This opens up the kitchen sink of requirements and can derail any attempt at making the workflow better. Honestly, often the client may not know what they want. It's your role to curate the requirement sessions and help drive them to an end state.
- Better does not equal more
- When new functionality is possible, just because you can do it doesn't mean you should. Gee-whiz functionality has a place and time. But remember, who are you designing this workflow for? You're looking for gains and optimizations for the client, not a foo-foo workflow that does stuff only because you can.
With those two tenets in mind, how do you go from the current state to the better, future state? Often it's hard to think critically about where pain points can be shed and efficiencies gained. Here's an equation I find useful:
Current State - Pain Points + Efficiencies = Better Workflow
Efficiencies can be as simple as an email or task notification or as complex as a series of ancillary workflows. Don't overthink the efficiencies too much because you don’t want to turn them into burdens – both to developers and end users. So make smart, prudent decisions when weighing how to make things better.
When you're ready to capture what the better workflow will look like, it's best to capture that in a technical design. A technical design is the culmination of designing a better workflow. A technical design defines where this process is currently and everything that's needed to arrive at the future state; it's the product of being smarter about the process and making the process better. Don't be fooled by the title, but a technical design should be written in plain, unpretentious English. This means no tech sp34k.
I've written a post previously that walks through a workflow technical design and includes a sample deliverable.
If we could make all of our processes better, we would. But it requires being shrewd in our assessment of the pain points on how they can be optimized. Don't rush through making the workflow better, but don't be afraid to take chances and gain efficiencies.