Hacker News Reader

> Designers are frustrated because the systems they built are ignored.

Designer here. My experience has been that Figma has done the opposite. It's created a lot of consistency with shared component libraries and standardized type / color styles. Also, the fact that engineers can jump into Figma and inspect CSS has been immensely helpful.

In the design world, Figma is like the equivalent of getting a robust IDE with syntax highlighting, code completion, compilation, and debugging. It's replaced multiple tools and connected people in a way that's never been possible.

From the developer perspective I never felt the inspect CSS gets me much over the design documents that I got in the past, that included the systems definitions and rules to follow. To be honest, I prefer the latter and find a lot of the "modern", interactive tools fiddly and ineffective to use (e.g the generated css giving me a html code instead of a variable name even if its a defined design color).

That said, I never felt implementing a design once is the hard part, but keeping them maintained and in sync. What are things that worked for you in that regard? E.g. as an engineer, how do I quicky figure out what I need to adapt when a design has changed? I quickly looked at Figma, and while there is a version history, it just seems to switch completly between versions without anymore detail. So I'm bound to miss changes and completly am reliant on the designer annotating manually.

I love getting figma files as mocks for things i need to implement. I love grabbing CSS from the figma, and I love that the design system allows the designer to not only export CSS, but export it in a way that has annotations (all the colors I get from my designers are annotated with "brand red 300 weight" as a comment, so I can use the right mixin.

Furthermore, I can also, when I'm building out the first-form HTML implementation of the mock, right-click and copy-as-svg the whole component, which makes for a nice stand in while I work on the rest of the code. It is great.

In your experience, do you know if engineers implement the shared component libraries as such in the actual applications? This would be as opposed to engineers directly implementing the end result of work in Figma (Sketch, etc.) that utilizes said components. There is a big difference there, and I'm always curious to have more data points about how this actually happens at other organizations.

Anecdote: at my current org the ideal we talk about is having a component library designed in Figma by the Designers and implemented by the engineers.

In reality Design doesn't use components and most pages end up being composed of a bunch of one-off components and we waste a ton of time.

As a side effect of this, the app design isn't consistent across pages because we aren't sharing components.

Ditto, we have a quite a few designers and they mostly seem to struggle with thinking in components. They use design system like a color guide, and we keep reimplementing patterns on many pages.

Yeah that is the exact result I have observed before as well. I'm really curious to hear more examples about how this actually works out well in the end from others.

I recognize that my view of this is from the bottom up in terms of only really having worked for SV startups, but I want to learn more and see if I can't make it work a bit differently this time.

Some do, sometimes relying on things like Storybook.js to do QA in the middle. There's more and more things to maintain consistency between Figma design and e.g. React components being built.

My uncle had a successful career in advertising. He would always say to me, "don't be just a wrist." He meant participate in guiding the concept and strategy instead of just being an execution person.

I've been in the design industry for 15 years now. When I was starting out, there was a flurry of philosophizing about design. There was a belief that designers should focus on solving problems instead of just making slick UIs. I don't see that discussion anymore. I see a bunch of "wrists" arguing over which pencil is best.

Maybe I'm just an aging curmudgeon...

I was going to say my experience is kind of the opposite — everyone seems to be waxing poetical about "design thinking" but UI work is more and more cut and paste. That being said, the "wrists" may just have moved one abstraction level higher, and they're parroting design thinking tropes (design sprints, etc.) instead of lower level ones.

Good execution compliment good strategy. I think you can also be the valuable wrist that hard to replace.

I've seen people who knows about the theory and have creative idea, but the end result they made is just...lacking?, because they focus just about the strategy part and kinda look down on the importance of good execution. They may know that it is not good, not what they envisioned, but they don't know how to make it better because they don't know how the production process works, and usually have to accept what the vendor gives you.

But well yeah, there are certainly people that just want to be a wrist and not thinking too much about anything.

Anecdotes like this are rarely widely seen, maybe its your companies hiring or your location?

I've had some success in agile-style places pushing for separate story pointing of special-snowflake bullshit design. Like:

"This feature's a 3 if we just do it with native elements or and/or existing UI guidelines, but it's another 5 story on top of that if you really need this ugly crap you're insisting on that'll bloat our bundle by a ton, likely be fragile in a variety of ways, and, realistically, probably have some a11y and cross-platform issues even with a "5" of effort put in."

Suddenly they don't really need it that much, and if they do, well, they have only themselves to blame when "not much" gets done this sprint. Congrats, you just saved them money and (probably) improved the UX and maintainability of the project. Every now and then they'll really insist, which is fine, but if you've got someone who's picking their (let's face it, usually terrible) glittery UI ideas over features & bugfixes more than very occasionally then the project's probably doomed, so at least that becomes clear really fast and you've got numbers to point to if shit gets toxic and the blame-game starts (you did document it, right?)

I thought the Waterfall process was primarily an Agency/Marketing thing, with Tech Startups focusing more on a level playing field where most have input and touch the final product.

This is where I believe these products are focused on, essentially agencies try to get sign-off from clients before they begin work, and the better they can show what the final product (and processes) will be like, the better.

Edit: Yes the Waterfall sucks, especially if you're at the bottom.

> This is where I believe these products are focused on, essentially agencies try to get sign-off from clients before they begin work

Agreed that it makes sense for contractual work like this, where you just get sign-off, do the work, maybe iterate a little at the end, and then move on to something completely different. In fact, I would say it's the right tool for the job here, despite how much of a charged term "waterfall" has become.

It can easily fall apart when a single company does this enough though, because it usually comes with the lie that it delivers reusable work. You're not, and it manifests itself through your slow, confusingly inconsistent product. Maybe your customers don't care, but nobody will be proud of their work, and you'll start to gain the reputation of "it's buggy and confusing but it works"

The best case I ever found was insisting that designers and developers sit together without much PM interference. The unplanned communication and collaboration ended up producing gold.

That's awesome to hear! Was that something that you had to fight for, and if so, what did that process look like?

My observation with SV startup organizations is that it is very difficult to get that buy-in from product on something like this. These product teams are groups of people trained to believe that "if we deliver X we get $Y", which prioritizes building as many of X in as little time as possible. And I completely agree on that merit, a company SHOULD strive deliver as many revenue generating changes as possible, that's how you avoid death.

If, as an engineer, you challenge that with a push to make better reusable systems and actually stick to them, you will always be met by opposition. "What's the ROI?" they will ask. It's hard to give one because it's not really quantitative, but everyone in the room (generally, product included) KNOWS it's the right move. What do you do?

Are you me? This hits just too close to home.

Work with enough teams and you start to realize the same types of problems come up everywhere :)

this time will be different

This is an interesting opinion. Can you share how would you design a proper structure so the above is not the case?

I have my own "perfect world" solution that I can shed some light on, sure. It's built to address the concerns that I myself have observed, so it might not apply to all. Never just blindly follow the advice of a stranger on the internet :)

Stop wasting time with high fidelity mocks. Engineers shouldn't need a picture perfect rendering of what product wants in order to implement it. The end result almost never ends up being an exact replication anyway for "reasons".

Start doing both of these in parallel: 1. Free up design to build systems that can be used to solve problems. Have them work closely with engineering to ensure the vision will carry ALL the way through to implementation 2. Lean very heavily on low fidelity mocks to hash out the SHAPE of changes to product (inspired by Basecamp https://basecamp.com/shapeup/1.1-chapter-02)

To use object oriented programming as an example, a design system is used in the concrete implementation of the abstract shape of the product requirement. When something doesn't fit into an existing abstraction, you refactor instead of fork.

Amen. I have similar experiences working with designers and PMs and this is my ideal as well.

Designers don’t know the software architectural constraints and what is easy to code up and what is not. Engineers do. PMs know what trade offs they want to make in fidelity for the product, but designers and engineers don’t. What you often end up with is designers spending a lot of time creating designs they think solve the problem, but miss out on a lot of edge cases. They and PM discuss the product design and hand it over to engineers as if their work is done. When the engineer goes to implement it, they find all those edge cases that were missed and the designer has to go and redo a bunch of stuff while engineering is blocked on some of those decisions and PM is concerned why it’s so hard to implement as is.