8 ms·

What design tools get wrong

199 points by deanalevitt 7y ago

golergka 7y ago
It seems that author advocates for design tools to become more and more like developer tools - a notion that I, as a developer, can totally get behind. However, in my 12 years of experience in game development, many people who are world-class designers and artists don't have the same mental model as developers. There are a lot of "technical art" issues that in the end, you'd rather handle on a developer's side. I just don't think that a person who spends his time thinking about character's emotion, colour balance, human anatomy and other art-related issues is in the same mind space to think about technical issues like which UI containers should be scaled on what rules (full-screen or safe area? hugging the screen outside or inside?) for different screen sizes, how things should be composed from layers and animated, how assets can be converted from a static image to a resizable one, how a giant image can be cut into a 9-slice (or in a more complicated way) to save texture budget, how can we reuse already existing assets without importing another image that is very, very similar, how different kind of gradients behave with not-pixel-perfect scaling and crunch compression (and I didn't even go into 3d!). I tried empowering designers and artists so they would make these decisions, but they hated it and were miserable - so in the end I'd rather get a static, single-sized PSD and do all that work myself. All of this, of course, are just my 2 cents from a specific industry and with a very specific kind of people in mind - I'm not trying to impose these views on any designers and artists who want to get into the technical art side and would be thrilled to see more and more individuals who can be productive and happy in this kind of hybrid role. But as a matter of fact, these people are very, very rare and we shouldn't expect most artists to be like that.
- lucideer 7y ago
  I think you're right, but I think the motivation for a lot of posts like this are rooted in developers working with designers who believe "issues like which UI containers should be scaled on what rules (full-screen or safe area? hugging the screen outside or inside?) for different screen sizes" should be within their domain of influence. That separation of responsibilities is always a tough line to define in reality, and I do agree that the tools used by whomever is assuming that role should become more like developer tools.
- nkrisc 7y ago
  I see where you're coming from but I disagree on a few points. I work as a UX designer, designing web UI. I should understand and consider how the design will flex when the browser is resized (and understand what's possible). I have a good understanding of what will be trivial to implement versus what will require an extra week of development for little gain. I need to understand how the web works so I can think about how the site will work on a bad connection, how it will work when the request times out, how the data that powers the site is shaped and the implications of that. The web is my medium and how can I effectively design for the entire experience (not just how it looks) if I don't understand how the web fundamentally works?
  - golergka 7y ago
    I don't think that we really have something to disagree on here. Web and app designers like you are more technically and design-oriented; however, I'm talking about game development, where these roles require much more pure "art" skills: you don't use simple material design here, you actually draw all the real-looking materials (in the artistic style of the whole project) and characters and every little shiny detail.
    - nkrisc 7y ago
      Perhaps I misinterpreted your comment then. But all the same, my work is not simply applying material design to websites. We're creating our own branding and "art", but still we have to distill that down into something that can actually be implemented by a developer. Early on we do all kinds of crazy stuff but we always have to be thinking about how we'll bring it back down to Earth and how it will be used and experienced.
- parksy 7y ago
  Kind of agree (as a developer who appreciates art) - right now we're constraining ourselves to grid-based layouts. Having been in web professionally for 15 years and recreationally for 25 years, I've seen UI conventions change a lot as technology, form factors and global design trends change. So modern tools like sketch work for grids, mobile responsive, yada yada which is much better than using photoshop as the design sits closer to the canvas it will be rendered on. As a developer, yay that works great for me! And also it's a huge middle finger to those designers who just built stupid impossible pointless UIs in the 90s and 2000s. But it's also very constraining for the designer, especially given how far standards have come, and it's almost a given that someone is going to come along and Bauhaus the shit out of UI. I really enjoyed the challenge of implementing a truly creative design on the web, but there has been a general convergence towards a convenient middle point where the designs are constrained by development requirements, at least in the way the tools are geared. That's not to say a great artist can't create something amazing but if we have to teach all our creatives that they must conform to this particular way of thinking, then we're cutting the industry short in a bad way I think. I guess the next thing will be a sass or js library called bauhaus.js. Or is that just DOM + CSS?
  - HeWhoLurksLate 7y ago
    > it's almost a given that someone is going to come along and Bauhaus the shit out of UI. I nearly fell out of my chair of laughter when I read that. Out of curiosity, do you mean this in a positive or a negative way?
