[O]rganizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.
It’s worth understanding the thinking behind Conway’s law because there’s a good chance it’s going to influcence how your team works and what you end up producing. When I was younger, I resisted unstoppable forces like these. I’ve learned better as I’ve gotten older.
By having a real, dedicated team it means the design system can flourish. Bugs can be addressed in a timely manner rather than being thrown into an abyss that never gets looked at. New features can be added to the design system, which further improves the lives of the people using it.
I think the real value of “productizing” a design system is not that it’s treated like a product. Sure, that’s helpful, but I think the overwhelming value comes from what that mindset change represents. Once something is a product, you need folks who own it. You need people who are accountable. You need to define success.
I think it’s the structure of productizing that’s important. Maybe that’s just obvious and I’m deluding myself that it’s worth bringing up…
I vascilate on the value articles like these provide to the community. On one hand, it would be nice if there was a general understanding of what a design system is. Having to roll that boulder up the hill isn’t fun. On the other hand, I question if there is a common definition. Hell, we still can’t align on what Design is or what it encompasses. Articles like these that attempt to “answer” often just create more questions.
I think things like Design and Design Systems are less something you universally define but rather develop a localized point of view on. An organization can absolutely decide on a what a design system is to them. But getting that universal “answer”? I’m not so sure.
Building UIs has a very long tail: it’s fairly easy to get the basics for a given component working, but there are many details to consider, and these add up to a majority of the work.
Read this article and tell me front-end skills aren’t a vital part of creating software. There’s so much detail that goes into component development. As the author says, it’s easy and fast to get something. But not so much to get something good.
Modern design languages offer a lot of flexibility with their focus on fundamentals like typography, white space and simplistic icons. But sometimes, using an old school real world metaphor adds a lot of delight to an experience.
See: Pendulum swing. I see the flat design movement akin to manufacturing decisions for mass production. Flat design enabled a much more streamlined and reproducible interfaces. But… Maybe some of those interfaces felt a little.. mass produced. I don’t think that’s due to the flat design aesthetic, but rather the lower barrier of entry.
Don’t weigh other design system’s decisions too heavily. You have no idea the constraints they were working under to arrive at their decisions.
There’s tons of good tidbits of advice in this article. The article doesn’t go too deep into any, and that’s OK. I could quote a ton of the bulletpoints from the article, but instead I’ll just suggest you read them yourself.
We all have to force ourselves to see the truth, because the truth hurts. The truth is that our ideas weren’t right, our insight isn’t shared by customers, our awesome design is confusing, our potential customers love that competitor we’ve been calling ‘dumb,’ that thing we say is ‘broken’ is not in fact broken, the pain we insist our customers are experiencing, they’re not experiencing. Did you even ask? If you asked, were you listening? If you haven’t made major changes to your strategy and product and positioning, then you’re blundering. Seek the truth, then face the truth.
In many ways, design systems are like mini startups within a company. You’re often bootstrapping your “product”, being scrappy to find consumers within your company—all with the hope of gaining investment to grow and scale. This article is super helpful to contextualize how to avoid the kind of mistakes that can tank your precious startup.
Craft isn’t glamorous. In fact, it can be pretty boring. Craft doesn’t require innovation or a big show, but the curiosity to consistently study your materials and practice your techniques. It’s knowing that big moments are made of tiny ones. That every second counts. For a chef, it might be peeling the mushroom skin even if clients will barely notice. For a designer, it might be organizing files even if that work is not going to be celebrated. Everything we do informs how we approach our lives.
Craft and quality continue to be in the current spotlight. What’s been missing (for me at least) is a dissection of how we ended up in our current position. That’s a whole subject altogether, but I do think what’s been forgotten or glossed over is that craft takes work. Like, a lot of it. And it’s often hard, menial, unappreciated labor. Things like organization, creation of detailed specifications, file hygiene, precision in execution. Design system teams know that because it’s typically a huge part of the day-to-day. I’ll be interested to see how this conversation evolves, but it’s interesting how the unsung ‘grunt work’ many systems teams have taken on for years is now coming back into fashion by the broader design industry.
I like to put it this way. Of the people who see your math paper, 90% will only read the title. Of those who read on, 90% will only read the abstract. Of those who go still further, 90% will read only the introduction, and then quit. Thus, it pays to put a huge amount of energy into making the front end of your paper clear and enticing. This can reduce those 90% figures (which I made up) to about 80%, leading ultimately to an eightfold increase in the number of people who read beyond your paper’s introduction.
There’s a ton of nuggets of wisdom in this article related to making something typically dry (math papers) into a more engaging ring. There are numerous lessons from this that can be applied to design system documentation. Give people a reason to read.
I will go to my grave holding the belief that documentation does not need to be “we’re so serious because this is serious business”. We’re writing about how doodads should show up on gadgets. Let’s have some fun people. I’d bet the farm more people would read “fun” documentation. Seems like a win-win.
So, what have we learned so far? Good typography can make your documents more influential and easier to consume. It can change people’s impression of your ideas and induce creative thinking. These benefits alone are enough to see that good design is scientifically proven to be impactful.
This is an absolute must-read—there are tons of great tactical learnings that can be applied to typographic systems. Additionally, it proves that aspects of design can be scientifically proven. There’s been a recent recoil from designers on the pressure to prove the value of design. I understand the frustration, especially given design can be harder to objectively measure than other aspects of software development. I don’t agree with the mindset that design is off the hook to appraise its impact. This work from Microsoft is proof that design’s worth can be measured/defined. I’m convinced more research like this will clear a path for greater understanding and valuation of design in the industry.
This blog post is the poster child for why design systems are feature teams’ best friend. Sure, a feature team could make their own avatar (or whatever) component, but are they really interested in the amount of depth/detail necessary to make it work across all use cases and scenarios? I think more blog posts like this which expose the iceberg of component design can be a great wake up call for teams who’d rather, “just make their own”.
But when it comes to design systems work you often have to explain to folks why your job is worth doing in the first place. As a product designer or engineer you might have to argue for a feature or even fight for the existence of a team if you’re unlucky, but you rarely have to deal with the existential threat that your whole career shouldn’t exist.
Relatedly, in my experience the number one psychological drain on design system team members is a lack of external understanding/recognition/valuing for what they do. Nearly every pain point comes back to this issue.
If there’s one thing design system practitioners should know before starting is that “making the case” is part of the job. It may be leadership, it may be consumers, it may be external customers. It may be all of them. It’s something I’ve come to expect given how long I’ve worked in this space. Accepting that as part of the work has made it much easier and, dare I say, fun part of the job.
It’s also critical for design system managers to be keenly aware of this issue and have a continually evolving strategy to support your team through this. Not just as a shoulder to cry on, but to get the team to a better place so they no longer need a shoulder to cry on. Easy to say, hard to do.
While there is some truth to Meta’s (Facebook) famous slogan ‘Done is better than perfect’, we’ve slowly begun to believe that ‘done equals perfect’ or at least, perfect enough. Sure, shipping early may be necessary to live up to customer expectations and needs, but it’s not sustainable in the long run.
Quality is all up in the current zeitgeist. I’m not confident that this pendulum swing is going to result in any true, sustained change. But that’s another topic for another day. I believe Anton calls out the obvious, but important fact that the iterative and “fix-it-later” nature of software development has atrophied teams’ ability to ship high quality experiences. What was the strength of software has become a hinderance.
This article isn’t directly tied to design systems, but the topic of quality is. If I was a betting man, I think these next couple years will see design systems playing a central role in raising the quality bar of software. Which is incredibly interesting as it’ll signal a change in focus from efficiency to refinement. That is, if this push towards quality doesn’t fizzle out beforehand.
A micro-interaction is a small, task-based interaction in digital products. It provides feedback or visual responses to user actions. These interactions guide users as they offer subtle cues about how to use a product.
This article is exhaustive and a great place to start for any system designer interested in learning the subject matter. Micro-interactions are a super interesting space to play in and the prototypical wheelhouse of design systems. These are the fine details that can raise the bar of quality so many companies are talking about. However, without restraint and continuity, they can do more harm than good.
I haven’t used this plugin and this is in no way an endorsement. I link to this because I think it represents a great way to educate designers on how to use a Figma features, components, libraries, etc. Written documentation is ideal for some use cases while video tutorials are ideal for others. Why not use both in their ideal fit?
Vercel consistently delivers easy-on-the-eyes interfaces and their new Geist documentation site follows suit. I’m less sold on its content and some interaction decisions, but it’s undoubtedly handsome. Which is why I added it to the list this week. I notice a lot of design systems teams—including ones I’ve been responsible for—put emphasis on the meat-and-potatoes at the detriment of visual appeal. We know for a fact those meat-and-potatoes are critical to a design system’s usefulness, but they can also fall under the radar for many folks.
I admittedly have a love/hate relationship with “veneer” as it is often misused to mask foundational gaps/failings. But it’s damned near impossible to ignore the impact it has on an unfamiliar and/or skeptical audience.
There’s something inspiring, yet demystifying, about watching a lump of clay turn into a final vessel, or a plate of ingredients into a delicious meal, or a series of pull requests into an elegant piece of software. When we can observe the process, we naturally pick up little habits, tricks, and techniques that strengthen our own work.
I enjoyed the premise of this post, although I’m not sold on the conclusion (e.g., buy our product). There are many things that I think add up to a team producing great work. One of the more critical things is what this post describes due to how it influences the work. If literally everyone will see your work, things like clarity of communication, attention to detail and strong organization skyrocket in importance. It’s far easier, and dare I say worth it, to cut some corners when the audience for your work can be counted on one hand. That’s not the case when the audience is everyone.
Where I diverge is that I don’t think we need another tool to do this. We can do this today—it’s a mindset shift, not a solution gap.
We often talk about ‘stability’ in software engineering, but in my work, I’ve found it more helpful to talk about ‘resiliency.’ Design is a frequent subject of iteration, whether via aesthetics, function, or code. Brand language evolves or is reinvented, products grow or fragment, interfaces are refined and reorganized. In all of these situations, the nature of a given design is changing in terms of both ‘what’ and ‘how’ — therefore, the code responsible for design needs to be more resilient than stable. That is, our code should be amenable to substantial changes in requirements such that implementing the desired modifications is possible with a minimum of friction while still achieving the desired outcome.
There’s a lot to this post (which is a great read), but this section stood out the most. Yes, resiliency in design systems is critical as they are often the most effective way to usher in those changes in requirements. A redesign with a design system is hard enough as it is, but without one, it can be an existential challenge for teams lacking serious operational and organizational horsepower.
You’ll rarely discover ‘what’s next’ by standing still. Start working on something. Start tinkering. That will put you in motion to figure out what ‘the thing’ is.
Is this advice specific to design systems? Nope. But it’s especially helpful for our practice given how systems can so frequently feel overwhelming and everything-all-at-once. Often times the best advice is to take a deep breath and put a foot forward. Do anything. Then learn. Then repeat.
…AI tools can supercharge many facets of design system work. Of course it’s critical to stress that all of this is emerging technology, has the potential to do a lot of harm, and should be handled with care. A human-centric mindset along with a healthy level of skepticism (especially in these early days!) should be employed when wielding these new tools.
I’m thankful for teams like this doing the homework around how AI can be employed within the context of a design system. This is going to be increasingly a part of our lives, whether we like it or not. I agree that it could be a major help, if used responsibly. And, as Brad mentioned, skepticism is going to play a major role in whether that happens—or not.
Bold elements demand your attention. When too many elements demand attention it can make an interface worse. Good design is partly about how attention is directed. That becomes harder when lots of things look important. They distract people from whatever is actually important.
I’ve been thinking more and more about how to employ an “emphasis” ramp within design systems. I think design systems can get a bad rap because they frequently have to play on the safe side. So visual styles tend to get muted so they’ll work in whatever circumstance. I would be interesting use have an emphasis dial (beyond size or primary/secondary) where elements can be amped up or chilled down based on need.
I’m admittedly shooting from the hip with this idea, but this great article (which you should totally read) immediately made me think of it.
That’s it, no duplicative versions to showcase changes across breakpoints, no time-consuming red lining necessary in order to communicate how the style should change as the screen does. The fluid and atomic foundation built in to our atomic content components handles those repetitive design decisions for you.
Folks in the design system space take something like this for granted. It’s simply a given. I don’t think that’s necessarily the case outside of the practice. In my experience, teams are typically time starved. What’s one of the (many) things suffers? Yup, documentation. Lack of time means less documentation means engineers aren’t up for success means a lower quality end product. A mature design system is a major win as it removes gobs of functional requirements that would need to be documented. The bigger win is not needing to have everyone understand the nuances of those functional requirements. THe bigger, bigger win is not dealing with inevitable lost-in-translation deviations at scale if they were expected to.
The GOV.UK Design System makes it [shipping a redesigned crown] possible to do this in a consistent way through its centralised open-source codebase, GOV.UK Frontend. The Design System team updated the crown in versions 5.1, 4.8 and 3.15, to make sure that services using older versions of GOV.UK Frontend can update it as easily as possible.
Yes, design systems speed up workflows. But that’s really just the start. The increased speed/efficiency enables new ways of working altogether. This is something I discussed often at Pinterest. The speed a design system brings allows for greater agility, and thus a more nimble product development process. Want to redesign your icons every 6 months? I wouldn’t suggest that, but with a mature and well adopted design system, it’s entirely feasible. One person can redesign icons, swap out the assets of your system’s Icon component and voilà you’re done. That’s just not something that would even be up for consideration without a design system.
I would really like to have the chance to work on an email design system. It seems super challenging, it can be a huge time-sink for teams to work on (which amplifies the value of systemizing) and it’s typically a “needs improvement” area for companies in terms of design. Looking through Stack Overflow’s design system gets me even more eager to play in this space. Big props to them for opening it up.
I love that we’re beginning to see toolchains like this and I expect to see much more of this in the months/years ahead. One caveat that concerns me however is the use of Figma as the source of truth. If I was responsible for a large design system with hundreds of consumers, I’d want 100% full ownership over the core data source with all third-party tools pulling from it. Call me old fashioned, but I’m not comfortable with Figma being the driver for something as critical as design tokens.
Once you publish something, the convention is that whatever you wrote was what you thought before you wrote it. These were your ideas, and now you’ve expressed them. But you know this isn’t true. You know that putting your ideas into words changed them.
System design is, far and away, the most challenging form of design I’ve ever worked on. That’s due to many reasons, but a significant portion of that is due to the continual process of articulating rationale and intent. Designing an elegant solution is challenging at baseline. Designing that solution and then documenting it to be comprehensible and repeatable by a whole org of varying skillsets and experience is just another level altogether.
But it’s that requirement of writing that makes system design such a formative practice for an individual. Because through writing, we end up improving our initial ideas. It makes our thinking and our work better because of it.
Watch out for people using ‘good taste’ and ‘bad taste’ as exclusionary terms. When someone says “you need to have good taste” but doesn’t break down what taste means in an objective manner, they might be using it as an excuse to exclude people. Historically, taste has been an elitist concept and intentionally kept blurry and subjective to prevent people from accessing certain places, groups, or opportunities.
I’ve come to loathe “taste” being thrown around in design conversations because it’s so rarely followed up with any objective definition. Much of the real work in corporate America is not the actual work, but rather managing how that work actually gets done with an army of people with different opinions, agendas, incentives, etc. Aligning seems impossible at baseline, so injecting squishy, indeterminate variables into the equation is simply unproductive.
What is productive however is for large organizations to clearly articulate their collective definition of things like taste and quality—along with a commitment to adhering to them. Unfortunately, that has been exceptionally rare in my experience.
As the U.S. defense community loved to point out in the 1980s, quantity has a quality all of its own. The reverse applies to software—the more you have of it, the more risks you run.
This article is well worth the read. While its subject is security-related, the underlying reason why bloat leads to security risk also leads to risks to stability, performance and general comprehension. For far too long, our industry has taken shortcuts to ship “good enough”. And I understand the appeal, but “good enough” continually heaped upon more “good enough” eventually leads to crap.
Another great quote:
To some, complexity equals power. (…) Increasingly, people seem to misinterpret complexity as sophistication, which is baffling—the incomprehensible should cause suspicion rather than admiration.
This is another topic altogether—it’s something I’d like to write about down the road. I completely agree with this quote—we should have an immediate skepticism to complexity. Far too may nefarious things hide in the tall grass of complexity. We know this to be the case in fine-print, why don’t we hold the same suspicion for overly-complicated experiences.
Why do I bring this up in the context of design systems? Because design systems can be the driver or the firewall of bloat. I think it’s critical for our practice to take the harder road and hold the line.
Let’s say there is an icon of a lightbulb. Lightbulbs can be a symbol for an idea, so you name the icon “idea”. A couple of years later, your team wants to use the lightbulb for an electrical component and changes the name to “electricity”. This requires your team to devote time and resources to make the change as well as your team now must use the mental effort of remembering a new name for the icon. If the icon had been named “lightbulb” from the beginning, teams wouldn’t have to learn the name of the icon because they already have a mental model of that symbol. And there wouldn’t be a need to change the icon in the future.
This is one of the many, many reasons why design systems should include content design into the core practice. So much of a design system’s success or failure comes down to comprehension, yet we so often don’t give it the attention it needs.
And please, for the love of all that is holy. Do not name icons after features. There are few things in the practice that are just objectively right/wrong, but this approach just doesn’t ever end well.
I want to do anything and everything I possibly to promote the growth of Web Components. The current state of web development is overly complicated (see my issues with that in the previous article) and reliant on third-party libraries that I am not necessarily in love with. I want a web that doesn’t require firing up a terminal and installing lord-knows-how-many lines of someone else’s code before you can even get started. It doesn’t need to be like this. It shouldn’t be like this.
And frankly, it dilutes the focus of design systems from creating a codified experiential point of view to wrangling dependencies. It’s time to move on.
There’s no particular “hair on fire” problem that design systems solve that instantly sells to management. This can be frustrating to design system practitioners because we understand the intrinsic benefits of consistent UI over one-off solutions and maintenance nightmares. We trade immediacy in the short term for predictability over the long tail.
There are times in this line of work where I just need to sit the corner and breathe into a paper bag… My paper-bag-breathing is not directed towards the author, but rather to the hyper-myopic mindset that would drive someone towards such a conclusion. Design systems are a zero-interest rate phenomenon as much as roads are. Sure, they don’t directly make money, but at a some point in a company’s growth, it becomes harder and harder to make money without it.
I keep thinking that building infrastructure to ensure efficiency is just obvious, common sense. But here I am, still breathing into paper bags.
Critics of my position may point to what they believe is some sort of sentimentalism for old user interfaces on my part. It’s true that the problems I point to in this piece are of the kind that I consider solved in many of the older user interfaces. That has nothing to do with being sentimental however. Products have to work properly. If a button is the right choice, use a button. If it’s not, don’t. But if you are going to implement a design element that works like a button, it should look like one too.
I jokingly say that design systems aren’t about buttons, but they aren’t not about buttons either…
The author makes a strong case for the inherent usability of properly-leveraged skeuomorphism. At some point, the design practice veered into skeuoMOARphism where the practice jumped the shark with leather stitching and numerous other poor choices. Then, because any extreme movement needs to be countered with an opposite-yet-equally-extreme movement, we landed in flat design. I’ll be honest, I prefer flat design over leather stitching…
But the author is not wrong. A lot of the natural affordances from skeuomorphism do not really have an equivalent in flat design. I’m beginning to fall in the camp of skeuenoughism—where we have harken back to physical metaphors when it makes sense and just enough to get its point across.
When I decided that I didn’t want to be normal. I didn’t do it intentionally. I didn’t wake up one day declaring, ‘I’m an idiot surrounded by other idiots!’ No, I started with identifying behaviors that were corrupting my life and then made a conscious decision to replace them with alternative activities. Activities that were meant to contribute to my life progression, instead of persisting in current endeavors that have confined me in a wretched abyss of mediocrity.
This post isn’t about design systems, but it has a life lesson that I think is essential for a healthy design system. It’s a common trap to follow normal standards that other design systems follow. I think that’s a nasty habit that can often end in solutions backed by “everybody’s doing it”. Yes, I understand the irony given how design systems often ask teams to follow its “normal” components/patterns. I nonetheless stand by the statement.
I love exciting, and popular, and new software, but installing Arch showed me that popular isn’t as important as understandable.
The new hotness is exciting and, well, new. And if it’s well-supported, great! But nearly without fail, the old reliable solutions have more mature support and collective understanding. Which, also nearly without fail, will lead to better outcomes. We undervalue longevity and comprehension. It’s worth giving them serious weight.
Brad recommends a frontend workshop like Storybook for building design systems. Frontend workshops help you isolate UI components from applications and render their variants by mocking props, data and context. This way can verify UI appearance and behavior without needing to spin up the app.
Design systems do not implode because they don’t use Storybook. However, my brain imploded when Storybook decided it was a good idea to write this.
Akin to excess—absence, or minimalism, and the idea of “clean design” can sometimes make me not think or feel anything special when interfacing with said art, software, or device. It often fails to surprise or force a moment of pause to ponder—why does this feel great? Rightfully so, I do not need to be intellectually stimulated when making breakfast—it is conveniently acceptable for the design of the toaster not to be influenced by contrasting aesthetics.
The author goes into detail of mixing styles/aesthetics to create unique experiences. I think this post was supposed to lead me to a different conclusion, but instead I gravitate towards the line, “it is conveniently acceptable for the design of the toaster not to be influenced by contrasting aesthetics”. See, here’s the thing, there are a lot of products on the market that, despite their wishes, are toasters. And the people using them don’t want to some bespoke experience to invite curiosity, they just want toast.
Sometimes—hell, I’d say many times—we serve people best by squelching our desire to make something different, special or the envy of our peers. Instead, we just make an effin’ toaster that makes toast.
Most institutions, companies, and groups suffer from at least a partial lack of solid knowledge management. Fortunately, this is fixable by acknowledging the problem, understanding its sources, and addressing them in planned phases. Open source organizations can implement via iterative sprints, traditional companies via top-down project management.
I’ve battled for greater investment in knowledge management for the past 7 years. I can’t think of a phase in the corporate lifecycle where it isn’t useful. Are you endlessly hiring in a hyper growth stage? Knowledge management helps onboard and orient new hires so they can align faster. Cutting headcount? Hey, who isn’t nowadays? Well, a mature knowledge management process would ensure the expertise and domain understanding was maintained.
The most important investment you can make is in yourself. And that’s one of the hardest things for people or corporations to do.
While this may not technically be an example of design system documentation, it’s nonetheless handsome as hell. There’s a lot to learn from this wonderful set of guidelines. I know it’ll be something I refer back to numerous times.
The hub and spoke (also called “core + federated”) model is not the only solution, but it’s enabled Carbon to evolve an ecosystem that maintains design system compliance while driving innovation and evolution at the business unit and team level. All of which drives further growth of the design system and its community.
I like the idea behind hub and spoke, I really do. But I also think it’s important for folks to know just how much work it takes from all parties to make this model successful. It would represent a tectonic shift in how many companies work—where the system is at the core of nearly everyone’s job. And like I said, I’m totally down for that. But similar to the discussion of contributions, the sheer magnitude of commitment and effort is often brushed aside. Managing a system is hard. Managing a system of systems is like, really hard. There’s absolutely nothing wrong with things that are hard, I just think we need to be aware before jumping in.
We can’t predict the future, but we both know that there will be new frameworks with significant developer share AND there will be a ton of apps running React and jQuery and … for some time. Both are true, so why not support both?
This is exactly how I would build a design system if I was starting from scratch. There is no way that I want to be fully invested in any framework. They come and go and can fall out of favor faster than you can imagine. Don’t let a framework dictate the future of your design system. Create something that allows you to control your own destiny.
Have you ever had a zipper that gets stuck or the lining gets misaligned? When they fail, it can take the most beautiful designer jacket and make it feel completely worthless.
Designers, please do not take stability for granted. There is not a bigger hit to a person’s app experience than running into any bug—let alone a blocking bug. Quality means a lot of different things to different people. But don’t discount the importance of having something just do what it’s intended to do. Start there and build from that.
Impact testing is something that typically fell through the cracks on teams I worked with—to the detriment of everyone. This is one of those things I wish I could have taken back. It’s never someone’s highlight of the day to have their design break after updating a library. This is especially problematic if you’re working in an environment where it’s tough to get folks to update frequently. Don’t make the same mistake I’ve made. Have a test plan for component updates.
One of the primary elements of ensuring these promises come to fruition is consideration of the future. The decisions a design systems team makes have wider reach than a typical product team’s decisions, and as such require ensuring that the decisions the systems team makes will work for the company today, in 6 months, in 2 years, or beyond.
At the risk of being a human broken record, I strongly believe that the tech industry sorely underestimates the value of stability and continuity. You won’t find a more ardent supporter of iteration—but within the appropriate context. No, I do not believe it’s helpful to continually upend the foundations of a company or culture. Yes, we need to improve what’s not working, but we also don’t need to continually fix what isn’t broken. And that is especially true within the realm of design systems. Stability and familiarity is golden. So be careful with what you decide to change. Some change is good, but too often or too much at once can be risky.
I’m still forming about my opinion the use of AI that encompasses broad swaths of subject matter and information. However, I’m pretty sold on more targeted applications. I haven’t used this particular solution, but I’m bought into the idea. It’ll be interesting to see how this space continues to evolve.
Not that it matters what I think, but Nathan Curtis is one smart dude. I was truly impressed with Nathan’s thoughts in a recent Design Systems Podcast episode. I don’t think I’m breaking new ground by saying Nathan knows what he’s talking about, but I’m saying it nonetheless. There’s a ton of great nuggets of smart thinking in this conversation—it’s well worth a listen.
It’s a new year and that means a blank slate for this site. This page will be continually updated with 2024 posts. And if you’re feeling nostalgic, you can go back to the 2023 archive.
We want to include pictograms in our design system package to make it easy for other engineers to use throughout the product, but there are some problems. To include every option, we’d have to store a different SVG file for each color combination, which means a 1kb SVG file will now require (number of combinations) * 1kb of package space. If we add a new brand color or skin color, that number grows immensely. So we need to make this dynamic.
I wouldn’t be surprised if we see more work in this space moving forward. Illustrations are traditionally such a big operational lift, so any automation can go a long way. This work is a great first step, and I think so much more can be done. I’d love to see SVG leveraged for dynamic composition and configuration of modular “illustration parts”. While it likely can’t work for every illustration style, there’s nothing stopping select styles from being as modular as any other UI convention.
In the world of user experience, if everything is deemed important, then effectively nothing is. Carousels, while seemingly convenient, often compromise the clarity and effectiveness of your website. Prioritizing purposeful clarity and intentional user engagement over flashy features significantly enhances the overall effectiveness of the digital experience.
If there’s one thing I could accomplish in my professional career, I wouldn’t necessarily want it to be the extinction of carousels, but I’d nonetheless be quite proud of the accomplishment. As the article title suggests, carousels don’t work. Unfortunately this post doesn’t provide any hard evidence towards it’s assertion, but don’t worry, it exists.
I understand that carousels are the UI manifestation of corporate compromise. And for that reason alone, much to my chagrin, they’ll exist in perpetuity. But a boy can dream.
If you’re making something weird, you need to have a very good reason why.
I’m all for weird, believe me. There’s just a time and a place for it. I’m a big believer in personal projects as they’re ideal for weird. In fact, I’d go as far as to say a personal project should be a little weird. But weird becomes a little less desirable once we’re talking about products with a large user base who are relying on it to work. If you’re willing/able to do the upfront work to test/validate/iterate, then by all means, let the weird-flag fly. But otherwise, maybe follow existing conventions and save that idea for a personal project.