7 ms·

And since neither of them are able to actually justify their reasons beyond some vapid and subjective claim of making the product "more delightful" Do you appr

And since neither of them are able to actually justify their reasons beyond some vapid and subjective claim of making the product "more delightful" Do you appreciate the irony that you just wrote a whole post about making decisions objectively, in which you have essentially dismissed designers as ignorants who just make arbitrary decisions according to their personal whimsy, based on a series of unsubstantiated claims, out-of-date stereotypes, and straw man arguments that any half-decent designer could have corrected for you in moments? Why would you think a designer would have no justification for a change beyond “it looks nice”? What would you assume designers don’t understand issues like pixel alignment or designing for multiple devices? Why would you think designers would be raising these issues based on Photoshop mock-ups? Do you understand that there is actual research underpinning a lot of design theory, demonstrating both how humans respond to different design choices and the fact that those choices can directly and sometimes dramatically affect metrics you care about like conversion and retention rates? So if a designer asks for a 3px change without justification, then the engineer should push back until a good reason is given. I wonder how you’d feel if you as a developer were told that every line of code you wanted to change — even those with obvious bugs — could not be touched unless you had previously demonstrated why you expect a measurable benefit to the satisfaction of the business development staff, and that your commit access was going to be revoked and every change would have to be made by bizdev after someone who didn’t know anything about programming decided whether it was justified.

ricardobeat 13y ago
That last paragraph is a fairly accurate description of work at decadent BigCos.
sxp 13y ago
Why would you think a designer would have no justification for a change beyond “it looks nice”? What would you assume designers don’t understand issues like pixel alignment or designing for multiple devices? Why would you think designers would be raising these issues based on Photoshop mock-ups? Experience. I've had arbitrary requests made based on Photoshop mocks. I've pushed back against them after showing that the proposed design looks blurry on devices with a low dpi. Or showing that the UI breaks down in edges cases where the text field contains more text than what is shown in the mocks which results in unwanted wrapping. These are issues that can only be understood by someone who knows the implementation details and constraints of the underlying OS that does the final work of rendering the UI rather than relying on the constraints of Photoshop. Do you understand that there is actual research underpinning a lot of design theory, demonstrating both how humans respond to different design choices and the fact that those choices can directly and sometimes dramatically affect metrics you care about like conversion and retention rates? Yes. And good UX designers know this research which is why they can quickly justify their choices.
- Chris_Newton 13y ago
  It sounds like your real problem has nothing to do with a “design version” or an “engineering version” of anything. You’ve just worked with some people who were in a design role but didn’t know how to do it. That’s unfortunate, but I don’t think it invalidates the original premise of the article that paying attention to seemingly minor design details matters more than a lot of non-designers tend to acknowledge.
  - jessedhillon 13y ago
    I have yet to see a proposed application design or cosmetic change whose justification does not ultimately rely on "this guy's taste is better than that guy's" -- yes designers do sometimes bring out some justifications which are expressed with objective sensibilities but to me they always seem to be rationalizations, in the same way that evolutionary psych seems to be. That is, first see a behavior or a look that seems appealing, then figure out which design principles are making it seem better. I think the best designers temper their taste and predilections with judicious application of statistical methods such as split-testing. I don't find anything objectionable about this, as long as the designer actually owns the design and has the fortitude and clout within the organization to defend their changes. Design seems to me an art in many respects, so some decisions will come down to a matter of taste in the end. Like any successful artist, the designer then will need the persistence to defend their vision against the meddling of bike-shedders. I also think @sxp's characterization of the objectivity of engineering decisions leaves too much out. Engineering debates rarely come down to foosort() v. barsort(), where one obviously performs better. More often, they come down to questions like "should we be passing this argument first or last?", "what should these methods be named?", "can this code be extracted into its own module?" -- in other words, how to design the code.
    - nikatwork 13y ago
      You're not working with properly trained designers then. Layouts have certain empirical properties which can be judged objectively: * Conforms to a grid * Internally consistent padding and margins * Information sized and arranged hierarchically according to importance * Proportions conform to the rule of thirds or golden ratio * Internally consistent UX patterns (eg cancel buttons might be always red, confirm buttons might be always green) * Text column widths are not too wide * Color choice is harmonious (conforms to color wheel rules) These are the main ones but there are many others. Unfortunately, these kind of classic design principles don't seem to be taught very often these days, instead design courses focus on the mechanics ie how to use Photoshop.