- xsmasher 7y ago
  A UX designer or UI artist should absolutely be concerned with these things. Every UI artist I know has asked "How do I do 9-slicing?" on day one. I try to put as much power in the hands of the UI artist; if they have full control and an accurate preview (or better yet, WYSIWYG) then they can iterate on the screens without my involvement, and turn in something beautiful that I just need to connect to the actions / data sources. > a person who spends his time thinking about character's emotion, colour balance, human anatomy and other art-related issues Non Sequitur. Those are character artist concerns, not UI/UX artist concerns.
comis 7y ago
I could nitpick the authors points, but honestly this article just boils down to "Design tools need more features!" which I generally agree with. We're living in nice times for design tools though - Figma/Sketch are leading the pack and moving extremely fast. We're no longer in the dark ages of waiting 5+ years for Adobe to implement some basic feature (like being able to round corners on a rectangle). Well, I guess if you're for some reason using xD you're still waiting a comically long amount of time between significant releases, but that's your own fault.
- shams93 7y ago
  Well a lot of people don't know how to use Figma properly and still are exporting css with absolute positioned items so there's certainly a need for courses on Figma its a very deep tool but its not going to give usable results by default.
  - chrisweekly 7y ago
    Got any good links to share that would help designers level up w/ Figma and leverage it properly?
- ebiester 7y ago
  More importantly, they have a separate use case that needs a set of features that aren't well covered by the current set of tools. Maybe it isn't even more features, but rather a completely different tool. This could be a market opportunity.
doitLP 7y ago
Sounds like the author wants his tools to be as fully featured as the code that will embody the resultant design. In that case I would recommend learning more code instead of relying on a proxy that will never be as flexible. The best designers I’ve worked with not only understand their own domain but the possibilities and limitations of how it will be executed, because they are also developers.
- shredprez 7y ago
  A little background: you are more or less describing the author of the blog post! That’s the interesting thing about being a coder who designs, the tooling on both sides always lets you down at least a little. Having that wider context is worth the disappointment, I think.
- pcmaffey 7y ago
  Basically this. It's mind boggling to think a designer could ever excel without knowing how to work with the medium they're designing for. One of the fundamentals of art school is learning how to work with the characteristics of your medium.
  - davidivadavid 7y ago
    The whole purpose of tools is to make craft accessible to more people. It's perfectly logical not to expect a designer to excel without knowing what they're designing for, but to expect tools to aim for that goal. How much knowledge has to be "in the head" vs. "embedded in the tool" can be debated, but the direction where things generally go seems pretty obvious.
    - TeMPOraL 7y ago
      Is it though? If so, it's deeply troubling. The purpose of a screwdriver isn't to make working with screws more accessible, it's to make it possible and convenient. The purpose of power drill isn't to be more accessible than a screwdriver - it's to enable working faster and easier with screws, and to enable working with screws and materials for which using a screwdriver isn't feasible. This brushes my primary annoyance about modern software - the current trend is to focus on making the basic, entry-level tasks accessible, at the expense of tasks that a proficient user might want to perform. The more advanced tasks are not just made more difficult - they're often made impossible.
phaedryx 7y ago
I worked at an agency with designers. We (web developers) convinced the designers to use Sketch for the stuff that they did for us. It saved us a ton of time over receiving Photoshop and Illustrator files to work with (the traditional "design tools"). Sure, things could be improved, but I love that we have Sketch and Figma now.
- jdhn 7y ago
  I've found that agencies are behind the times when it comes to design tools. I once exported a screen of a mobile UI from Sketch as a PDF, only to be told "When I opened it in Photoshop, it was one flat layer. Can you send over your original Photoshop file?" I told them that the original was made in Sketch, and that was the last I heard from them.
  - ypeterholmes 7y ago
    To be fair, Sketch is a Mac only program, so the team may have just been unable to use it, and preferred to just move on rather than purchasing an entire new computer (and Sketch). It would perhaps been more helpful to have responded by offering to provide your Sketch assets/layers via Zeplin, which is free and web based.
    - deleted 7y ago
      [deleted]
    - poof_he_is_gone 7y ago
      Sketch files also open in Figma which is free, browser based, and OS agnostic.
