Well... I don't want to force someone to do that, but I'd really really really prefer if design people actually did code sometimes, so they understood the reality of what they're 'designing' from an implementation standpoint.
It may take you 6-8 hours to mockup something that is ... logically impossible, which someone 'signs off' on, then 40 hours for someone else to try to cobble together - pushing back is 'combative' and 'negative', etc.
You know how designers don't like people who ask for stuff that "pops" and then want more "pop"? Designers 'designing' stuff that creates practical impossibilities or gaps in state, etc. - programming folks hate that just as much as you hate 'make it pop' requests.
Hey - cool - you "designed" a form with 3 elements! The actual implementation options are 17 for that area. What should happen with 0 selected? Do we want notifications or help text?
Nice - that design looks really slick with 3 checkboxes in a pulldown, but you've sort of just invented a widget that doesn't really exist, will create accessibility nightmares, and you didn't show how this should behave on mobile/tablets.
The number of design people I've met who can actually reconcile clean design with real implementation, usability and accessibility issues addressed is very small.
I can sure relate to this. Or my favorite question: "What happens when I click that magnifying glass in the top nav?" and they say, "Oh, I didn't think about that!"
I doubt the real answer is for the designer to code (though it's nice when you get to work with someone like that), but you sure have to ask a lot of questions, and you never manage to check everything up front. Especially anything that doesn't immediately open a new web page, at every step there are just so many input possibilities: the user clicks this button or that, clicks elsewhere, types a bit here then a bit there, presses Enter, presses Tab, presses Escape, has a screenreader, is on a phone, is on an iPad, gets an error, gets 1000 results, changes the dropdown that enabled this other control. . . . I guess you do the best you can imagining flows up front, but plan on having some iteration as you discover gaps in the design.
> I doubt the real answer is for the designer to code
I'm not saying they have to code 100% of everything, but I'm really fed up with having to deal with that sort of "well gosh that's not our issue!" hands off sort of 'design' folks.
Internal design teams that work in the same building as the implementors/devs... maybe a different experience. I'm sometimes brought in and given "mockups" from an external team, done in whatever tool of the day they use, that have little bearing on real world web implementation.
it's apparently beneath some of these folks to learn css/html and use ... you know... a web browser to mock up a web site. i don't care how much 'freedom' some tool gives you, you're just punting the hard implementation to someone else.
Came off a project recently like this - the original team had done 'weeks' of 'design' and 'planning' with an external design firm. "but plan on having some iteration as you discover gaps in the design" sounds nice, but in their mind, they'd already "thought a lot about it" 8 weeks earlier, so any implementation issues I found were somehow... my fault? my problem? "these guys are a really strong design firm..." who don't seem to have ever actually implemented anything they design, from what I could tell.
Well... I don't want to force someone to do that, but I'd really really really prefer if design people actually did code sometimes, so they understood the reality of what they're 'designing' from an implementation standpoint.
It may take you 6-8 hours to mockup something that is ... logically impossible, which someone 'signs off' on, then 40 hours for someone else to try to cobble together - pushing back is 'combative' and 'negative', etc.
You know how designers don't like people who ask for stuff that "pops" and then want more "pop"? Designers 'designing' stuff that creates practical impossibilities or gaps in state, etc. - programming folks hate that just as much as you hate 'make it pop' requests.
Hey - cool - you "designed" a form with 3 elements! The actual implementation options are 17 for that area. What should happen with 0 selected? Do we want notifications or help text?
Nice - that design looks really slick with 3 checkboxes in a pulldown, but you've sort of just invented a widget that doesn't really exist, will create accessibility nightmares, and you didn't show how this should behave on mobile/tablets.
The number of design people I've met who can actually reconcile clean design with real implementation, usability and accessibility issues addressed is very small.