I started writing a response about my experience as a designer at Mozilla and it got really long and I turned it into a blog post called "Code talks and designers don't speak the language." Thanks for inspiring me to come out of blog hibernation. http://skinnywhitegirl.com/blog/code-talks-and-designers-don...
"Probably the most daunting question for projects without any design lead that has the trust of the team is, how do the devs know if the proposed design is correct? Without that trust, bugs quickly devolve into nasty arguments. How you build that trust has been the subject of entire books. But the question remains, who and how do you approve a mockup? The code review process works great for just that… code."
Developers also have nasty arguments about what code is correct/the better one etc. ;-)
So this argument also should in principle apply to developers - but developers don't seem to have any problem about that point. I don't know whether the reason is simply that developers have less a problem with conflicts?
But nevertheless: there are well-established principles to judge which code/software architecture is better (elegance, smallness, extendability etc. (all of these can be judged rather objectively) - which role these play, depends on the project). I think it would help project leaders if you suggested a similar process for judging design decisions. Just an idea. If this is a bad idea of me, suggest a better one.
"there are well-established principles to judge which code/software architecture is better" There are very similar principles for judging which design is better (affordance, natural mapping), it's just that coders don't know those principles.
You're implying a value judgement that code is an objective discipline and design in a subjective discipline. There are aspects of visual design that are subjective. However, UX is a testable, repeatable, objective discipline that is informed by the work of cognitive science.
Yes coders have arguments... with coders. They have inside baseball arguments. It's entirely different than a designer having an argument with a coder. Often, the designer has to teach the coder the principles of design in order to even engage in a logical, productive discussion.
The overriding point I was making is that the tools like github are designed for code, not design. Our tooling inherently advantages code. It's a pain in the ass to even insert an inline image into a comment. Github isn't built for evaluating mockups and wireframes. Designers do our best to bootstrap into the tool, yes. But it's not our tool.
Fantastic blog post! You have a much more optimistic approach that I could learn from. Too often I find myself saying "Because I said so, dammit! You code, I design!," but the idea of building trust and credibility is a good one.
One of the challenges of design education for developers is that developers are naturally geared toward rule sets, which becomes a problem when the designer decides to break the rules for a justifiable reason. Just like devs couldn't teach a designer to code in a day, a designer can't really provide all of the ins-and-outs of good design to devs. Perhaps education needs to be introduced to devs as to the value of UI/UX, rather than the specifics.