anoffsinger 7y ago
I recommend you try Figma, as it addresses and solves most of the gripes in your post.
deleted 7y ago
[deleted]
erikpukinskis 7y ago
Somewhat off topic, but this gets at an issue with “components” of all types that I’ve been wanting to get off my chest: > Design libraries are also limited in the type of things they share: just components or symbols. This works great if all your design work is just clicking together new screens with the same components, but anything new will see designers clicking into components and copying over things like colors, font variants and checking spacing just to copy that over into new components. When you copy over things, you’ll invariably make mistakes (we’re just human after all). Ideally, a component system means you’re black boxing some function. Unfortunately every component system I’ve ever seen has a hard boundary at some “material” transition: A UI drawing that can be used inside a design program A React component is bounded at the DOM and can’t handle server side concerns A CSS component is bounded at styles and can’t handle HTML concerns A middleware component that handles authentication, but can't reach outside the routing phase. etc Inevitably then, you end up having two or more tightly coupled components: A front end component + the server API that it knows how to talk to A little HTML widget + a microservice that it feeds with it’s own persistence A container for wrapped content + a little middleware meant to be added to the app that serves the content A button + a delayed job + an email template to get sent when it's done etc In order to do this, instead of just having one module with a tight set of concerns inside it, you have to implement some of your concerns in two places, and you also have to map data into the component interface, and then back out again. In some cases this can be 4x the complexity ("code" vs. "code + write to component interface + decode component interface + variant of code on other side of interface"). If the component could span both domains, it could just move the data exactly where it needed to go, as efficiently as possible, since the data is all internal to the component. The conclusion I’ve come to is something like "components want to be free." I.e. components want to have concerns that can span the entire stack, and implement procedures in arbitrarily disparate kinds of source locations. This of course precludes ALL of the component systems which are confined to a specific material domain. It means the boundary of a component has to look something like arbitrary source code. Component interfaces can’t conform to a single template. That raises the question “what is a component at all?” If the boundary of my component is just a set of function calls, it’s just a module. How is it a component? And maybe it’s not. Maybe components are a local maximum in code cleanup, and I’m advocating people move past them and just write really excellent single-concern modules instead. I don’t know. This is as far as I’ve thought it through. (I do maintain an NPM module called browser-bridge that lets me build arbitrary client/server components, along an event sourcing library called a-wild-universe-appeared for doing persistence in an isomorohic way, and then something called bridge-module for getting dependencies in the browser... All of which let me experiment with what I'm describing, but those are all in a pre-1.0 mostly beta state. The basic interfaces are all stable though.)
matthewhager 7y ago
We created exactly what you are looking for at https://shift.studio https://shift.studio. You design “systems” which are web components built in React (though as a designer, this is abstracted away from you). The components have variants, state, data, and we have a fully featured media query system to help you handle responsive design. Finally, we’re fully integrated with NPM so you can pull code in if you want and add functionality to your design system. We will soon add the feature to expose your design system as an NPM package so that developers can install the system into their project and the component creation can be the domain of the designer with the application structure/creation being the domain of the developer. This is a problem that can be solved but it can’t be half-baked solutions. It has to allow designers to fully create all states of a component and even work on components with live data flowing through. We are in closed beta but you can view videos of how Shift works here: https://www.youtube.com/playlist?list=PLl4_DbGKML_Jb2Wq5pEGWgPznK6mUj0tC https://www.youtube.com/playlist?list=PLl4_DbGKML_Jb2Wq5pEGW...
poof_he_is_gone 7y ago
I think that design tools are slowly but surely zeroing in on this. The updated versions of Sketch, Figma, and InVision can support responsive layouts, and all of them are moving from being able to create static designs, to interactive prototypes. There are several plugins and workflows out there that will convert your designs to useable code, and it is only a matter of time before this software is doing that natively and representing the full stack.
tomger 7y ago
I don’t think the author has spent a relevant amount of time with Figma
marcintreder 7y ago
I think the underlying premise of this excellent article is that design tools have to get closer to the capabilities of web technologies in order to bring much needed realism to the design process. This is exactly what still gets me going after nearly 10 years working on design tools (I co-founded UXPin back in 2010). I'm so glad that more people in the industry notice it! Majority of the popular design tools (Sketch, Figma, InVision Studio, XD...) work in a 30 year old paradigm of image based–design tooling (originally created for early vector and raster "creative" tools that were never meant to be used to design software interfaces!). In this paradigm the output of a design tool is an illustration of the final product that has no relation to the reality of code. The rendering is different, the interactions are just slide-based simulations, the ability to describe states is nonexistent. To get more down to earth - those tools can't even render a simple text field or a checkbox! And yes – they're getting better and better, but ultimately getting around the limitations of their paradigm is impossible. At the end of the day those tools are perfect for drawing icons and illustrations, but really bad at creating, for example, a working prototype of a form field with validation. That's why a bunch of design tooling rebels (UXPin, Framer X, Modulz, Interplay, Shift...) started to work on code–based design tools. In this paradigm the output of a design tool is rendered from html/css/js code, but designers don't necessarily need to know how to code. Majority of UXPin users don't even know that they're prototyping interfaces with advanced JavaScript :). Within code–based paradigm the limitations of image–based tools do not exists. In reference to the article here are some features present in UXPin (and some others just to illustrate my point): - states of elements (every element can have multiple states and variants, originally we've built it in 2013. The new version was launched last year). - conditional interactions - javascript expression (from advanced math, regular expressions to operations on strings - in UXPin designers can build really advanced prototypes) - context awareness (prototype can be aware of the os/browser that is used for previewing or e.g. the size of the screen and conditionally render the right state of elements) - accessibility linters - import and synchronization of production React.js code (in beta, we're calling it UXPin Merge) - access to external APIs (you can, for example, build prototypes that can interact with smart devices) None of that is possible in the old paradigm! Of course the giants of the design industry don't want you to know it, so they invest tens of millions of dollars into flashy marketing:) Some things that Kilian mentioned are still missing, but we (and others!) are working on them. Hope this is providing some context to the state of the design tooling industry. Ps. Fun fact - Figma branded themselves as the first design tool with real time collaboration. We have it since 2011 and... it was also called multiplayer design :)