10feet 13y ago
> Why would you think a designer would have no justification for a change beyond “it looks nice”? What would you assume designers don’t understand issues like pixel alignment or designing for multiple devices? Why would you think designers would be raising these issues based on Photoshop mock-ups? You are right, they often have good reason, and can make the case by explaining that. Of course, they often to not have a good reason beyond spacing, it looks better, it is too crowded, or it is not crowded enough.
- TheZenPsycho 13y ago
  Isn't it unreasonable to expect that every design decision be based on logic? Human beings have two brain hemispheres. TWO WHOLE BRAIN HEMISPHERES. a right lobe and a left lobe. The right lobe is JUST AS BIG and complicated as the left lobe, in which our logic and reasoning abilities are based. But in our culture, especially in development culture, for some reason any decision based on a process in the right hemisphere is valued far less. We call it "subjective" even though it isn't. It's the same processes that every human brain does in much the same way. This is why optical illusions can work. They work much the same way for every person, and the reasons they work are not based on logic. They're based on physical, biological processes in our visual processing systems. It's not a "logical" or "rational" process. It's a visual process. But if a designer says that spacing is going to cause a problem, it's not valuable input because there is no "logical" reason behind it. That's not logical!
  - carbocation 13y ago
    All of these statements might be true, but they neither imply nor advance one another. They are all non sequiturs. Also, there is less to the left/right brain thing than most people seem to think.
    - TheZenPsycho 13y ago
      I can only guess that you just didn't read it, or don't understand it, because you're 100% wrong. Not just wrong, but ironically wrong- you're explicitly proving my point that the only thing you value is logic and reason. Which is ridiculous because our brains do a lot more than just logic and reason. As for the left/right thing, I know that- strictly speaking, there isn't really that much of a left-right separation of concerns in the brain. It doesn't matter for my point though. It's just a metaphor for the easily demonstrable fact that brains have functions other than logic that are just as useful and important to satisfy.
ww520 13y ago
> I wonder how you’d feel if you as a developer were told that every line of code you wanted to change — even those with obvious bugs — could not be touched unless you had previously demonstrated why you expect a measurable benefit to the satisfaction of the business development staff, and that your commit access was going to be revoked and every change would have to be made by bizdev after someone who didn’t know anything about programming decided whether it was justified. The difference being that the developer makings his own changes as he sees the problem, not asking someone else to make the changes, whereas the designer just asks someone else to make an arbitrary change. If the developer is asking someone else to make a few lines of changes, he better gives a good justification.
- TheZenPsycho 13y ago
  So a developer is permitted to make arbitrary changes to the design at his whim with no justification, because he/she is doing the actual work. Because design is not actual work? But the designer, with years of experience, research, university studies and so on, cannot request to reverse that arbitrary change? I mean, it's division of roles. does the developer want to be a designer too? Does the developer want to justify their choice of algorithms to the designer? Doesn't this seem one sided to expect the designer to justify every choice, but the developer answers to no-one?
  - ww520 13y ago
    The point is when you ask someone else to do the work for you, you need to give more justification than you are doing it yourself because in software development pretty much everyone has their plate full or overflowed, and your adding of more work on them would need to be prioritized against pushing something else off. Of course you need to justify your change that is important enough to push off some of other work. If you are doing the change in HTML/CSS/Javascript or whatever yourself, go right ahead. Just make sure you don't break something else. Likewise if there's change the developer is asking the designer to make, the developer better makes a good case for it. What if I tell you to remove the color red and blue in your design. Just do it. Don't ask why. You would be annoyed, too. And when you question, I told you, oh well, based on my years of training and experience, color red and blue run slowly in this algorithm. I think what annoys most people here is that the designer thinks his changes are the most important ones and have to be made. There are millions other things the engineers need to worry about to make the product work. If the database is corrupting, moving 3 pixels to the left is not important. What the engineers asking is the justification for the change so that it can be weighed against other priorities. Isn't that so hard to do?
