4 ms·

I think this is pretty insightful. I have some recent experience deploying web-based administrative tools in my organization, which are meant to replace and su

I think this is pretty insightful. I have some recent experience deploying web-based administrative tools in my organization, which are meant to replace and supersede legacy, often informal, workflows. Adoption rates are low and frustration among users is high, and my efforts at understanding this has focused on missing elements in the new workflows -- it seemed likely that, in formalizing the workflow in order to implement it computationally, we missed something, or got the order wrong. The unexamined assumption here is that there exists a correct, usable formal workflow, and that our task is just to find it and code it up, and then users will engage and frustration will recede. But, as the article suggests, this may not be the case. If users are frustrated by the inability to use familiar tools, and to comprehend and execute the sub-parts of the workflow, then no "all-up" integrated workflow will ever feel right to them. Somewhat embarrassingly, the "bricolage" approach also reflects the Unix philosophy, of which I am very fond -- users should be given a suite of powerful, comprehensible tools with narrow and very clear operational scopes, out of which they should build their own solutions.

scottLobster 9y ago
I can't speak for your work, but in my experience most web-based administrative tools are often poorly implemented by the company using them, no matter how good the design. Quite often they're designed for corporate efficiency and not worker usability (ex: This framework has a shitty interface but generates nice looking reports! We're going with that one!), leading to frustration to those on the ground. A good example is my company's Mantis ticket usage. There's nothing wrong with Mantis, but if I file a ticket odds are it will never get looked at for hours or days, whereas if I walk over to our DevOps team and make the request person-to-person it will often get addressed immediately. It's also worth noting that it's less effort to just have a conversation with someone vs filling out a Mantis ticket which then has to be filed/processed/marked as done, etc. The ticketing system actually adds unnecessary overhead in our context. If all formal workflows were as reliable as, say, Amazon shopping and customer service, I think we'd see mass adoption after some initial resistance. I have no knowledge of the organization you work for, but I'd look for problems in execution before seriously questioning the design. Most corporate leadership types consider (wrongly IMO) infrastructure to be a cost center, and that attitude tends to trickle down no matter how good the design.

scottLobster 9y ago

I can't speak for your work, but in my experience most web-based administrative tools are often poorly implemented by the company using them, no matter how good the design. Quite often they're designed for corporate efficiency and not worker usability (ex: This framework has a shitty interface but generates nice looking reports! We're going with that one!), leading to frustration to those on the ground. A good example is my company's Mantis ticket usage. There's nothing wrong with Mantis, but if I file a ticket odds are it will never get looked at for hours or days, whereas if I walk over to our DevOps team and make the request person-to-person it will often get addressed immediately. It's also worth noting that it's less effort to just have a conversation with someone vs filling out a Mantis ticket which then has to be filed/processed/marked as done, etc. The ticketing system actually adds unnecessary overhead in our context. If all formal workflows were as reliable as, say, Amazon shopping and customer service, I think we'd see mass adoption after some initial resistance. I have no knowledge of the organization you work for, but I'd look for problems in execution before seriously questioning the design. Most corporate leadership types consider (wrongly IMO) infrastructure to be a cost center, and that attitude tends to trickle down no matter how good the design.