199 points by deanalevitt 7y ago

It seems that author advocates for design tools to become more and more like developer tools - a notion that I, as a developer, can totally get behind. However, in my 12 years of experience in game development, many people who are world-class designers and artists don't have the same mental model as developers. There are a lot of "technical art" issues that in the end, you'd rather handle on a developer's side. I just don't think that a person who spends his time thinking about character's emotion, colour balance, human anatomy and other art-related issues is in the same mind space to think about technical issues like which UI containers should be scaled on what rules (full-screen or safe area? hugging the screen outside or inside?) for different screen sizes, how things should be composed from layers and animated, how assets can be converted from a static image to a resizable one, how a giant image can be cut into a 9-slice (or in a more complicated way) to save texture budget, how can we reuse already existing assets without importing another image that is very, very similar, how different kind of gradients behave with not-pixel-perfect scaling and crunch compression (and I didn't even go into 3d!). I tried empowering designers and artists so they would make these decisions, but they hated it and were miserable - so in the end I'd rather get a static, single-sized PSD and do all that work myself. All of this, of course, are just my 2 cents from a specific industry and with a very specific kind of people in mind - I'm not trying to impose these views on any designers and artists who want to get into the technical art side and would be thrilled to see more and more individuals who can be productive and happy in this kind of hybrid role. But as a matter of fact, these people are very, very rare and we shouldn't expect most artists to be like that.

