Sign in to join this conversation, and others like it, in the communities you care about.
Product Design / Toolbox
This may be a naive question but how do you see these tools or toolsets scaling and growing as development tools, requirements, languages, etc. change? \
I was nodding the whole way through this post.
> choose an actual UIButton in the toolbar, insert it into a View rather than an artboard and simply begin adjusting its actual native properties?
Have you seen Modulz? I'm working on something along the lines of what you're describing here.
No reason why it couldn't export to interface.json
I think that misses the point. You, in whatever role you see yourself, should be able to use the best tool for the job you’re trying to accomplish without having to redo work. Whether that’s building a component, defining routing, or defining behavior. You should only need to do the same task once.
maintaining design systems as a task shouldn’t be a full time role, it should be the source of truth across roles and a way of staying in-sync rather than something that needs to be kept in-sync itself.
A point of feedback and discussion on the proposed format: It seems like what you put above only addresses static components.
From my experience, a lot of interface complexity rears its head in two cases: when you take into account component state, and the context of each component. What I mean by context is the device the interface is on, or properties of that device (for example, if the device is turned horizontally, or the interface being on an iPhoneX device vs. a iPhone 8).
I understand this proposal is early, but do you have any thoughts on how the format could address this?
there certainly needs to be handling for this for my example above with the UIKit syntax to work at all
@bryn Product teams should basically never do the same thing twice. I think what you're describing would be a great place to be at at some point. I think we can start by looking into each of our small processes and look how we can improve those. They should lead us to an open, interchangeable format that you're describing.
It can be as small as changing the copy on a design. If there is back and forth between the designer who edits the file and renders a flat image and the content strategist who comments on those flat images. Why can't we bring those people closer together?
If we're doing this we realize that the "handoff process" might not be as good as it can. Designers rendering flat images of their potentially powerful structures in Sketch/Figma/Adobe XD, is a total loss in depth.
Anyway, great read! 👏
Great post. Been drafting some similar thoughts, but no where close to this fidelity. Interested in your thoughts on where rectangles and pen tools shine: rapid, generative sketching of non-existing patterns, @bryn. I.e. aggressive forking of existing components in cases where completely new views are needed
Good question, @dannywhite! I think non-existing patterns are rarely created, and rarely the right approach to be honest. There's certainly room, though. I'm not advocating for removal of those primitives (Illustration is great and you should be able to illustrate using good illustration tools!), but more for the addition of UI-appropriate primitives that are determined by a standard.
@bryn great post. 100% agree. The reason I joined Fuse in the first place was because I realised that in the process of making a great app development platform, they created a really powerful design tool. What you are describing is basically a more platform agnostic version of our UI layer, written in JSON instead of XML. I also think this problem will be solved by making design an indistinguishable part of the product development cycle. I don't think UI tools are best positioned to make that happen.
Love this Bryn. I've also been thinking about how design tools are limited by language. We can typically design for out native language. But we so often ship in multiple. No design tool is set up to quickly change language and filter through the design accordingly. This proposed format could certainly help that.
Love this @bryn. I’m very interested in this. Recently I've been looking into tools created for specialized purposes like creating car dashboards/HUD's and there's so much advancement in this space. We might take notes from this industry: Some of these tools lean heavily on API's, binding data to objects to assist with jobs like logic within the interface, localization, and automation. More and more I feel our tools should integrate tightly with one and another, this could bring teams and disciplines closer together.
This is a great post - one I think I'll be re-reading and quoting to colleagues.
I'm particularly intrigued by where we could possibly go with this particular idea of yours: "auto-generate a flow-map for your application based on route properties".
Imagine having integration with QA tools that would enable high-level testing to take place ahead of build, teasing out interesting edge cases to design for.
Hi, I've been writing about something similar, the need for UX source files:
I'd love to get in touch and share thoughts.
Best regards, Julius
But seriously, thank you for this very thoughtful post. There hasn’t been a great leap in our tools yet, but I feel like it’s going to be soon.
I especially feel the pain of, *‘Attempting to manage design systems manually across incompatible formats is a full-time job that always results in inconsistencies.’* One thing that I wonder about is how Interface will deal with complex dev. environments, dependencies, and all that. Dev. environments at my work are exceedingly complex, so I balk at bringing that pain (back) into my work as a designer. (I used to write front-end code at this job, but the dev. env. and legacy code were two huge pain points that made me want to just design.)
I'd rather just design in code until *all of the work I do* can contribute directly to the end product with no manual reproduction
(that said, I do use design tools for illustration/icon work - which they're great for)
I think dev environments are magical when they're well-maintained.
Just thinking of all the behavior my IDE has due to open source tooling defined by standards makes me super excited about what abilities design tooling could have
And you weren’t very fair to Framer. 😉 Their code-centricity really sets them apart from these other illustration tools. Still, it falls short from your vision. Your point about the disposable nature assets is true of Framer. They are aware of this, and I bet they will get on top of this (as they’ve started to ship partial solutions to this). Your other point about design tools being ignorant of real components is keen (only seeing rectangles). Framer doesn’t solve this either, but I feel like they are best suited to nail this as well, particularly because of the code-centricity. 💅
I've talked to Koen and Jorn quite a bit about this (forgot to include them in thanks 😅) and I think it has the same dead end as every tool, despite its code-centricity.
This is a really interesting perspective and I find myself agreeing with more and more. When InVision announced Studio, I remember feeling excited but also skeptical in it actually solving the problem. With your post, I realized that the problem isn't with the tools, it's with the workflow (and our understanding of the workflow), and I think what you're proposing is a better workflow between design and development and with that, the proper tool.
indeed @bomberstudios - seems to be same intent with slightly different goals (theirs seems to be aiming for cross-platform with same data. I'm a little skeptical of that piece.) but they definitely emphasized the omni-directionality of flow across tool, which I think is very important.
This has been on my mind for some time too, but this write up is much more thorough than I could've imagined. Thanks for that @bryn!
At the Sketch Plugin Hackathon that we organized in Berlin there was a team that made a proof of concept of the `.svgsymbol` file format that aims for omni-directionality and cross-platform design/dev. Even though the PoC was limited to working with Sketch & Framer, I can see it as a first step (like you mentioned) that could go in this direction for building on top of the current structures of symbols/components and map that to a codebase.
See more here: https://github.com/gerrit/sketch-svgsymbols
And the recording of the hack demo here: https://vimeo.com/242445551#t=23m55s
What do you think?
great post thank you - I'm currently having this exact problem with our design to engineering and back again, in some cases engineering may change some elements and then create some 'design debt' that we need to update back in our design system within Sketch. We've looked at the React Sketch plugin which would help but its not great, this would definitely be the direction forward!
As a designer whose full time job is basically updating and maintaining a UI library alongside a custom CSS framework and Angular module architecture... this resonates with me on a deep level. Will be paying close attention to the conversation in here! Thanks for kicking it off @bryn