4 ms·

I just see this as a tool to help make UI designers (and maybe POs) look smart and competent, but the real work is going to go to the programmers, just as it do

I just see this as a tool to help make UI designers (and maybe POs) look smart and competent, but the real work is going to go to the programmers, just as it does today. UI designers will be able to give a "demo" but how will this basic functionality translate to the rest of the app? It won't.

sarchertech 3y ago
I hate it when designers present what looks like polished and complete UIs in Figma. To the execs it looks like a finished product which frequently creates unreasonable expectations that interfere with what should be the iterative nature of UI design. I don’t know how many times I’ve come across a project where a terrible system design was foisted on a group of engineers because of the constraints required by a Figma design that was blessed by some exec or other. Granted there are worse problems in these orgs, but easy high fidelity mock-ups vs wire frames has made it worse.
- tsunamifury 3y ago
  I hate it with engineers complain moan and drag their feet on implementations that are hard but worth it. Because really under the surface they just don’t like doing something new, even if it has clearly defined user and business value.
  - jayd16 3y ago
    I suspect you're on the wrong side of town for a comment like this, haha. Almost always its just conflicting requests. Every ticket has a clearly defined user and business value to the person who wrote it.
    - tsunamifury 3y ago
      I managed a 250 person engineering team at FANG. The number of times I had to explain to a jr or mid level engineer what our fundamental business was, was astounding. They would constantly argue tickets on a premise that was entirely self contained inside their code -- and be entirely oblivious to what the product was accomplishing outside in the real world with real users. Now this wasn't always the case, and frankly I ran into it much less there than I had at smaller companies. But it still happened a lot. And these engineers would always boast the most about how they knew best about X or Y. Maybe that was my fault as a leader -- but I couldn't fix the incurious.
      - jayd16 3y ago
        The disconnect is that both sides are valid. User value is important, but stability, opportunity cost, and ROI also provide user value. It's not valid to say that the realities of the current code base are irrelevant just as much as it's invalid to say clean code always trumps features.
        tsunamifury 3y ago
        That’s actually not true and this is the mistaken idea engineers have. It’s not a negotiation. User value that translates to business goals strictly always trumps internal code. Or you don’t have a business to fund that code. You find a way to do it if you need to fund the business. If not your are sunk.
        rcbdev 3y ago
        I agree with you to some extent, but if you go with this line of thinking consequently then things of no apparent "User Value" (say, a code base not riddled with technical debt) never gets any budget or attention in favor of shoehorning in more shiny stuff of obvious value. What this then leads to is borderline unmaintainable code because the project managers, software architects, etc. rarely touch the IDE anymore and the more junior people can't or won't articulate the issues they are having. (i.e. a feature made tests 10x slower, a hastily added API times out often locally, etc.) This then leads to people jumping ship every 1-2 years, low productivity and bad implementations. All in the name of precious User Value!
  - joshstrange 3y ago
    As a developer I actually agree. Too often we let “straightforward” or “fits best with the backend design” cause a knee jerk reaction to reject designs that are better for the end-user. I’ve been working to catch myself and say “yeah this won’t be easy but in the end it’s going to fit better with the user’s mental model of what they are doing”. The example I think of is if you have 2-3 related entities a developer might like a simple CRUD for each thing where you have to create the parent object before you can create the child (in a relationship). However sometimes the child is the obvious first thing a user wants to create so it’s important to build a UI that lets them create the parent on the fly or even have no parent until later. As a younger dev I dug in my heals too often on things like that and I think it’s made me much better as a dev to approach designs with fresh eyes and think about how I’d want to experience the UI/UX instead of bringing preconceived notions based on how we built the existing code/UI. One thing I will point out is I love working with designers who are open to “what if we did X instead of Y? X will take me 1 hour but the Y in your design will take 1 week”. Sometimes the “Y” is worth it and some times the designer thinks “X” is just fine (or even likes it better). Nothing is worse than strict designs passed down that need to be pixel-perfect with no wiggle room.
    - tsunamifury 3y ago
      I generally agree with you and its how I operate, but then you see Apple who strictly requires engineers to follow design/marketing requirements to the pixel -- and they are the most successful consumer business on the planet.
macNchz 3y ago
> how will this basic functionality translate to the rest of the app? It won't. It certainly will lead to fun and productive conversations like “it’s already working right there! Why is it going to take so long to get it into the app?!? Can’t you just download it?” Since well before GPT there has been an argument for making very early prototypes/mocks more obviously lo-fi, such that their visual polish is proportional to how functional they are under the hood. Beautiful, seemingly “working” UI-only prototypes have a way of setting unrealistic expectations even with clear communication, leading to a higher probability of proto-duction.
- strix_varius 3y ago
  A decade ago when I worked at an agency, we had a policy of having two branches of any given project: an internal one, and a version with "gray-boxes.css" applied. It's too difficult for humans to separate visually polished from functional and finished.
