Where the design community meets.
Freelance Graphic Designer Joined over 7 years ago
Jed hasn't posted any stories yet.
Yep, you nailed it – we just have different needs. My need for buy-in is a good way of putting it.
BTW you didn't upset me at all. Hope I didn't piss you off either.
Have a good one mate.
How is "just" improving prototyping not helpful? For me, everytime I send a Figma prototype to a client, it needs to be accompanied with many sentences like "in the real app, this would behave like this...". Because the prototype itself cannot do the job. This increases cognitive processing for viewers of the prototype, and makes it harder to get everyone on the same page. A picture tells a thousand words, but in this case, we have to rely on the thousand words.
If you don't see a use case for stateful components, then perhaps you aren't designing interfaces with multiple options for interaction on each interface, and with the need to communicate it's behaviour to various stakeholders, not just front end devs. That's fine if you're not, but my use-case absolutely calls for stateful components, and is in fact the only feature that I really miss in Figma.
It's not about delight for me, it's about communicating the expectations of an interface/workflow to stakeholders/the team.
I tried on new iMac and bailed. I guess I have pretty low tolerance for loading screens.
You certainly do not need to illustrate different states side-by-side. You only do this because of a limitation of your tools. If you can do hover states and other interactions in the prototype, why would you need to show it side-by-side?
Keep in mind that many designers are also doing their own front-end dev (like me). So I want to show a prototype to my team/client that has some form of reality before I spend the time to code it.
I can live without stateful components for web design (for the most part), but for web-app design it's a whole other matter.
For me it's more than just a convenience. Without it, my prototypes feel like toys.
I design web apps, and when prototyping, I want to show multi-page/element flows, with conditionals depending on user input (for example). Simulating a choice a user has made is a nightmare which includes entire screens for each option. So it quickly gets out of hand.
And before you say "do it in code", I do. I do it in code because I don't have a GUI tool that can do the job, which is a real shame. That's why these design tools are like toys for the kind of work I do. Useful for playing with UI ideas, but very lacking when it comes to interaction.
Accordians, tabs, dropdowns, sliders, hover states, overlays. I could go on and on. Stateful components in Figma would be an absolute game changer for me. No contest the single thing that makes me go to HTML/CSS so early in the design process is for stateful components.
Everything we do is documented in Trello. Normally a card for each feature, but sometimes we decompose them for larger features.
So I guess it's not a framework, but we can search for the card and read the thread for it if we want a history of that feature.
I bought it a couple of days ago. It's well presented, but I'd say less than half of the course is about React. Lots of it is about CSS.
It's also very basic. So I guess I would only recommend it if it's literally your very first introduction to it. I had already run through some tutorials and other courses, so I found it too basic.
I did Wes Boss' React for Beginners, and found this much more useful personally.
Jed hasn't upvoted anything yet.
Where the design community meets.
Designer News is a large, global community of people working or interested in design and technology.