3 ms·

Is this mostly written for a sysadmin / dev-tool creators audience? As a web developer of consumer (non-technical users), while I found myself agreeing with a l

Is this mostly written for a sysadmin / dev-tool creators audience? As a web developer of consumer (non-technical users), while I found myself agreeing with a lot of these points, I feel as though this was not written with app devs in mind because I don't find the advice very actionable. For example: > your app should mostly expose operational data for its application users, not its developers. Okay, so I agree that we should provide visibility through through _some_ means specific to operators at different levels of abstraction. i.e adding framework middleware logging (if you're building a framework for devs) for app developers so they don't have to add logging everywhere in their app hoping to spot something off. What about the "end end" user - the 60 year old retiree using turbotax. I mean - those are also people feeding input into this complex system. What operational data do you offer them? Or are they not considered operators in this context? (I may have answered my own question haha)

di4na 8y ago
The answer is it depends. In that case i am pretty sure the main target was libraries authors and devtools authors. But we can consider the users as operators. It depends of the use case. For a turbotax example, turbotax is here to give control of a fairly complex system (US taxes) to its operators (60 years old retiree). Now can the retiree learn about it if the optimizations are not enough? Probably not. Or maybe. That is a UX problem right? But think of it. If it fails, who will the retiree call for helps? Experts operators. Hotline for turbotax or accountants. Can you provide them with that info? I especially want to emphasize tools for your Customer Support staff. These are rarely prioritized, but they imho have a far better RoI and customer satisfaction impact than any UX change you can do. CS are operators.
- catwind7 8y ago
  > That is a UX problem right? Ah yeah - I do recall author making that distinction ("user" UX teams vs operator UX teams). > I especially want to emphasize tools for your Customer Support staff. These are rarely prioritized, but they imho have a far better RoI and customer satisfaction impact than any UX change you can do. CS are operators. That's a good point. Right now my team does give tools to CS related staff but you're right they're not prioritized, the UX is horrible (b.c it's "designed" by developers who were tired of having to troubleshoot themselves), and devs get pissed / act surprised when the CS people dont use the tools the "right" way.
  - di4na 8y ago
    Yeah. These are always low priority because they are not from paying customers right? Except they impact your customers directly. Bonus point: they are customers you can easily talk to and watch how they work. Super fast feedback loop ! Want a group to test super fast prototyping and "go live" ? These people are round the corner, will love you for it. They are the perfect place to train a team in velocity...

di4na 8y ago

The answer is it depends. In that case i am pretty sure the main target was libraries authors and devtools authors. But we can consider the users as operators. It depends of the use case. For a turbotax example, turbotax is here to give control of a fairly complex system (US taxes) to its operators (60 years old retiree). Now can the retiree learn about it if the optimizations are not enough? Probably not. Or maybe. That is a UX problem right? But think of it. If it fails, who will the retiree call for helps? Experts operators. Hotline for turbotax or accountants. Can you provide them with that info? I especially want to emphasize tools for your Customer Support staff. These are rarely prioritized, but they imho have a far better RoI and customer satisfaction impact than any UX change you can do. CS are operators.

catwind7 8y ago
> That is a UX problem right? Ah yeah - I do recall author making that distinction ("user" UX teams vs operator UX teams). > I especially want to emphasize tools for your Customer Support staff. These are rarely prioritized, but they imho have a far better RoI and customer satisfaction impact than any UX change you can do. CS are operators. That's a good point. Right now my team does give tools to CS related staff but you're right they're not prioritized, the UX is horrible (b.c it's "designed" by developers who were tired of having to troubleshoot themselves), and devs get pissed / act surprised when the CS people dont use the tools the "right" way.
- di4na 8y ago
  Yeah. These are always low priority because they are not from paying customers right? Except they impact your customers directly. Bonus point: they are customers you can easily talk to and watch how they work. Super fast feedback loop ! Want a group to test super fast prototyping and "go live" ? These people are round the corner, will love you for it. They are the perfect place to train a team in velocity...