You can imagine a version of the world where designers structure their designs in a way that can easily export to e.g. a vue component, and along with the base structural layout they define different UI states it can be in, with animation timelines. Designers should be able to specify every aesthetic variable, and developers just program the business logic to fill content tags and toggle designer-defined states.
This is what I’m doing. I’ve been building a “programming language” for UI designers. The idea is that they just describe the visual behavior, and then devs can wire it up with business logic.
There’s many ways to style things on the web and in apps, but every framework has to grapple with a number of constraints:
- Usability (if a design system is too unfamiliar, people won’t use your product)
- Ability to compose components
- Accessibility (keyboard nav, clear roles, large font sizes, high contrast colors, etc.)
- Internationalization (left to right, etc.)
- Responsiveness
- Page load time
- Server side rendering
There is lots of room for small, artisanal design systems that shunt some of those constraints. It may be better to think of those design systems more as experiments, or art.
I like how this encourages designers to think about all the states of a UI component.
I understand that there are designers and design orgs out there with the discipline to be detailed in their design to cover all states of a UI element. There are also many designers that just design for the happy path. For the latter, we need to ensure they start to think about edge cases for what they are designing.
I've worked on a few design systems. Thinking about future interoperability and themeability is hard when creating a design system, and it really would make sense to have some conventions that help foster an ecosystem - that can also outlive specific frameworks.
Will be checking out UI Themes and Blocks UI mentioned here for new projects. Designer tooling (Figma plugins or something for Hadron) for these would help significantly with designer/design team adoption and creation/maintenance of high quality themes and UI components - which in turn would feed popularity of the whole ecosystem.
This is not a design system, this is just a UI library and an incomplete one at that. A design system would define semantic colors and fonts, a navigation hierarchy, and a far more exhaustive list of custom components that can represent all the possible types of data that an application ever needs to present.
I get your point, but don't you think it is somewhat complicated?
When you are the main dev in such a project, would you be willing to give this huge responsibility to some guy who might loose interest after a few weeks? What then?
Also, I have seen people doing graphical sketches of possible UI's and people think nice - but it is a whole different thing to actually implement this (especially with so little money involved), when the to do list involves 10 million other things.
Also, usually the problem is the designers are not coders and quite often the code base is not designed in a way, where you can just swap out the UI for a new one.
But yes, I'd love to see more collaboration of designers with a vision and coders.
Designers absolutely need to focus on dynamic issues and state issues. Not all state is exclusively the developer’s domain.
There’s language, locale, time of day (which you mention), accessibility, screen resolution and those are just things off the top of my head that are implicitly exist as state in a designers head.
Then there’s the whole idea of transitions which are explicitly about state and in designers domains.
You can’t tell me designers don’t care about transitions. It’s developers who usually don’t care about that state.
And that last bit is my point. Let designers handle the state they care about. UIs will get better as a whole with it.
Looks very useful! In terms of feedback, I think if you brought in a designer you'd have a much bigger "wow" factor. There's a lot of low hanging fruit like consistent button styles, fonts, whitespace, larger text inputs, that'd go a long way. And I'm sure you've thought of this already, but seems like a node-based paradigm could be an improvement over the panel-based paradigm e.g. more akin to something like Blender nodes, or Tableau.
Sooner or later (IoT, AR, VR) we will have to let devices (AI) to assembly the final user interface.
I imagine something like this: we designers / developers / UI architects are creating plenty of interconnectable components describing our idea of a product covering all scenarios and use cases.
Then the device will asemmbly the final UI based on the individual user, and the device capability.
For example a watch will display something different than a large digital billboard on a skyscraper.
And everyone of us will see a different design each time we look at a display, based on our individual digital history (Data mining).
The point is predetermined design must be advanced to on-demand, context based, liquid design. We let the big picture be assembled by third party, we focus only to smaller components.
How would this work in practice though? Sorry if the question seems dumb.
For your own example : orders, customers and products. How would you generate a UI that matches design decisions of your product? Without specifying super detailed rules, in which case you could write it yourself? What am I missing?
I feel like I must be on crazy pills for suggesting that the designer's deliverable should be something like UWP XAML documents. I wouldn't necessarily expect them to do any fancy data binding, but they should be able to at least lay things out and maybe manually fill in some dummy data.
I've been building UI for years now and all these points highlighted by Dan are spot on. Great post!
I've been thinking lately about the "design system" trend that is becoming more and more popular where companies want more control over styling and behaviour to make their UX unique to their brand as well as consistent across all their products. Ready-made 3rd party components like the excellent react-select don't really fit into this world as general purpose components like this naturally have to make some choices regarding styling and behaviour. No matter how customisable they are, in the end they rarely integrate well into a UI based on a design system.
This makes me feel like the abstraction is all wrong. Rather than aiming for fully-functional, out-of-the-box components that cater for all manner of general purpose requirements, how about a library/framework that focuses on a set of primitive components that deal with the lower level concerns like layout, scrolling, positioning, etc. Maybe the abstraction could be more like "composable shapes" than "ready-made components" or something along those lines.
With this approach, you wouldn't ever start out with something like a ready-made Autocomplete component, for example. Instead, you would always build a custom Autocomplete and have complete control over styling and behaviour, but it would be built from solid foundations using some form of the "shape" abstraction. That way, you can focus on making the component's styling and behaviour consistent with the design system without having to worry so much about layout, accessibility, scrolling, positioning, etc - as all of these are taken care of by the framework.
I hear what you're saying about the UX part... I think that this can be solved if the developer has knowledge in this area and can consult with the designer during the design process.
This is the process at the company I work for and it works quite well. For more complex projects that have a lot of interaction the designer comes up with a look and feel and a color palette and then the developer requests additional graphic elements as he feels they are necessary...
reply