lucideer 7y ago
I think you're right, but I think the motivation for a lot of posts like this are rooted in developers working with designers who believe "issues like which UI containers should be scaled on what rules (full-screen or safe area? hugging the screen outside or inside?) for different screen sizes" should be within their domain of influence. That separation of responsibilities is always a tough line to define in reality, and I do agree that the tools used by whomever is assuming that role should become more like developer tools.
nkrisc 7y ago
I see where you're coming from but I disagree on a few points. I work as a UX designer, designing web UI. I should understand and consider how the design will flex when the browser is resized (and understand what's possible). I have a good understanding of what will be trivial to implement versus what will require an extra week of development for little gain. I need to understand how the web works so I can think about how the site will work on a bad connection, how it will work when the request times out, how the data that powers the site is shaped and the implications of that. The web is my medium and how can I effectively design for the entire experience (not just how it looks) if I don't understand how the web fundamentally works?
- golergka 7y ago
  I don't think that we really have something to disagree on here. Web and app designers like you are more technically and design-oriented; however, I'm talking about game development, where these roles require much more pure "art" skills: you don't use simple material design here, you actually draw all the real-looking materials (in the artistic style of the whole project) and characters and every little shiny detail.
  - nkrisc 7y ago
    Perhaps I misinterpreted your comment then. But all the same, my work is not simply applying material design to websites. We're creating our own branding and "art", but still we have to distill that down into something that can actually be implemented by a developer. Early on we do all kinds of crazy stuff but we always have to be thinking about how we'll bring it back down to Earth and how it will be used and experienced.
parksy 7y ago
Kind of agree (as a developer who appreciates art) - right now we're constraining ourselves to grid-based layouts. Having been in web professionally for 15 years and recreationally for 25 years, I've seen UI conventions change a lot as technology, form factors and global design trends change. So modern tools like sketch work for grids, mobile responsive, yada yada which is much better than using photoshop as the design sits closer to the canvas it will be rendered on. As a developer, yay that works great for me! And also it's a huge middle finger to those designers who just built stupid impossible pointless UIs in the 90s and 2000s. But it's also very constraining for the designer, especially given how far standards have come, and it's almost a given that someone is going to come along and Bauhaus the shit out of UI. I really enjoyed the challenge of implementing a truly creative design on the web, but there has been a general convergence towards a convenient middle point where the designs are constrained by development requirements, at least in the way the tools are geared. That's not to say a great artist can't create something amazing but if we have to teach all our creatives that they must conform to this particular way of thinking, then we're cutting the industry short in a bad way I think. I guess the next thing will be a sass or js library called bauhaus.js. Or is that just DOM + CSS?
- HeWhoLurksLate 7y ago
  > it's almost a given that someone is going to come along and Bauhaus the shit out of UI. I nearly fell out of my chair of laughter when I read that. Out of curiosity, do you mean this in a positive or a negative way?
xsmasher 7y ago
A UX designer or UI artist should absolutely be concerned with these things. Every UI artist I know has asked "How do I do 9-slicing?" on day one. I try to put as much power in the hands of the UI artist; if they have full control and an accurate preview (or better yet, WYSIWYG) then they can iterate on the screens without my involvement, and turn in something beautiful that I just need to connect to the actions / data sources. > a person who spends his time thinking about character's emotion, colour balance, human anatomy and other art-related issues Non Sequitur. Those are character artist concerns, not UI/UX artist concerns.

comis 7y ago

I could nitpick the authors points, but honestly this article just boils down to "Design tools need more features!" which I generally agree with. We're living in nice times for design tools though - Figma/Sketch are leading the pack and moving extremely fast. We're no longer in the dark ages of waiting 5+ years for Adobe to implement some basic feature (like being able to round corners on a rectangle). Well, I guess if you're for some reason using xD you're still waiting a comically long amount of time between significant releases, but that's your own fault.

shams93 7y ago
Well a lot of people don't know how to use Figma properly and still are exporting css with absolute positioned items so there's certainly a need for courses on Figma its a very deep tool but its not going to give usable results by default.
- chrisweekly 7y ago
  Got any good links to share that would help designers level up w/ Figma and leverage it properly?
ebiester 7y ago
More importantly, they have a separate use case that needs a set of features that aren't well covered by the current set of tools. Maybe it isn't even more features, but rather a completely different tool. This could be a market opportunity.

doitLP 7y ago

Sounds like the author wants his tools to be as fully featured as the code that will embody the resultant design. In that case I would recommend learning more code instead of relying on a proxy that will never be as flexible. The best designers I’ve worked with not only understand their own domain but the possibilities and limitations of how it will be executed, because they are also developers.

