4 ms·

I have a theory. I have been designing software for 9 years. I have been designing Developer products for the last 4 years of my career. Let me tell you somethi

I have a theory. I have been designing software for 9 years. I have been designing Developer products for the last 4 years of my career. Let me tell you something. The developer experience is one of the toughest and roughest experiences for anyone who uses software. From installing a library, to browsing logs. From reading documentation to deploying code. Everything in the developer experience is mined with obscure processes and seemingly impossible to achieve tasks. Every developer eventually figures out a mental framework to work around this experience and consider this a skill that it's part of what makes them good at their job. Of course developers are very smart, so why they "suck at ux"? The problem is that when your tools and processes are full of bad UX patterns you never get an opportunity to really learn and analyze how well-designed professional and productivity software works. I can't tell you that 60%-70% of the things I know come from using software (many times using it for the sake of learning its UX, not because I'm an actual user). Basically, exposure is key and this is why there are UX designers that also suck at their jobs. Developers are trapped in this loop. Homegrown tools rarely include input from designers. Startups in the developer space rarely prioritize design hires. They can only build and try to improve what they already know, so the progress in developer experience is very slow. Any progress depends on companies like Microsoft investing in design. For example Visual Studio Code is a wonderful developer experience in my humble opinion. But it takes more than a good IDE or text editor to create that instinct to identify what's good or bad UX. I wouldn't say that developers suck at UX. They are just not very good at articulating their UX ideas, but some of the best things that I have designed even outside of the developer tools space, came from a developer idea.

mamcx 6y ago
I like this take, and also add that is perpetual: You start with some objectively bad things like bash/terminal/c/c++ and then the tools get replaced with js/electron/etc. From bad to other bad. So giving options, eventually as developer you settle with the less bad or the already understood option. RARELY you start from good, then move to better. --- P.D: I see this in other fields too (ie: That run in a circle of bad to bad...), from my own customers. My UX skills are bare (I align things, use 2-3 colors max, and some typography that is barely decent, and point when logos and icons are terrible, and have the sense of just use one made by designers...). In one app, I just deploy bootstrap as-is with slight increase in font size and base. That was all. I still get kudos for that!
NewOrderNow 6y ago
I really like this take. I was mulling around a thought and I feel this might be a good place to validate it: So I was talking about this with a friend, and I believe that there is an inclusivity to UX that most engineers don't seem to care about or have the patience for. A technological Darwinian mindset where if you don't get it, then you don't get it. The UX designer holds everyone's hand as they run. The Engineer is the person in front telling you to keep up.
- rutthenut 6y ago
  I think this appears to be 'blaming' the engineers, pointing to a lack of patience and so on. The parent idea seems closer, techies get used to working with technology-led tools and solutions, so rarely (less often) get exposed to usability best-practice, for them to consider that as an input requirement.
nfw2 6y ago
I agree. The assertion in the article that "when engineers are developing products strictly for other engineers...their UX is fantastic" seems way off, at least from my experience. I think one of the problems that no one has mentioned yet is that developers like to think about things in logical absolutes, which doesn't work well in UX, which is a more holistic field. In UX, there are always trade-offs. For example: - Adding features to a UI could help support more complex use cases. - BUT the new complexity might using the core functionality harder. - OR we could refactor to a different conceptual model that intuitively supports all use cases - BUT this shift could totally confuse the existing users who are used to the old model. The only way to solve these sort of problems is to collect information about all the tradeoffs, make a judgement call, get the change(s) in front of users, and iterate. Unfortunately this isn't always how internal dev tools are built. I've seen entire systems planned and roadmapped following some abstract ideal like "consistency" or "flexibility" and built out over months or years without ever really consulting the users who will be using the systems. Concerns about the system being too confusing are dismissed because "we'll just add documentation in confluence."

mamcx 6y ago

I like this take, and also add that is perpetual: You start with some objectively bad things like bash/terminal/c/c++ and then the tools get replaced with js/electron/etc. From bad to other bad. So giving options, eventually as developer you settle with the less bad or the already understood option. RARELY you start from good, then move to better. --- P.D: I see this in other fields too (ie: That run in a circle of bad to bad...), from my own customers. My UX skills are bare (I align things, use 2-3 colors max, and some typography that is barely decent, and point when logos and icons are terrible, and have the sense of just use one made by designers...). In one app, I just deploy bootstrap as-is with slight increase in font size and base. That was all. I still get kudos for that!

NewOrderNow 6y ago

I really like this take. I was mulling around a thought and I feel this might be a good place to validate it: So I was talking about this with a friend, and I believe that there is an inclusivity to UX that most engineers don't seem to care about or have the patience for. A technological Darwinian mindset where if you don't get it, then you don't get it. The UX designer holds everyone's hand as they run. The Engineer is the person in front telling you to keep up.

rutthenut 6y ago
I think this appears to be 'blaming' the engineers, pointing to a lack of patience and so on. The parent idea seems closer, techies get used to working with technology-led tools and solutions, so rarely (less often) get exposed to usability best-practice, for them to consider that as an input requirement.

nfw2 6y ago

I agree. The assertion in the article that "when engineers are developing products strictly for other engineers...their UX is fantastic" seems way off, at least from my experience. I think one of the problems that no one has mentioned yet is that developers like to think about things in logical absolutes, which doesn't work well in UX, which is a more holistic field. In UX, there are always trade-offs. For example: - Adding features to a UI could help support more complex use cases. - BUT the new complexity might using the core functionality harder. - OR we could refactor to a different conceptual model that intuitively supports all use cases - BUT this shift could totally confuse the existing users who are used to the old model. The only way to solve these sort of problems is to collect information about all the tradeoffs, make a judgement call, get the change(s) in front of users, and iterate. Unfortunately this isn't always how internal dev tools are built. I've seen entire systems planned and roadmapped following some abstract ideal like "consistency" or "flexibility" and built out over months or years without ever really consulting the users who will be using the systems. Concerns about the system being too confusing are dismissed because "we'll just add documentation in confluence."