ilaksh 3y ago
How? You literally just give GPT-4 a new prompt: "Thanks. Please connect it to the rest of this code:" If you want it to do a better job, add "it's very important for my career". Lol.

sarchertech 3y ago

I hate it when designers present what looks like polished and complete UIs in Figma. To the execs it looks like a finished product which frequently creates unreasonable expectations that interfere with what should be the iterative nature of UI design. I don’t know how many times I’ve come across a project where a terrible system design was foisted on a group of engineers because of the constraints required by a Figma design that was blessed by some exec or other. Granted there are worse problems in these orgs, but easy high fidelity mock-ups vs wire frames has made it worse.

tsunamifury 3y ago
I hate it with engineers complain moan and drag their feet on implementations that are hard but worth it. Because really under the surface they just don’t like doing something new, even if it has clearly defined user and business value.
- jayd16 3y ago
  I suspect you're on the wrong side of town for a comment like this, haha. Almost always its just conflicting requests. Every ticket has a clearly defined user and business value to the person who wrote it.
  - tsunamifury 3y ago
    I managed a 250 person engineering team at FANG. The number of times I had to explain to a jr or mid level engineer what our fundamental business was, was astounding. They would constantly argue tickets on a premise that was entirely self contained inside their code -- and be entirely oblivious to what the product was accomplishing outside in the real world with real users. Now this wasn't always the case, and frankly I ran into it much less there than I had at smaller companies. But it still happened a lot. And these engineers would always boast the most about how they knew best about X or Y. Maybe that was my fault as a leader -- but I couldn't fix the incurious.
    - jayd16 3y ago
      The disconnect is that both sides are valid. User value is important, but stability, opportunity cost, and ROI also provide user value. It's not valid to say that the realities of the current code base are irrelevant just as much as it's invalid to say clean code always trumps features.
      - tsunamifury 3y ago
        That’s actually not true and this is the mistaken idea engineers have. It’s not a negotiation. User value that translates to business goals strictly always trumps internal code. Or you don’t have a business to fund that code. You find a way to do it if you need to fund the business. If not your are sunk.
        rcbdev 3y ago
        I agree with you to some extent, but if you go with this line of thinking consequently then things of no apparent "User Value" (say, a code base not riddled with technical debt) never gets any budget or attention in favor of shoehorning in more shiny stuff of obvious value. What this then leads to is borderline unmaintainable code because the project managers, software architects, etc. rarely touch the IDE anymore and the more junior people can't or won't articulate the issues they are having. (i.e. a feature made tests 10x slower, a hastily added API times out often locally, etc.) This then leads to people jumping ship every 1-2 years, low productivity and bad implementations. All in the name of precious User Value!
- joshstrange 3y ago
  As a developer I actually agree. Too often we let “straightforward” or “fits best with the backend design” cause a knee jerk reaction to reject designs that are better for the end-user. I’ve been working to catch myself and say “yeah this won’t be easy but in the end it’s going to fit better with the user’s mental model of what they are doing”. The example I think of is if you have 2-3 related entities a developer might like a simple CRUD for each thing where you have to create the parent object before you can create the child (in a relationship). However sometimes the child is the obvious first thing a user wants to create so it’s important to build a UI that lets them create the parent on the fly or even have no parent until later. As a younger dev I dug in my heals too often on things like that and I think it’s made me much better as a dev to approach designs with fresh eyes and think about how I’d want to experience the UI/UX instead of bringing preconceived notions based on how we built the existing code/UI. One thing I will point out is I love working with designers who are open to “what if we did X instead of Y? X will take me 1 hour but the Y in your design will take 1 week”. Sometimes the “Y” is worth it and some times the designer thinks “X” is just fine (or even likes it better). Nothing is worse than strict designs passed down that need to be pixel-perfect with no wiggle room.
  - tsunamifury 3y ago
    I generally agree with you and its how I operate, but then you see Apple who strictly requires engineers to follow design/marketing requirements to the pixel -- and they are the most successful consumer business on the planet.

macNchz 3y ago

> how will this basic functionality translate to the rest of the app? It won't. It certainly will lead to fun and productive conversations like “it’s already working right there! Why is it going to take so long to get it into the app?!? Can’t you just download it?” Since well before GPT there has been an argument for making very early prototypes/mocks more obviously lo-fi, such that their visual polish is proportional to how functional they are under the hood. Beautiful, seemingly “working” UI-only prototypes have a way of setting unrealistic expectations even with clear communication, leading to a higher probability of proto-duction.

strix_varius 3y ago
A decade ago when I worked at an agency, we had a policy of having two branches of any given project: an internal one, and a version with "gray-boxes.css" applied. It's too difficult for humans to separate visually polished from functional and finished.

ilaksh 3y ago

How? You literally just give GPT-4 a new prompt: "Thanks. Please connect it to the rest of this code:" If you want it to do a better job, add "it's very important for my career". Lol.