shredprez 7y ago
A little background: you are more or less describing the author of the blog post! That’s the interesting thing about being a coder who designs, the tooling on both sides always lets you down at least a little. Having that wider context is worth the disappointment, I think.
pcmaffey 7y ago
Basically this. It's mind boggling to think a designer could ever excel without knowing how to work with the medium they're designing for. One of the fundamentals of art school is learning how to work with the characteristics of your medium.
- davidivadavid 7y ago
  The whole purpose of tools is to make craft accessible to more people. It's perfectly logical not to expect a designer to excel without knowing what they're designing for, but to expect tools to aim for that goal. How much knowledge has to be "in the head" vs. "embedded in the tool" can be debated, but the direction where things generally go seems pretty obvious.
  - TeMPOraL 7y ago
    Is it though? If so, it's deeply troubling. The purpose of a screwdriver isn't to make working with screws more accessible, it's to make it possible and convenient. The purpose of power drill isn't to be more accessible than a screwdriver - it's to enable working faster and easier with screws, and to enable working with screws and materials for which using a screwdriver isn't feasible. This brushes my primary annoyance about modern software - the current trend is to focus on making the basic, entry-level tasks accessible, at the expense of tasks that a proficient user might want to perform. The more advanced tasks are not just made more difficult - they're often made impossible.

phaedryx 7y ago

I worked at an agency with designers. We (web developers) convinced the designers to use Sketch for the stuff that they did for us. It saved us a ton of time over receiving Photoshop and Illustrator files to work with (the traditional "design tools"). Sure, things could be improved, but I love that we have Sketch and Figma now.

jdhn 7y ago
I've found that agencies are behind the times when it comes to design tools. I once exported a screen of a mobile UI from Sketch as a PDF, only to be told "When I opened it in Photoshop, it was one flat layer. Can you send over your original Photoshop file?" I told them that the original was made in Sketch, and that was the last I heard from them.
- ypeterholmes 7y ago
  To be fair, Sketch is a Mac only program, so the team may have just been unable to use it, and preferred to just move on rather than purchasing an entire new computer (and Sketch). It would perhaps been more helpful to have responded by offering to provide your Sketch assets/layers via Zeplin, which is free and web based.
  - deleted 7y ago
    [deleted]
  - poof_he_is_gone 7y ago
    Sketch files also open in Figma which is free, browser based, and OS agnostic.

anoffsinger 7y ago

I recommend you try Figma, as it addresses and solves most of the gripes in your post.

deleted 7y ago

[deleted]

erikpukinskis 7y ago

