5 ms·

In all fairness, our UX/UI design studio [1] has worked with engineering teams of big companies. Be it Google engineers or others. The problem, almost always, i

by krm01 7y ago

In all fairness, our UX/UI design studio [1] has worked with engineering teams of big companies. Be it Google engineers or others. The problem, almost always, is that the designers try to design simple UX logic - Engineers try to implement that logic - but someone higher up urges those engineers to add ABC and XYZ. All resulting in an unclear direction, where the engineering teams usually lean towards their boss' opinion. And, unintentionally, remove any logic that was initially part of the design process. To design better products, there should be a better balance between designers & engineers. Adding one guy to your team to 'make this crappy looking prototype pop' isn't going to be very helpful for your users. [1] http://fairpixels.pro http://fairpixels.pro

mac_was 7y ago
Haha! It is not us it is the engineering team blaming culture
alxlaz 7y ago
> All resulting in an unclear direction, where the engineering teams usually lean towards their boss' opinion. What other opinion are they supposed to "lean towards"? Their boss' opinion is the only one that actually carries any sort of authority -- you implement it whether you agree with it or not.
JamesSchriver 7y ago
I think you are making a mistake in your prescription. From my perspective it is not the engineers that need to work closer with the designers, but rather the designers that need to work closer with the managers with engineer support. It's a critical mistake I see all over the place, and it's a rather silly one when you think about it. As you described, the boss can bring the whole thing into disharmony, so why, for better or worse, would you not want to bring that variable into the process loop as closely as possible. I get it, it's not something many want to do and some may even loathe their bosses mucking around and screwing things up, but reality is that if you don't adapt to the process it will guarantee to screw your process up; so just adapt to reality and not let the stubbornness sabotage things.
hinkley 7y ago
We have known for over twenty years that most problems with software come from the requirements phase. We need to stop accepting that we are the guilty party and trying to get our house in order while the one next door is engulfed in flames. The problem is not in how we track our time. In how we organize tasks, in how we deal with technical debt, long-term maintenance, engineering disputes. Documentation. Our problem is in being ill-informed consumers of requirements information. In accepting it instead of sending it back to be done over and refusing to start on anything other than basic R&D until it's sorted. If people aren't told in a clear manner why what they've done is wrong how will they ever improve? And if they know we'll do it anyway, why would they bother changing?
- AgentOrange1234 7y ago
  I love this idea. But I fear I’ll be shot for executing it. :)
- acephal 7y ago
  Holy Christ, I'm like a Junior Dev and once got into an argument with the CEO of the conglomerate I work for after a town hall meeting about how agile was basically only gonna accelerate how poorly we research "the problem space" as I called it. She replied that we weren't gonna do waterfall and that the data supported agile as the company wide prerogative. I replied that what I was asking for wasn't necessarily waterfall, but I also had no other term to describe it, and so she shut down the conversation completely by going, "I'm sorry, but the data supports agile. This conversation is over." It struck me at first as "What the fuck, seriously!?" but then I considered she probably wasn't the one who made that decision or pushed it, but also that I wasn't maybe being clear. So it's helpful to hear that this a bigger issue throughout the industry from a vet Ave not just local to the company I started my career at and so have no other frame of reference
  - sepranu 7y ago
    No offense, but this doesn’t read as a situation you should feel vindicated about. Engineering management is a complicated beast that the average junior dev doesn’t see all the dimensions, let alone the nuances of. Town hall meeting or not, the “CEO of a conglomerate” probably doesn’t want an admittedly inarticulate opinion on what project management style not to use, especially without a clear alternative being suggested.
