4 ms·

Not a comment about Figma really, but it has unfortunately become a trigger word for me. These are my observations from working with tech startup companies as a

Not a comment about Figma really, but it has unfortunately become a trigger word for me. These are my observations from working with tech startup companies as a software engineer. Software solutions will never fix problems that are caused by people. Sketch, Figma, whatever the next design tool is. Google Docs, Quip, Notion. Trello, Pivotal Tracker, GitHub/ZenHub, Jira. I've gone through tool-switching fatigue with all of the above. Sometimes it doesn't matter much, other times it bogs us down with metawork for months as you figure out which features you gained, and more importantly, lost. Back to design. I have seen design die the same way every time. Product misuses design resources, effectively making them contractors that hammer out one-off pieces of work. Those pieces of work get nitpicked by some vocal minority holding a lot of clout, until the end result violates the framework that the designer created. This frustrates everyone over time. Designers are frustrated because the systems they built are ignored. Engineers are frustrated because they are adding new debt with every designed feature that has to rebuild parts of the world to make exceptions to systems work. Product is frustrated because they just don't get why things are slow after they delivered a clear design to the engineers. Let it all build up and people will start leaving your company. So yes, use Figma if it suites your company well. If you're reaching for it because your team is frustrated, maybe consider digging into that more before you swap out yet another piece of software for all the wrong reasons.

doh 6y ago
This is an interesting opinion. Can you share how would you design a proper structure so the above is not the case?
- corytheboyd 6y ago
  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 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.
  - allenu 6y ago
    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.
mrpigeonpants 6y ago
> 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.
- corytheboyd 6y ago
  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.
  - emptysea 6y ago
    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.
    - corytheboyd 6y ago
      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.
    - gedy 6y ago
greyswan 6y ago
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...
- davidivadavid 6y ago
  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.
- softwarejosh 6y ago
  Anecdotes like this are rarely widely seen, maybe its your companies hiring or your location?
- raindropm 6y ago
  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.
harryf 6y ago
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.
- corytheboyd 6y ago
  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?
OzzyB 6y ago
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.
- corytheboyd 6y ago
  > 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"
- deleted 6y ago
  [deleted]
dsego 6y ago
Are you me? This hits just too close to home.
- corytheboyd 6y ago
  Work with enough teams and you start to realize the same types of problems come up everywhere :)
  - edoceo 6y ago
    this time will be different
eyerony 6y ago
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?)

doh 6y ago

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

corytheboyd 6y ago
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 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.
- allenu 6y ago
  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.

mrpigeonpants 6y ago

> 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.

corytheboyd 6y ago
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.
- emptysea 6y ago
  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.
  - corytheboyd 6y ago
    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.
  - gedy 6y ago

greyswan 6y ago

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...

davidivadavid 6y ago
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.
softwarejosh 6y ago
Anecdotes like this are rarely widely seen, maybe its your companies hiring or your location?
raindropm 6y ago
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.

harryf 6y ago

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.

corytheboyd 6y ago
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?

OzzyB 6y ago

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.

corytheboyd 6y ago
> 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"
deleted 6y ago
[deleted]

dsego 6y ago

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

corytheboyd 6y ago
Work with enough teams and you start to realize the same types of problems come up everywhere :)
- edoceo 6y ago
  this time will be different

eyerony 6y ago

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?)