Somewhat off topic, but this gets at an issue with “components” of all types that I’ve been wanting to get off my chest: > Design libraries are also limited in the type of things they share: just components or symbols. This works great if all your design work is just clicking together new screens with the same components, but anything new will see designers clicking into components and copying over things like colors, font variants and checking spacing just to copy that over into new components. When you copy over things, you’ll invariably make mistakes (we’re just human after all). Ideally, a component system means you’re black boxing some function. Unfortunately every component system I’ve ever seen has a hard boundary at some “material” transition: A UI drawing that can be used inside a design program A React component is bounded at the DOM and can’t handle server side concerns A CSS component is bounded at styles and can’t handle HTML concerns A middleware component that handles authentication, but can't reach outside the routing phase. etc Inevitably then, you end up having two or more tightly coupled components: A front end component + the server API that it knows how to talk to A little HTML widget + a microservice that it feeds with it’s own persistence A container for wrapped content + a little middleware meant to be added to the app that serves the content A button + a delayed job + an email template to get sent when it's done etc In order to do this, instead of just having one module with a tight set of concerns inside it, you have to implement some of your concerns in two places, and you also have to map data into the component interface, and then back out again. In some cases this can be 4x the complexity ("code" vs. "code + write to component interface + decode component interface + variant of code on other side of interface"). If the component could span both domains, it could just move the data exactly where it needed to go, as efficiently as possible, since the data is all internal to the component. The conclusion I’ve come to is something like "components want to be free." I.e. components want to have concerns that can span the entire stack, and implement procedures in arbitrarily disparate kinds of source locations. This of course precludes ALL of the component systems which are confined to a specific material domain. It means the boundary of a component has to look something like arbitrary source code. Component interfaces can’t conform to a single template. That raises the question “what is a component at all?” If the boundary of my component is just a set of function calls, it’s just a module. How is it a component? And maybe it’s not. Maybe components are a local maximum in code cleanup, and I’m advocating people move past them and just write really excellent single-concern modules instead. I don’t know. This is as far as I’ve thought it through. (I do maintain an NPM module called browser-bridge that lets me build arbitrary client/server components, along an event sourcing library called a-wild-universe-appeared for doing persistence in an isomorohic way, and then something called bridge-module for getting dependencies in the browser... All of which let me experiment with what I'm describing, but those are all in a pre-1.0 mostly beta state. The basic interfaces are all stable though.)

matthewhager 7y ago

We created exactly what you are looking for at https://shift.studio https://shift.studio. You design “systems” which are web components built in React (though as a designer, this is abstracted away from you). The components have variants, state, data, and we have a fully featured media query system to help you handle responsive design. Finally, we’re fully integrated with NPM so you can pull code in if you want and add functionality to your design system. We will soon add the feature to expose your design system as an NPM package so that developers can install the system into their project and the component creation can be the domain of the designer with the application structure/creation being the domain of the developer. This is a problem that can be solved but it can’t be half-baked solutions. It has to allow designers to fully create all states of a component and even work on components with live data flowing through. We are in closed beta but you can view videos of how Shift works here: https://www.youtube.com/playlist?list=PLl4_DbGKML_Jb2Wq5pEGWgPznK6mUj0tC https://www.youtube.com/playlist?list=PLl4_DbGKML_Jb2Wq5pEGW...

poof_he_is_gone 7y ago

I think that design tools are slowly but surely zeroing in on this. The updated versions of Sketch, Figma, and InVision can support responsive layouts, and all of them are moving from being able to create static designs, to interactive prototypes. There are several plugins and workflows out there that will convert your designs to useable code, and it is only a matter of time before this software is doing that natively and representing the full stack.

tomger 7y ago

I don’t think the author has spent a relevant amount of time with Figma

marcintreder 7y ago

I think the underlying premise of this excellent article is that design tools have to get closer to the capabilities of web technologies in order to bring much needed realism to the design process. This is exactly what still gets me going after nearly 10 years working on design tools (I co-founded UXPin back in 2010). I'm so glad that more people in the industry notice it! Majority of the popular design tools (Sketch, Figma, InVision Studio, XD...) work in a 30 year old paradigm of image based–design tooling (originally created for early vector and raster "creative" tools that were never meant to be used to design software interfaces!). In this paradigm the output of a design tool is an illustration of the final product that has no relation to the reality of code. The rendering is different, the interactions are just slide-based simulations, the ability to describe states is nonexistent. To get more down to earth - those tools can't even render a simple text field or a checkbox! And yes – they're getting better and better, but ultimately getting around the limitations of their paradigm is impossible. At the end of the day those tools are perfect for drawing icons and illustrations, but really bad at creating, for example, a working prototype of a form field with validation. That's why a bunch of design tooling rebels (UXPin, Framer X, Modulz, Interplay, Shift...) started to work on code–based design tools. In this paradigm the output of a design tool is rendered from html/css/js code, but designers don't necessarily need to know how to code. Majority of UXPin users don't even know that they're prototyping interfaces with advanced JavaScript :). Within code–based paradigm the limitations of image–based tools do not exists. In reference to the article here are some features present in UXPin (and some others just to illustrate my point): - states of elements (every element can have multiple states and variants, originally we've built it in 2013. The new version was launched last year). - conditional interactions - javascript expression (from advanced math, regular expressions to operations on strings - in UXPin designers can build really advanced prototypes) - context awareness (prototype can be aware of the os/browser that is used for previewing or e.g. the size of the screen and conditionally render the right state of elements) - accessibility linters - import and synchronization of production React.js code (in beta, we're calling it UXPin Merge) - access to external APIs (you can, for example, build prototypes that can interact with smart devices) None of that is possible in the old paradigm! Of course the giants of the design industry don't want you to know it, so they invest tens of millions of dollars into flashy marketing:) Some things that Kilian mentioned are still missing, but we (and others!) are working on them. Hope this is providing some context to the state of the design tooling industry. Ps. Fun fact - Figma branded themselves as the first design tool with real time collaboration. We have it since 2011 and... it was also called multiplayer design :)