Should I be building everything that the designers give me on Figma?
16 comments
A few important lessons here.
You dont tell someone NO. You say, I could do this, or I could make this change and it would work in a standard way. If you want me to do it this other way, I can but it is going to cost XXX extra hours to build it, and probably incur a lot of future work to maintain our own "version" of this.
Then when they say "do it that way" you go into your planing meetings and say "task xxx is 2x longer for a design deviation"
Make sure if you say this, it goes in an email. You know why all the old people send you emails for bullshit? Because we have all been burned and know that we can keep copies of that for CYA reasons.
I didn't see an email (a lot of them) is a bad excuse 6 months down the road. When the bills come due and the design team is getting a beat down.
You dont tell someone NO. You say, I could do this, or I could make this change and it would work in a standard way. If you want me to do it this other way, I can but it is going to cost XXX extra hours to build it, and probably incur a lot of future work to maintain our own "version" of this.
Then when they say "do it that way" you go into your planing meetings and say "task xxx is 2x longer for a design deviation"
Make sure if you say this, it goes in an email. You know why all the old people send you emails for bullshit? Because we have all been burned and know that we can keep copies of that for CYA reasons.
I didn't see an email (a lot of them) is a bad excuse 6 months down the road. When the bills come due and the design team is getting a beat down.
Consulting 101 training kicks in here - YES is always the answer to any request, followed by "heres how long it will take, how much it will cost and what other priorities will need to be shifted. We can get started this afternoon if you're good with that?"
Stakeholders asking for crazy things back up real fast when you take their requests/demands/GOOD IDEAS and apply these realities to them.
Stakeholders asking for crazy things back up real fast when you take their requests/demands/GOOD IDEAS and apply these realities to them.
Most of conversation are on open channel.
For them it's like, you think it's difficult, park it for later and do it later.
But they don't update the designs.
For them it's like, you think it's difficult, park it for later and do it later.
But they don't update the designs.
> Most of conversation are on open channel.
This is the hallway of modern Remote work.
You either do it right and pay the price or the design gets updated... Email shit, make a point to keep asking the question till they reflect whats going to get built.
Deisgn is an implementation detail, not a cost driver. You aren't working for apple.
This is the hallway of modern Remote work.
You either do it right and pay the price or the design gets updated... Email shit, make a point to keep asking the question till they reflect whats going to get built.
Deisgn is an implementation detail, not a cost driver. You aren't working for apple.
Designer who can do some web dev here.
When I work with real developers I engage with them to show them designs for feasibility, timelines, accessibility. But when I have worked with designers who don’t have these skills, and I have to break the news to them about their dribbbly designs, I have largely had success by starting from web standards and accessibility. So, in your example with the input, I’d tell them that a standard <input> comes with out-of-the-box accessibility for people who must use some sort of assistive tech but that custom stuff, even with all of the extra dev work done to satisfy the browser’s accessibility tree, is still unproven, which means we could actually hurt some users. That’s usually where I would add putting the user first means sticking as much as possible to standard HTML elements. But if it were a business, I’d make the argument from a liability stand point and use the DOJ’s recent guidance about websites are covered under the ADA.
Now for the unreasonable designers, I would just say no and email them, the project owner, with references links to DOJ and WCAG. That’s covering your ass and being an advocate for the assistive technology users at the same time. I once got designs from a print designer who didn’t know anything about web standards, etc., and when I brought up this stuff, they angrily retorted “I can do this in SquareSpace so why do we need you?” So, that’s when I first used the tactic I am telling you, which aligns closely with others’ responses here about sending emails. I would add a BCC to your own personal email too.
When I work with real developers I engage with them to show them designs for feasibility, timelines, accessibility. But when I have worked with designers who don’t have these skills, and I have to break the news to them about their dribbbly designs, I have largely had success by starting from web standards and accessibility. So, in your example with the input, I’d tell them that a standard <input> comes with out-of-the-box accessibility for people who must use some sort of assistive tech but that custom stuff, even with all of the extra dev work done to satisfy the browser’s accessibility tree, is still unproven, which means we could actually hurt some users. That’s usually where I would add putting the user first means sticking as much as possible to standard HTML elements. But if it were a business, I’d make the argument from a liability stand point and use the DOJ’s recent guidance about websites are covered under the ADA.
Now for the unreasonable designers, I would just say no and email them, the project owner, with references links to DOJ and WCAG. That’s covering your ass and being an advocate for the assistive technology users at the same time. I once got designs from a print designer who didn’t know anything about web standards, etc., and when I brought up this stuff, they angrily retorted “I can do this in SquareSpace so why do we need you?” So, that’s when I first used the tactic I am telling you, which aligns closely with others’ responses here about sending emails. I would add a BCC to your own personal email too.
In my experience, the more hacky the coding is, the worse the user experience would be. The better thing would be to help the designer understand the feasibility.
You're right to criticize, but talk to the team/lead to get clarification/direction.
If you have valid concerns, then it's a teaching lesson for the designer.
Good luck!
If you have valid concerns, then it's a teaching lesson for the designer.
Good luck!
Yes I have already aproched my lead. But what do you feel scroll bar out the overflowing div.
Does this classify as a valid concern?
I push back on stuff like that.
I too did but rather than changing the design I get that 'np do it later'
Something that is not possible today how do I make it possible tomorrow?
Something that is not possible today how do I make it possible tomorrow?
yeah, at the end of the day if you can push it off, then its better than having to implement a shitty solution.
Maybe talk to the designer?
They don't listen. They say do it later if not now.
They say there are benefits of changing the default way.
alpha_king(1)
The designs they create look interesting, but whenever I take a closer look, I see elements that are not industry-standard practices or are not feasible. If they are feasible, the implementation is often hacky.
For example, using ellipses at the start of a input box when the user has typed the entire length and is still typing, or havind a scrollbar outside an overflowing div.
These designs drive me crazy. I get frustrated seeing these designs. Am I right to criticize, or should I implement them in a hacky way?