
The designer who doesn't code - zdw
http://metamn.io/beat/the-designer-who-doesnt-code/
======
config_yml
This seems a bit hostile? Why not go back and share your knowledge, present
the arguments and change it together rather than spending the time
begrudgingly implementing what should have been a 10 minute chat with your
designer who doesn't code.

~~~
Zanni
Yeah. This seems less like an argument about why designers should code and
more like a case study of incomplete requirements/inflexible process.

------
daleco
Why don't you have design review and design sessions with the designer? This
is the type of thing that we talk about on a daily basis (I used to code and
now design). If the Dev or PM has a compelling argument, we negotiate,
compromise or stop at each other desk.

I bet that the Ads is not his call but marketing :)

------
mharroun
How about saying to the designer... "Hey if we remove this or make an
adjustment like X I can get this done 5x faster.

If you cant agree bring it up to the person in charge of the project. Either
time is saved or it is explicitly stated that the extra time is worth the
result.

------
jarym
I sit and discuss ideas on what’s easy, what’s hard, etc. It’s an ongoing
process but I rarely end up with something that involves too many hacks

------
RickS
A poorly thought out and damaging post for a number of reasons.

1) It starts out creating a straw designer with a set of below-market skills
that is easy to chop down. If the assets as presented represent the entirety
of what was delivered, I'd say they're weak for a just-okay marketing team and
comically below bar for any product shop at any place with one of taste or
money. This deliverable wouldn't get you a phone screen. It's not that your
designer can't code... it's that they can't design.

2) The comps section makes some claims that don't hold up. A less technical
designer can deliver mocks in the listed formats (PS, sketch, zeplin) that, in
a competent design/dev environment, require NONE of "slicing, calculating, or
converting to pixels like in the 90s." I had the marketing team at my last gig
using sketch files that were templated out of the box with our grid system at
every breakpoint, with plugins for our spacing units and typography that
matched existing CSS implementations, so all you had to do was declare spaces,
css color var names, etc. There's clarification to be done, and custom work in
many cases, but for generic grid stuff like this? If you're repeatedly doing
the same pixel snipping labor, your dev/design teams are dropping the ball on
both comms and tooling. It's possible to have shared language/understanding
here without designers needing to code.

> If no design thinking there is no design system and code, project, budget,
> people gets bloated.

This is tough to parse. I think it can be rewritten as "If there is no design
thinking, there is no design system, without which the size of
code/project/budget/headcount balloon." I think it's silly to pin that solely
on non-technical designers and a lack of "design thinking". As engineers used
to thinking about DRY/reuse/abstraction, part of our role is educating
upstream teams about the principles from our domain that would make
collaboration more effective. I find that designers are usually excited to
have conversations about anything that makes their work easier, automated, or
predictable.

3) "The task" starts with an assumption that I think is a pretty amateur one.
It assumes that the object count in the mocks is the object count for the
page, and not merely the number that fit in the viewport. He goes on to gripe
about inefficient calls that fetch content that is then not displayed, when I
strongly suspect that the designer here meant for the page to scroll and
failed to communicate that explicitly enough. This is the designer's failing,
but it's not reasonable treat one's assumption about ambiguous post count as
an explicit requirement. It would take less time to clarify this than to write
the post griping about it. There is a codepen. It is not mentioned whether the
codepen was run by the designer for clarification. We do this routinely on my
team. It irons out miscommunications very effectively.

4) It's not the role of the designer to imagine within the bounds of what's
possible with CSS grid. CSS is a ridiculous and archaic language. If there are
implementation difficulties, have an adult conversation about it. What are the
underlying goals? Can you achieve visual separation another way? Is an element
critical enough that templating should be refactored? There is no default
right way to prioritize developer experience compared to user experience. If
shitty grid code makes an extra $500k in sales, so be it. To be clear, I don't
think these lines are that powerful or important, but "if you can't code it
easily you aren't allowed to do it" is a limiting mentality IMO.

5) "The designer doesn't knows exceptions are painful and bloat the source
code" ... I really stand behind this one, in general. While designers should
not necessarily be able to write code, they should absolutely be robust
systems thinkers that can design repeatable solutions. But "the ad requires a
variation in the CSS grid" is just so freaking trivial. Given only the scope
shown... come on. "Moving out of the grid will spare around half of
development time and budget." yeah, half of... an hour or two, the poster
estimates?

This person didn't even get into the problem I expected them to: on fluid
layouts, it's common for content to resize when ads can't, which can result in
layout problems trickier than anything mentioned in this post, but that's a
result of ad sizes being somewhat standardized and having third party
constraints on their display. In complaining about the size disparity, the
poster is revealing their own ignorance about the forces that govern the
content they're working on. Of course the ads are different sizes. Have you
_seen_ a website before? What's the desired alternative here? Set the layout
units based on your ad dimensions? They mention moving the ad... great. Did
your designer need to code to move the ad in response to layout constraints?
No.

\----

This person drafted an inarticulate tirade with scare-mongering statistics
about trivial numbers ("double the time", "500% more") instead of having a
clarifying conversation with their coworkers or attempting to build systems
that permanently eliminate this class of hangup. They used a colleague's weak
work to demean an entire profession instead of reflecting on their own role in
a larger system.

Further, they approach the whole thing through a lens where work quality is
evaluated based on developer happiness without ever addressing business
outcomes beyond their own domain.

I somewhat regret spending my time to enumerate the ways that this sucks, but
if it gets someone who agrees with the post to reconsider, that would be a
good thing for everybody.

