31–40 of 145 posts
It sounds to me like what the effect that the author dislikes is actually more often than not a good thing. Of course non-conventional designs have their time and place as well, but I'm not worried about designers being unable to pursue those just because Figma nudges them in the other direction.
No, here’s the problem: Figma doesn’t go far enough. If you need a free form design tool to sketch, use one. There are hundreds of them. I need to implement my design system inside of a design tool so I can prototype designs with multiple breakpoints, container queries, modes, and variants. Figma isn’t up to the job. Ever tried opening the variables tab on the Material 3 Figma file? Stutter, stutter, stutter, “this t…
Yeah... Just do pictures on the design phase and then code.
There’s no reason that a tool can’t model a design system and make producing consistent designs that use it trivial.
I think the problem with Figma is that it tries to appeal to visual designers, UX designers, and programmers. Good for business, bad for users.
No, here’s the problem: Figma doesn’t go far enough. If you need a free form design tool to sketch, use one. There are hundreds of them. I need to implement my design system inside of a design tool so I can prototype designs with multiple breakpoints, container queries, modes, and variants. Figma isn’t up to the job. Ever tried opening the variables tab on the Material 3 Figma file? Stutter, stutter, stutter, “this t…
Eventually I’ll have a working end-to-end prototype together, but not yet unfortunately.
Having designed websites with Dreamweaver, Photoshop, Illustrator and Sketch, I absolutely love Figma and especially Auto Layout. I don't think people realise how annoying it was to design a list of repeatable items. There already was a concept of "smart object" or "component" that could be duplicated in instances with variations. But laying them out was really cumbersome: if one of the instance had a different heigh…
No, here’s the problem: Figma doesn’t go far enough. If you need a free form design tool to sketch, use one. There are hundreds of them. I need to implement my design system inside of a design tool so I can prototype designs with multiple breakpoints, container queries, modes, and variants. Figma isn’t up to the job. Ever tried opening the variables tab on the Material 3 Figma file? Stutter, stutter, stutter, “this t…
I’m actively working on an alternative right now. It’s a tool for designing in the browser, using HTML and CSS. Everything is parametric by design, including tokens. Eventually I’ll have a working end-to-end prototype together, but not yet unfortunately.
No, here’s the problem: Figma doesn’t go far enough. If you need a free form design tool to sketch, use one. There are hundreds of them. I need to implement my design system inside of a design tool so I can prototype designs with multiple breakpoints, container queries, modes, and variants. Figma isn’t up to the job. Ever tried opening the variables tab on the Material 3 Figma file? Stutter, stutter, stutter, “this t…
Code is merely the leanest human-readable representation for loss-less specification of requirements.
We're seeing this same pattern with 'K8s YAMLs' and 'prompt engineering'. There is an entire industry that's re-inventing new DSLs which inevitably converge to a scripting language as requirements get more complex.
Instead of reinventing the abstraction, I'd like to see no-code UX patterns that losslessly map onto the underlying abstraction. That way you can use the UX pattern until it gets too tedious, and occasionally dip in-and-out of the code-view in a non-jarring manner.
Graph UI for manipulating git trees (gitgraph) is a great example. Orchestration UI views (Airflow / Langraph) are another example that's getting there. At a higher level of abstraction, Notion (CRDT UIs) do a good job of representing collaboration-locks using blocks. At the highest view, I'm a big fan of how Gather-town represents remote collaboration.
I'd like to see more of this.
No, here’s the problem: Figma doesn’t go far enough. If you need a free form design tool to sketch, use one. There are hundreds of them. I need to implement my design system inside of a design tool so I can prototype designs with multiple breakpoints, container queries, modes, and variants. Figma isn’t up to the job. Ever tried opening the variables tab on the Material 3 Figma file? Stutter, stutter, stutter, “this t…
Assuming Figma is meant to serve the design process, it tries to stretch far into implementation territory, but does it at the expense of the exploratory phase. Everything Figma adds either screams MAKE IT READY FOR DEV or GET ALL YOUR MANAGERS A FIGMA SEAT™. Those are not concerns for the early exploration and research stage. If Figma is one of the first tools I boot up in my design process, I'm immediately running into a conflict of priorities.
I put it in contrast with old-school Photoshop UI work (younger devs: yeah, it was pretty much the one option, plus the only thing taught at design schools). Photoshop was great at the exploratory phase. I would sketch ideas with my Wacom tablet and eventually translate hand-drawn wireframes to actual mockups. I still miss that workflow, it was great. The tradeoff then was that "final" documents were static, fixed dimensions documents that usually left technical issues to be discovered later during the dev stage.
Photoshop shaped the design process just as much as Figma does now. That's what the readily available tool does to someone using it regularly.
Completely agree with the author. > This is contrary to my belief that any digital design process should start with rough sketches, but move quickly into code and iterate from there. As a dev, this is the point I resonate with the most. To me, the ideal dev designer interaction is collaborative and iterative. But the current state of affairs is one where all the design is done upfront, and little is done in terms of…
To me, one of the dirtiest words in dev designer interaction is "handoff". There's always a point in the lifecycle of any design tool where they start talking about it -- even if they quietly disagree with it in principle. My impression is that it normally happens when they're trying to acquire customers who (unfortunately) practice such dysfunctional team dynamics.
As a developer who designs, I've always found myself jumping between code and visual design tools; but rarely based on the current stage of the project and more often based on what kind of thinking I want to do. If I want to engage with the constraints I more often do it in code, if I want to explore tangents, I open up the design tool.
No, here’s the problem: Figma doesn’t go far enough. If you need a free form design tool to sketch, use one. There are hundreds of them. I need to implement my design system inside of a design tool so I can prototype designs with multiple breakpoints, container queries, modes, and variants. Figma isn’t up to the job. Ever tried opening the variables tab on the Material 3 Figma file? Stutter, stutter, stutter, “this t…
Isn't this the problem with all no-code / low-code platforms ? Code is merely the leanest human-readable representation for loss-less specification of requirements. We're seeing this same pattern with 'K8s YAMLs' and 'prompt engineering'. There is an entire industry that's re-inventing new DSLs which inevitably converge to a scripting language as requirements get more complex. Instead of reinventing the abstraction,…
https://worrydream.com/refs/Brooks_1986_-_No_Silver_Bullet.p...
For instance, a 2025 no code platform is likely to have "one click" deployment of a cloud application. That's great if you can accept that but if you require "on prem" this is either disqualifying or requires you to build an environment on prem that can host whatever it is they generate, which could be more trouble than building an application the old fashioned way in an environment you already know how to run.
A conventional analysis is that you should be able to generate a CRUD application out of a schema: you need a little bit more than something that looks at a SQL schema and creates a form to INSERT, UPDATE or DELETE, but that's a start.
One problem is that people write schemas that suck despite there being a body of "commonsense knowledge" about how to the world works. I had a year when I fixed a tremendous number of broken applications and one insight I got out of that was that whether it was a student who went from being an applicant to being enrolled to being an alumni or a pallet that would live in a logistics network and then enter a "reverse logistics" network and be inspected and possibly repaired to be returned to the logistics network the same data model of an object going through a number of states with state transitions was general and much better than the 15+ date columns that were added haphazardly to those columns.
Another example that kept turning up was that the ticket "1 phone number for a customer is not enough, support 2 phone numbers" is inevitably followed by "2 phone numbers is not enough, support 3 phone numbers" -- it saves time to work the proof by induction up front and just support N phone numbers up front. But talk that way and people think you're a lunatic like Doug Lenat.
Deployment, code generation from schemas, and schema generation from meta-schemas are part of the solution but if you can't solve 100% now getting that last bit is ultra-hard mode because all the essential complexity hidden by the framework is suddenly in your face.