The best experiences I've ever had is when you do a bit of both. I've mostly worked in areas where the steps in the workflow were designed to support some manda

The best experiences I've ever had is when you do a bit of both. I've mostly worked in areas where the steps in the workflow were designed to support some mandatory process steps for various compliance or legal reasons. Within a process step there's usually some give and take in the local workflow but most of the eventual users of the software are all too busy to spend lots of time learning new tools and tool workflows. So the solution? 1. Map these intraprocess workflows by talking to the users, find the biggest pain points for automation. 2. Build highly modular tools that implement those workflows and automate those pain points. 3. Deliver the tools into the environment and wait a bit. 4. Re-interview the users and find places in the workflow that are now the newest biggest pain points. Goto step 1. It's a pretty simple process and not hard to do. If you do it right, over a very short period of time you deliver working tools that improve the user's day-to-day jobs and then just...continue to make it better. Fairly often, after a few iterations, you end up just completely automating entire workflows and I've never had users get upset about this. It usually turns out those were boring, dull, and repetitive things they had to do and they hated spending hours of their days doing them anyways. Freeing them up from doing those things means they could move on to higher-value work that was far more interesting for them.