m12k 7y ago
I've found that ideally all product changes should be developed in close collaboration between a product owner, a UI/UX-person, and a developer. The design shouldn't be made upfront and handed to the developer, it should be made iteratively with the developer providing feedback. And the same goes for the product owner, giving input about user needs and their mental model. The developer should provide feedback about what is feasible and easy instead of just being expected to code up a design that's thrown over the wall. If you allow any of these parties to do most of their work before the others, then you'll get a local optimization that will either constrain the others to do sub-optimal solutions for their areas, or force the final result to break out of the optimum from the first area. The best result comes by having each side provide input in each iteration. Getting a team to work like this is rare though, in my experience - I guess that's part of what makes unicorns so valuable, since they'll integrate several of these roles in one person.

by krm01 7y ago

mac_was 7y ago

Haha! It is not us it is the engineering team blaming culture

alxlaz 7y ago

> All resulting in an unclear direction, where the engineering teams usually lean towards their boss' opinion. What other opinion are they supposed to "lean towards"? Their boss' opinion is the only one that actually carries any sort of authority -- you implement it whether you agree with it or not.

JamesSchriver 7y ago

I think you are making a mistake in your prescription. From my perspective it is not the engineers that need to work closer with the designers, but rather the designers that need to work closer with the managers with engineer support. It's a critical mistake I see all over the place, and it's a rather silly one when you think about it. As you described, the boss can bring the whole thing into disharmony, so why, for better or worse, would you not want to bring that variable into the process loop as closely as possible. I get it, it's not something many want to do and some may even loathe their bosses mucking around and screwing things up, but reality is that if you don't adapt to the process it will guarantee to screw your process up; so just adapt to reality and not let the stubbornness sabotage things.

hinkley 7y ago

We have known for over twenty years that most problems with software come from the requirements phase. We need to stop accepting that we are the guilty party and trying to get our house in order while the one next door is engulfed in flames. The problem is not in how we track our time. In how we organize tasks, in how we deal with technical debt, long-term maintenance, engineering disputes. Documentation. Our problem is in being ill-informed consumers of requirements information. In accepting it instead of sending it back to be done over and refusing to start on anything other than basic R&D until it's sorted. If people aren't told in a clear manner why what they've done is wrong how will they ever improve? And if they know we'll do it anyway, why would they bother changing?

AgentOrange1234 7y ago
I love this idea. But I fear I’ll be shot for executing it. :)
acephal 7y ago
Holy Christ, I'm like a Junior Dev and once got into an argument with the CEO of the conglomerate I work for after a town hall meeting about how agile was basically only gonna accelerate how poorly we research "the problem space" as I called it. She replied that we weren't gonna do waterfall and that the data supported agile as the company wide prerogative. I replied that what I was asking for wasn't necessarily waterfall, but I also had no other term to describe it, and so she shut down the conversation completely by going, "I'm sorry, but the data supports agile. This conversation is over." It struck me at first as "What the fuck, seriously!?" but then I considered she probably wasn't the one who made that decision or pushed it, but also that I wasn't maybe being clear. So it's helpful to hear that this a bigger issue throughout the industry from a vet Ave not just local to the company I started my career at and so have no other frame of reference
- sepranu 7y ago
  No offense, but this doesn’t read as a situation you should feel vindicated about. Engineering management is a complicated beast that the average junior dev doesn’t see all the dimensions, let alone the nuances of. Town hall meeting or not, the “CEO of a conglomerate” probably doesn’t want an admittedly inarticulate opinion on what project management style not to use, especially without a clear alternative being suggested.

m12k 7y ago

I've found that ideally all product changes should be developed in close collaboration between a product owner, a UI/UX-person, and a developer. The design shouldn't be made upfront and handed to the developer, it should be made iteratively with the developer providing feedback. And the same goes for the product owner, giving input about user needs and their mental model. The developer should provide feedback about what is feasible and easy instead of just being expected to code up a design that's thrown over the wall. If you allow any of these parties to do most of their work before the others, then you'll get a local optimization that will either constrain the others to do sub-optimal solutions for their areas, or force the final result to break out of the optimum from the first area. The best result comes by having each side provide input in each iteration. Getting a team to work like this is rare though, in my experience - I guess that's part of what makes unicorns so valuable, since they'll integrate several of these roles in one person.