3 ms·
This could be applicable for user-side documentation of any form of bureaucracy as either an employee or a customer (most enterprise fiefdoms basically have to
by devonkim 10y ago
This could be applicable for user-side documentation of any form of bureaucracy as either an employee or a customer (most enterprise fiefdoms basically have to consider other employees their customers) because it tends to follow a really long Gantt chart combined with a digraph (potentially cyclical, unfortunately I found). It also happens to address the usual problems I have with most to-do systems where I can have so many unforeseen problems that it is pretty much impossible to set and achieve goals within a certain allotted timeframe (the GTD system, for example, makes zero promises that you'll be able to achieve any of your set goals even if you follow it perfectly and to your best abilities, after all). It reminds me all too much of writing a nasty mess of nested asynchronous calls where the instant anything went wrong you'd probably wind up at square one.
It's unfortunate how this kind of to-do list is something I've almost never seen considered in an enterprise workflow for UX design because it shows a great deal of integration points that are weak and could use improvement, potentially with minimal resourcing. In my limited practice, I've only ever seen the Fortune 500 basically write pie-in-the-sky Visual Studio sticks and boxes or the equivalent of a nasty nested asynchronous call stack.