gutnor 13y ago
Engineer/Dev will come to me on a regular basis to "use framework X", that code is module Y is shit because and there is a more optimal version of the algorithm. Most of the time, there is not objective reason other than "I have used that before and I liked it", "micro-benchmark say so, but I have not looked in this case if there is any interest for us". Client want our application to produce an incorrect file, having forgotten that some bloke in their department is correcting by hand all the incorrect file of the old application. Manager want you to do a daily timesheet to properly track client billing despite the fact that your team is working full time for a single client. Client/Manager/Other Developer regularly ask for rubbish reason all the time, why would the Designer be any different ? They may have a good reason this time, just spend 2 min to explain them.
hrktb 13y ago
Just for the record, in environments where devs have to get their changes validated in a way or another (i.e. get it past the test team, release to prod etc.), they will get a resounding NO, if they try to change some code just for the sake of it (even if it's called "refactoring") or things they can't argue to be valuable (depending on where you are, fixing a minor bug might not be a good enough reason for changes). There's no double standards, basically anyone has to justify spending other people's time.

ricardobeat 13y ago

That last paragraph is a fairly accurate description of work at decadent BigCos.

sxp 13y ago

Why would you think a designer would have no justification for a change beyond “it looks nice”? What would you assume designers don’t understand issues like pixel alignment or designing for multiple devices? Why would you think designers would be raising these issues based on Photoshop mock-ups? Experience. I've had arbitrary requests made based on Photoshop mocks. I've pushed back against them after showing that the proposed design looks blurry on devices with a low dpi. Or showing that the UI breaks down in edges cases where the text field contains more text than what is shown in the mocks which results in unwanted wrapping. These are issues that can only be understood by someone who knows the implementation details and constraints of the underlying OS that does the final work of rendering the UI rather than relying on the constraints of Photoshop. Do you understand that there is actual research underpinning a lot of design theory, demonstrating both how humans respond to different design choices and the fact that those choices can directly and sometimes dramatically affect metrics you care about like conversion and retention rates? Yes. And good UX designers know this research which is why they can quickly justify their choices.

Chris_Newton 13y ago
It sounds like your real problem has nothing to do with a “design version” or an “engineering version” of anything. You’ve just worked with some people who were in a design role but didn’t know how to do it. That’s unfortunate, but I don’t think it invalidates the original premise of the article that paying attention to seemingly minor design details matters more than a lot of non-designers tend to acknowledge.
- jessedhillon 13y ago
  I have yet to see a proposed application design or cosmetic change whose justification does not ultimately rely on "this guy's taste is better than that guy's" -- yes designers do sometimes bring out some justifications which are expressed with objective sensibilities but to me they always seem to be rationalizations, in the same way that evolutionary psych seems to be. That is, first see a behavior or a look that seems appealing, then figure out which design principles are making it seem better. I think the best designers temper their taste and predilections with judicious application of statistical methods such as split-testing. I don't find anything objectionable about this, as long as the designer actually owns the design and has the fortitude and clout within the organization to defend their changes. Design seems to me an art in many respects, so some decisions will come down to a matter of taste in the end. Like any successful artist, the designer then will need the persistence to defend their vision against the meddling of bike-shedders. I also think @sxp's characterization of the objectivity of engineering decisions leaves too much out. Engineering debates rarely come down to foosort() v. barsort(), where one obviously performs better. More often, they come down to questions like "should we be passing this argument first or last?", "what should these methods be named?", "can this code be extracted into its own module?" -- in other words, how to design the code.
  - nikatwork 13y ago
    You're not working with properly trained designers then. Layouts have certain empirical properties which can be judged objectively: * Conforms to a grid * Internally consistent padding and margins * Information sized and arranged hierarchically according to importance * Proportions conform to the rule of thirds or golden ratio * Internally consistent UX patterns (eg cancel buttons might be always red, confirm buttons might be always green) * Text column widths are not too wide * Color choice is harmonious (conforms to color wheel rules) These are the main ones but there are many others. Unfortunately, these kind of classic design principles don't seem to be taught very often these days, instead design courses focus on the mechanics ie how to use Photoshop.

10feet 13y ago

> Why would you think a designer would have no justification for a change beyond “it looks nice”? What would you assume designers don’t understand issues like pixel alignment or designing for multiple devices? Why would you think designers would be raising these issues based on Photoshop mock-ups? You are right, they often have good reason, and can make the case by explaining that. Of course, they often to not have a good reason beyond spacing, it looks better, it is too crowded, or it is not crowded enough.

TheZenPsycho 13y ago
Isn't it unreasonable to expect that every design decision be based on logic? Human beings have two brain hemispheres. TWO WHOLE BRAIN HEMISPHERES. a right lobe and a left lobe. The right lobe is JUST AS BIG and complicated as the left lobe, in which our logic and reasoning abilities are based. But in our culture, especially in development culture, for some reason any decision based on a process in the right hemisphere is valued far less. We call it "subjective" even though it isn't. It's the same processes that every human brain does in much the same way. This is why optical illusions can work. They work much the same way for every person, and the reasons they work are not based on logic. They're based on physical, biological processes in our visual processing systems. It's not a "logical" or "rational" process. It's a visual process. But if a designer says that spacing is going to cause a problem, it's not valuable input because there is no "logical" reason behind it. That's not logical!
- carbocation 13y ago
  All of these statements might be true, but they neither imply nor advance one another. They are all non sequiturs. Also, there is less to the left/right brain thing than most people seem to think.
  - TheZenPsycho 13y ago
    I can only guess that you just didn't read it, or don't understand it, because you're 100% wrong. Not just wrong, but ironically wrong- you're explicitly proving my point that the only thing you value is logic and reason. Which is ridiculous because our brains do a lot more than just logic and reason. As for the left/right thing, I know that- strictly speaking, there isn't really that much of a left-right separation of concerns in the brain. It doesn't matter for my point though. It's just a metaphor for the easily demonstrable fact that brains have functions other than logic that are just as useful and important to satisfy.

ww520 13y ago

> I wonder how you’d feel if you as a developer were told that every line of code you wanted to change — even those with obvious bugs — could not be touched unless you had previously demonstrated why you expect a measurable benefit to the satisfaction of the business development staff, and that your commit access was going to be revoked and every change would have to be made by bizdev after someone who didn’t know anything about programming decided whether it was justified. The difference being that the developer makings his own changes as he sees the problem, not asking someone else to make the changes, whereas the designer just asks someone else to make an arbitrary change. If the developer is asking someone else to make a few lines of changes, he better gives a good justification.

TheZenPsycho 13y ago
So a developer is permitted to make arbitrary changes to the design at his whim with no justification, because he/she is doing the actual work. Because design is not actual work? But the designer, with years of experience, research, university studies and so on, cannot request to reverse that arbitrary change? I mean, it's division of roles. does the developer want to be a designer too? Does the developer want to justify their choice of algorithms to the designer? Doesn't this seem one sided to expect the designer to justify every choice, but the developer answers to no-one?
- ww520 13y ago
  The point is when you ask someone else to do the work for you, you need to give more justification than you are doing it yourself because in software development pretty much everyone has their plate full or overflowed, and your adding of more work on them would need to be prioritized against pushing something else off. Of course you need to justify your change that is important enough to push off some of other work. If you are doing the change in HTML/CSS/Javascript or whatever yourself, go right ahead. Just make sure you don't break something else. Likewise if there's change the developer is asking the designer to make, the developer better makes a good case for it. What if I tell you to remove the color red and blue in your design. Just do it. Don't ask why. You would be annoyed, too. And when you question, I told you, oh well, based on my years of training and experience, color red and blue run slowly in this algorithm. I think what annoys most people here is that the designer thinks his changes are the most important ones and have to be made. There are millions other things the engineers need to worry about to make the product work. If the database is corrupting, moving 3 pixels to the left is not important. What the engineers asking is the justification for the change so that it can be weighed against other priorities. Isn't that so hard to do?

gutnor 13y ago

Engineer/Dev will come to me on a regular basis to "use framework X", that code is module Y is shit because and there is a more optimal version of the algorithm. Most of the time, there is not objective reason other than "I have used that before and I liked it", "micro-benchmark say so, but I have not looked in this case if there is any interest for us". Client want our application to produce an incorrect file, having forgotten that some bloke in their department is correcting by hand all the incorrect file of the old application. Manager want you to do a daily timesheet to properly track client billing despite the fact that your team is working full time for a single client. Client/Manager/Other Developer regularly ask for rubbish reason all the time, why would the Designer be any different ? They may have a good reason this time, just spend 2 min to explain them.

hrktb 13y ago

Just for the record, in environments where devs have to get their changes validated in a way or another (i.e. get it past the test team, release to prod etc.), they will get a resounding NO, if they try to change some code just for the sake of it (even if it's called "refactoring") or things they can't argue to be valuable (depending on where you are, fixing a minor bug might not be a good enough reason for changes). There's no double standards, basically anyone has to justify spending other people's time.