What has me really excited about building websites is largely around design systems and the design tools we use to build them. Though, design systems are certainly not limited to websites.
Closing the Gap
In the ever-so-hot-right-now world of design systems, one of the most common phrases people use is “bridging the gap” (between designers and engineers). This was on several résumés I reviewed during my time at Salesforce when we were hiring for the Lightning Design System team. It’s a fair endeavor to strive for, as we want to bring alignment, coherence, and unity to our product design and engineering — all with the goal of having a quality-consistent experience for the people using our products and services.
However, “bridging the gap” still implies there is a gap. Why is that gap there in the first place? Is it due to many years of legacy process and workflows that still seep into our day to day work? I could see legacy being a real-world scenario need to work through. But what about newer, smaller startups? Why do many of them have a gap, too?
As a design systems practitioner, advocate, and enthusiast, I am always seeking ways to improve the people side of our work: how we meet and communicate, how we prioritize our roadmap, and how we can iterate on our process and way of working. However, another piece of this are the tools we use.
Some of our tools have come quite a long way, and it certainly seems that a new one is announced pretty frequently these days. But the ones that really get me excited are where I see them do more than “bridge the gap”.
A while back, when Modulz arrived at the scene, I noticed they used the hashtag, #closethegap. I couldn’t help but love that.
I am loving the @Modulz #closethegap slogan. Why bridge a gap when you can get rid of the gap all together? Fill that gap in! Haha.
— design systems jina (@jina) October 22, 2018
I’m very keen to see our design tools move away from simply bridging gaps and more toward closing them. For example, a feature I see as only bridging the gap is a “developer handoff” (which tends to rely on pixel dimensions and hex codes delivered as a spec). In my experience, delivering specs like this can promote duplication in code, inconsistencies, and are prone to errors. An example of closing the gap, however, are tools that work with actual, real, quality code instead of vector boxes.
Some tools achieve this by exposing design tokens — you can see that in InVision DSM which has tokens built-in as a feature. Another tool, Diez, is an open-source developer toolkit using tokens to turn your design language into scalable code. There are other tools like the previously mentioned Modulz, along with Interplay, that work with coded components but in a visual way. This is much better than the earlier WYSIWYG editors of the past because their generated code can be accessible and production-quality. And that’s not to leave out the other players in this space like Adobe, Figma, Framer, Sketch, UXPin, and many, many more that are also doing a lot to move this forward.
The Invisible Design System
Something I’ve been thinking a lot about is how much time we spend on making beautiful design system websites. I love looking at them. They’re great. But as our design and engineering tools get closer and closer together, will we come to a point where we don’t need the website? Can our tools surface suggestions for better accessibility, localization, performance, and usability, because our design system is baked into the tools? Just a thought.
The No-Code Movement
Webflow, which empowers people to build websites (complete with business and e-commerce features) without writing code, recently had a conference called No Code Conf. According to their website, the conference celebrates the future of visual development.
This is a movement that, while not new, is growing rapidly. In addition to building a full-featured website using Webflow, visual, declarative app-building has been explored for years at larger tech giants like Salesforce (with their Lightning App Builder) to smaller companies like Glide which let you generate an entire app from a spreadsheet. And with all of the task-based automation services such as Zapier and IFTTT, there is much you can do without writing code at all.
Now don’t get me wrong. I still love writing code, and I love seeing other designers code. I enjoy working closely with engineers as well. I’m not saying we shouldn’t code at all. But I’m excited to see us move away from a slower “throw designs over a wall” process. I want to see people able to make things without the requirement to write code. It will also be nice to move away from the tired argument on whether designers should code — and we all move toward what can we make together?
And if we can get to a point where we don’t need to bridge or close any gaps because the gap never existed at all — well that’s a pretty exciting world I want to be in.
Steve, I thought I was alone. Way to describe right where I’m at, too (I probably have more design experience but less JS). Polished and professional CSS/HTML as a deliverable is an underappreciated skill!
Tools should not build websites, or applications, etc. I’m not sure how many people can remember the horrible days of Microsoft Frontage, Dreamweaver, and similar tools. Tools that were built to allow anyone to build websites “without coding”. One of my first large jobs was for a large state agency that had almost 10,000 html files that were built by department secretary’s who were given the task to create the content in Frontpage because it was “easy as using Word.” These files were a series of agency guidelines for field counselors to bring services to the public, kind of a big deal don’t you think.
The agency had several lawsuits brought againist them “by their own staff” because the documents weren’t accessible for blind staff.
Tools are great. but if you don’t understand the underlying foundation of what the tool is suppose to do, in other words, if you can’t do it without the tool, you probably shouldn’t “oly” do it with a tool.
Now, I now there are a lot of areas where this statement doesn’t apply, like a lot of graphic design work, but again, if you don’t understand underlying principles of the type of graphics you’re trying to design, those graphics probably aren’t going to come out looking very good, or following any kind of design principles.
I know a lot of people are going to through me under the bus for this but, IMO, final sites or full systems should be coded by a someone who’s an SME in that area, not left up to a tool to hopefully code everything correctly. Otherwise you’re telling every web designer or develpor their jobs arent needed anymore.
I’m not telling people they shouldn’t code. I didn’t say that at all. Coding is great. If you can do it, keep doing it. But the No Code movement is a reality that is gaining traction and it has nothing to do with people who “can’t code”. It’s about getting designers and other non-coding folks able to contribute and create things as well without the requirement to code.
I think the future has a mix of code and no-code. Both are equally important and bring democratization to software creation. Tools like Glide, Utilize (https://www.utilize.app), Stacker (stackerhq) are taking the no-code space forward.