4 ms·

> The first thing I did was go and talk to people using LabVIEW. ... I conducted 50-something interviews with engineers, designers, and managers across many dif

> The first thing I did was go and talk to people using LabVIEW. ... I conducted 50-something interviews with engineers, designers, and managers across many different teams. Go on... > Next I brought a handful of LabVIEW programmers into a lab and recorded them as they worked on some open-ended refactoring tasks. Exactly. I've never met another developer that observes how their customers (users) use their own stuff. [1] And it's been 20+ years since I've even heard of an org doing any kind of usability testing. (No, A/B testing is not UX.) > Prototypes: Yestercode and CodeDeviant Great and genius. This person is good. I'm sad the world doesn't get to see his other ideas. > ...a very senior engineer interrupted with "This seems like a solution in search of a problem". Not a great feeling. No. This "very senior" engineer is a dick. Failures should be celebrated. You tried ideas this impotent chud could not, would not ever even dream of. Screw him. Engineering, finding the balance between competing constraints, discovering the art of the possible, is one of the ultimate creative endeavors. We use our cunning and wits to more cleverly explore a domain's huge problem space. "Failure" is just ruling out less fit possible solutions. Anyway. This OC (Austin Z. Henley) is a gem. He should ignore the haters. > How do organizations create an environment and culture that allows such behavior? I've only found a few books on the topic: ... Innovator's Dilemma More of a fan of Peter Drucker. But otherwise, I'm hoping Henley figures out how to facilitate creativity and tells us. I should post a picture of my bookshelf of "innovation" books. Maybe save him some time. Until then, from habit, I always recommend: Donald Norman's Design of Everyday Things and followups. He's a humanist and the narratives are relatable. Diffusion of Innovation, because understanding how and why people are motivated to change, or not, will save you a lot of wasted effort. Design Rules: The Power of Modularity is the only book I've found that explains what design and architecture is. -- [1] As a kid, I did a bunch of fun stuff with AutoCAD. So I shared some stuff with yet another person. Then for some reason I stuck around while they tried to install and then use it. More remarkably, instead of mansplaining, I just sat there and observed. This person struggled. And I could see exactly how and why, without them telling me. Mind blown. I had accidentally stumbled onto usability testing and ethnography. Completely changed my life trajectory. User tested all my future stuff. Learned UI. Bought every book. Met every expert.

rt456 5y ago
FYI the UK's government digital service tries to make sure each government service does usability testing as part of their service assessment https://www.gov.uk/service-manual/user-research/using-moderated-usability-testing https://www.gov.uk/service-manual/user-research/using-modera...
- aix1 5y ago
  I can't say whether it's solely attributable to the use of usability testing, but I have to say that I find UK govt's online services very smooth to interact with. Head & shoulders above the average.
snarf21 5y ago
Well said. I design board games as a hobby and we go to playtesting events where random strangers try to play your unfinished game. As you said, it quickly becomes clear what works and what doesn't. It exposes you to people who play your game from a different place and with a different goal than you and your insider group. It is quite eye opening. As you said, the key is to stfu and just watch.
- specialist 5y ago
  Totally. Exercises in humility. Chasing those exhilarating moments when your design just nails it. "The difference between the almost right word and the right word is really a large matter. ’tis the difference between the lightning bug and the lightning." ― Mark Twain
dkarl 5y ago
> I've never met another developer that observes how their customers (users) use their own stuff. [1] Is it so rare? I've worked with product managers who did customer visits and shadowed users through entire days and interviewed their managers and their managers' managers to understand their whole job, not just how they used our software. Most programmers don't have firsthand access to users except when they are working on internal tools, and in that case I feel like it is commonplace to walk over and ask to shoulder surf for a while and then ask questions. Generally it's only a problem if the users themselves don't have the freedom to grant permission (like call center employees) or if travel or access to other facilities is involved. (Although you are right that talking to as many users as the author did would required management buy-in for an engineer that needed to push back other work to make time for it.) The author's case is a special case within a special case: not only were the users internal to his organization, but they were doing software development, which is a job he himself is trained to do! There are reasons why product management is a full-time job, and one of the big ones is that learning the users' business and their job roles is a difficult skill in itself. Usually a user-facing application will have a product manager, and in most cases it won't help if you try to intervene and start doing their job for them.

rt456 5y ago

FYI the UK's government digital service tries to make sure each government service does usability testing as part of their service assessment https://www.gov.uk/service-manual/user-research/using-moderated-usability-testing https://www.gov.uk/service-manual/user-research/using-modera...

aix1 5y ago
I can't say whether it's solely attributable to the use of usability testing, but I have to say that I find UK govt's online services very smooth to interact with. Head & shoulders above the average.

snarf21 5y ago

Well said. I design board games as a hobby and we go to playtesting events where random strangers try to play your unfinished game. As you said, it quickly becomes clear what works and what doesn't. It exposes you to people who play your game from a different place and with a different goal than you and your insider group. It is quite eye opening. As you said, the key is to stfu and just watch.

specialist 5y ago
Totally. Exercises in humility. Chasing those exhilarating moments when your design just nails it. "The difference between the almost right word and the right word is really a large matter. ’tis the difference between the lightning bug and the lightning." ― Mark Twain

dkarl 5y ago

> I've never met another developer that observes how their customers (users) use their own stuff. [1] Is it so rare? I've worked with product managers who did customer visits and shadowed users through entire days and interviewed their managers and their managers' managers to understand their whole job, not just how they used our software. Most programmers don't have firsthand access to users except when they are working on internal tools, and in that case I feel like it is commonplace to walk over and ask to shoulder surf for a while and then ask questions. Generally it's only a problem if the users themselves don't have the freedom to grant permission (like call center employees) or if travel or access to other facilities is involved. (Although you are right that talking to as many users as the author did would required management buy-in for an engineer that needed to push back other work to make time for it.) The author's case is a special case within a special case: not only were the users internal to his organization, but they were doing software development, which is a job he himself is trained to do! There are reasons why product management is a full-time job, and one of the big ones is that learning the users' business and their job roles is a difficult skill in itself. Usually a user-facing application will have a product manager, and in most cases it won't help if you try to intervene and start doing their job for them.