Embodying a service-oriented mindset, proactively reaching out to teams, and being genuinely kind and curious are critical muscles for design system teams to devleop [sic].
It’s frightening that this far in the growth of this practice that people need a reminder to talk to the people using the system. Our job isn’t rocket science. Talk to your consumers. Ask for their feedback. Address the feedback. Yes, there are cases where reality is more nuanced. No, it’s not a 100%, slam-dunk approach. But in my experience, it’s the way to go for the vast majority of cases.
Don’t overthink things. Talk to people. Ask them what they need. Then do that.
After a few decades of watching this kind of knowledge slip from organizations’ grasp, I’m getting a little discouraged. Ever since I discovered Doug Engelbart’s proposals for collaborative knowledge work in the mid-1990s and the existence of the field of knowledge management shortly thereafter, I’ve been waiting for (and doing my best to model) better knowledge-capture and -sharing systems.
I’d give my left pinky finger for a dedicated content designer on my team. Content design is so undervalued in the industry. But I consider them a powerhouse on design system teams. This article points out something I’d never thought of—that they’re also oh-so-great at forming the internal narrative and information flow. Now I think they’re even bigger powerhouses!
Copying is fundamental to design, just as it is to software. The rise of permissive licenses and version control tools makes it seem like copying is a new idea, an innovative approach in an industry that thrives on novelty. But the truth is, copying has informed art and industry for thousands of years.
I have an ambivalent relationship with copying because so much of my point of view is wrapped around the intent behind it. I copy, you copy, we all copy. But one can copy to derive something new, whereas another can just brain-dead, mouth-breathing, carbon copy. And that’s a problem because it’s propagated/perpetuated so much crap.
Copying is rampant in design systems. One could argue its benefit to further standardize interface patterns. I say pfft. I’d argue it’s done more harm than good by, among other things, adding fuel to the fire that design systems aren’t “innovative”. Honestly, I don’t know what that means, but I know it’s not meant as a compliment.
…generally taking the following simple steps will suffice.
- Take the cheaper faster option.
- Take the cheaper faster option.
- Goto 1.
No one is ever going to curse your name for whipping up a quick fix. You’ll be the star of the show by making the latest problem disappear with your slapdash hack. It’s all unicorns and rainbows and love-fests… Until it’s not.
Our current generation of software is, to put it lightly, not great. There’s a lot that goes into why that’s the case, but a substantial portion comes down to chronic myopic decision making. Quality does not come from choosing the cheaper/faster option. But it often makes you popular in the corporate setting. And that’s why it’s so prevalent.
I think a lot of it comes down to simply not understanding how a few short term decisions can snowball into a Death Star. Which is a perfect segue to the next article…
One of the biggest challenges to recognizing an exponential trend when you see one is that they always seem to be underperforming compared to the more incremental, linear trends that more traditional businesses rely on.
That’s the problem about just adding one more thing… In a system, it’s not one thing. That one thing connects with all the other things and gets incredibly complex incredibly fast. Much of the disconnect between design system teams and consumers of design systems is this disconnect. Consumers see a simple linear request for a minor addition. System designers (often implicitly) see an exponential explosion in the making.
Writing docs first can help you iron out implementation details ahead of time before making tough calls about implementing a design. Even reference APIs can help you make a lot of designs.
API design is design. I’d go as far as saying it’s some of the most critical design in a design system. I don’t think this is a prevailing opinion in the design systems community, but I hold it nonetheless.
This is yet another opportunity for me to soapbox on the importance of documentation. If you don’t buy into the value of documentation for those reading it, then perhaps this article will shine a light on the value it brings just from the act of writing it.
The reason the persistent and the obstinate seem similar is that they’re both hard to stop. But they’re hard to stop in different senses. The persistent are like boats whose engines can’t be throttled back. The obstinate are like boats whose rudders can’t be turned.
Design systems require persistence. It’s typically not the well-worn, easily-trodded path within companies. Funding will be lost, secured and lost again. People will not understand the value, no matter how much you evangelize. Folks won’t want to use it for a myriad of reasons—some good, some maddeningly not.
Persistence is crucial. But obstinance—or to be fair, too much of it—is a death-sentence. The author does a good job delineating between the two.
These models we construct out of intuition and habitus allow us to mentally simulate situations. And out of these simulations, understanding. From understanding, empathy.
I see design systems as a tool, but a unique one. It’s not just a functional tool, it’s also paired with human knowledge (best practices, usage guidelines, etc.). I’d go as far to say that it’s the human knowledge which makes a design system—otherwise the tool is just a UI component library.
This article isn’t about design systems, but it does speak to the value of human understanding. Ultimately that’s what attracts me to this field. Sure, a lot of the work is about cranking out UI components, but the important work is defining a human point of view on how to best use them.
Outcome-driven strategy is about defining a desired state for your target market (vision) and the actions needed to realize that state. Unlike results-driven strategy that optimizes for extracting value from the an existing state, outcome-driven strategy is about creating a demonstrable change to the way people think and behave to manifest that desired state.
Design systems are a long game. While many in software think in quarters, design system teams need to be thinking in years. I understand and value OKRs, but the author does a great job articulating their weakness. Yes, it’s valuable to have short-term goals, but they need an ultimate destination out in the horizon to be pointing towards. Without that, you’re just myopically bean counting.
A decent amount of this talk, while interesting, isn’t necessarily relevant to design systems. But the heart of the talk does a great job articulating just how much of a mess we’ve made in the world of software. Unfortunately it doesn’t provide a ton of detail on how to fix that mess, but that may be asking for too much.
It is to our benefit, and to the benefit of our industry and society at large, to advance mental models that reflect the reality of our work and honor its essential creativity.
Much to my confusion, I’ve heard that developer experience has recently become a four letter word. Which is strange because it’s two words and has much more than four letters. People are pitting DX against UX, which is also strange because developers are users. So, if you care about UX, it seems like you’d care about DX. But I digress…
There’s a lot to glean from this article and one could quite easily replace “Developer” with “Designer” and collect the same value. I know speed and efficiency are all the rage nowadays. I’m just as guilty, if not more, of fanning those flames. This article touches on a subject I’m beginning to noodle on in my head—that yes, reusable code speeds things up, but a huge drag on productivity and quality of work is the constant distraction of today’s work culture.
I’m not planning to abandon design systems, but I could see myself dabbling in ops to tinker in that headspace.
The details are not the details. They make the design.
First off, that quote isn’t from the article, it’s from Charles Eames. But it’s a damned good quote and on topic.
This article also has almost nothing to do with design systems. But, I think it’s a great example of the level of detail design systems should strive for. No, most feature teams nowadays don’t have the time to ruminate on the nuances of a progress bar. But design systems can. They can sweat these details and subtly, yet profoundly improve an experience.
Sweat them details. They matter.
I think there are whole categories in business like this, where some of the world’s greatest geniuses have solved extraordinary engineering problems but have completely failed to take the psychological component into account.
Design systems are 20% design, 20% writing, 20% engineering, 40% sales and 100% psychology. That adds up, right? Jokes aside, this is such a worthwhile article to read as it articulates that all the academics of system design don’t matter if you can get people to use it. And getting people to use a design system has everything to do with understanding human behavior.
I have no doubt the Figma 2024 preview reveal was great for many people. What I saw was loss of focus. I see more attention and talent spread across more features that have increasingly less to do with the core experience.
I’ve used this metaphor a million times, but I want my hammer to be the best tool possible for driving nails. I don’t want it to cut wood. Figma continues to sprawl while there’s still so much room for improvement in its original purpose.
I also want to acknowledge that I’m weird. I frequently spend more money on things that offer less. I am not representative of Figma’s consumer base and they are, after all, running a business. It may just not be the tool I reach for on my own time.
System designers require more tools like this. I don’t think this is the ideal form, but it shows hints. How do you design a system without seeing how a decision propagates and impacts the entire system? This is the space I hope to see more peeps exploring. I think we should be designing less individual doodads in a silo and more overarching rules/models at a higher vantage point.
There’s a “stability vs innovation” dynamic that can sometimes feel like competing tension, but what we’ve found is that is that stability and innovation are more complementary than competitive.
You can innovate without a stable foundation, but not over a sustained period. Not continually. That instability will stifle progress harder and faster than you can imagine. I’ve seen it too many times first hand. A culture of innovation depends on a strong foundation.
I like this video because I think it’s a great example of lauding flexibility in a clearly constraint-based system. Their dashboard typography has infinite options…all using one typeface. And don’t get me wrong—constraints are totally my jam. Sometimes I think system designers try to overcompensate in their communications around constraint. Instead of hemming-and-hawing about what they system doesn’t allow, I’d take a cue from this video and focus on what it can do.
Let’s say you were employed as a CTO behind the front lines and you wanted to destroy productivity for as long as you can without getting caught. You can of course make a series of obviously bad decisions, but you’d get fired quickly. The real goal here is to sap the company of its productivity slowly, while maintaining a facade of plausibility and normalcy. What are some things you can do?
This is another one of those not-design-systems articles that could easily be discussing design systems. I think the real value of a design system is the behavioral change they typically create once fully operational. And a lot of the points for tanking productivity are typically addressed once that behavioral switch is flipped.
Content is one of, if not the most undervalued element in a design system. This video is a bit of an oldie (in Figma years) but a great case study for how content standards can be integrated into not just a design system, but a Figma library.
The implementation details may be slightly out of date, but the core idea remains just as valuable. It’s a must-watch.
Even though writing styled-components with bespoke CSS over and over was really slow and led to literally thousands of unnecessary lines of styling, it had one major benefit: people could easily try stuff.
I think some people forget that actual people need to be able to use your design system. Many of those people are not Figma/CSS savants. It’s incredibly important to remember that a system that isn’t approachable isn’t used. I’ve seen some design system wizardry in my day and a lot of it was too damned clever for its own good. Fancy is fun and it’s great to nerd out on theory, but bias towards simplicity and approachability.
Today, color modes like dark mode and high-contrast accessibility mode are table stakes in design systems. So, if you’re picking colors manually, you have to pick an additional 50 colors for each mode, carefully balancing the unique perception of color against each different background.
However, with the functions-and-formulas approach to picking colors, we can abstract a color palette to respond to any background color we might want to apply. Let’s go back to the lightness formula we used in the previous palettes:
Find a comfortable place to sit before you open this link because you’re going to be reading for a while. I’m not a fan of color—there, I said it. Working with color is increasingly demanding a PhD in mathematics. And while I’ve written a line of code (or 90,000) related to color manipulation, it’s just getting increasingly complicated for diminishing, if not questionable, upside.
However, unpopular opinions aside, Matthew does a great job in this article outlining the state of color in today’s practice. My biggest takeaway from this is that our practice is firmly in the “messy middle”.
Consider the overlaid promotions, tips, or call-outs typically found in an interface. To get these elements noticed, designers will apply contrasting colors, shapes, fonts, and more. All in an attempt to make things pop. But if a pop-up or any element of a user interface for that matter looks too different from the rest of the design, people will often perceive it as something that doesn’t belong (like an ad) and dismiss it.
Imagine if this is accurate and all that additional work people do to diverge from a design system actually performs worse… Imagine how much of a lose/lose scenario that would be… I’m all for going outside the bounds of a design system, but at the very least have some evidence that it’s worth it.
A final use case for leaning towards novelty over familiarity could be when exploration or surprise is the desired outcome. This might involve leveraging novel interaction patterns that will stand out and make the experience more memorable. Non-conventional techniques such as scroll-based interactions are a way to create immersion and engage users through richer engagement with content.
There’s a direct corelation between the first article and this article. Yes, novelty is helpful when trying to generate surprise or a memorable experience. But here’s the question that’s often unasked, “Would the person experiencing this consider it worth being memorable?” Of course the people making the experience want it to stand out so people take notice. But when everything is novel, nothing is.
Having an established process allows heterogeneous teams to work in tandem. From a business perspective, it also helps mitigate risk—since decisions tend to be more thoughtfully documented and consistent. Even when something goes wrong, having a set process allows teams to understand where things derailed so they can course-correct faster.
Design systems and process go hand-in-hand. Both work towards the goal of standardization so that large organization don’t devolve into a puddle of goo. I have a hypothesis that you can predict how an organization will respond to design systems by how they respond to process. If every team has their own bespoke way of working, there’s a good chance that design systems will be met with skepticism.
But just like design systems, process doesn’t need to be stifling. If wielded deftly, it can become a common language for people to rally around.
When implementing components from a design system, consider developers’ familiarity with plain HTML. By adhering to the principle of least astonishment, ensure components behave like native HTML elements, making them intuitive and easy to use.
First off, today I learned about the Principle of Least Astonishment—which is awesome. I quoted this sentence because it encapsulates part of what makes design system so hard. I think we all agree in theory about the principle of least astonishment and naming things to be intuitive. But what happens when different platforms all have different names for the same thing? Do we have separate names for each platform? OK, then what about Design? Do we give that another name altogether?
Design systems get stuck trying to make order out of an incredibly chaotic and fragmented landscape. Astonishment is a frequent occurrence.
Like so many performance indicators, adoption has been a popular metric because it is easy to measure and easy to understand, making it ideal for reports to executives whose buy-in we need. Adoption is also an easy-to-impact metric because it can be pushed as a mandate, making it an even less reliable indicator of a tool’s ability to drive bottom-line value.
Easy to measure? Now I just feel inadequate. I’ll be the first to say adoption measurements will be an eventual pain in our collective butts. That it’ll be the thing that a very nuanced subject gets dumbed down to. And then I’ll still be the guy that advocates measuring it. Because it’s incredibly useful.
I agree that a design system’s impact on efficiency is a much better indicator of value. But adoption is also really important—because it’s going to help you understand how much the company can leverage the system to make widespread adjustments/improvements. Want to redesign your app? The level of effort could differ by orders of magnitude based on the level of adoption.
Adoption as a metric is flawed, but so are plenty of valuable things. I don’t think we should throw the baby out with the bath water.
I am not linking to this article because I believe this particular study is valuable in relation to design systems. Instead, I think it’s something we should see more in design system documentation. We need more science!
Why would we ever need more science you ask? Surely, the vast majority of people will not read through the study. To which, I would agree. The reason why I think it’s valuable to have research findings in documentation is to validate beyond as many decisions as possible with objective, unbiased research.
It’s incredibly hard to get large groups of people to swim in the same direction. Especially when it’s one opinion versus the other. If we’re expecting people to follow our best practices and use our patterns, the least we can do is offer proof that they work.
…a concrete definition of UI density: UI density is the value a user gets from the interface divided by the time and space the interface occupies.
I’m not sure I’m fully bought in to what where this article landed, but I like the idea behind it. I do like two specific things however: 1. I like the attempt. While I’m not so sure about the final definition, I think having something like this could be valuable. 2. I definitely like the idea of pumping as much meaning into an element as possible. Think of a nutrient-dense vegetable versus a cracker. Design system components should aim to be the vegetables of UI modules.
Reading in the classroom has moved away from encouraging students to dive into a whole book and moved toward students reading excerpts and responding to them. ‘Even in elementary school, you read, you take a quiz, you get the points. You do a reading log, and you have to read so many minutes a day. It’s really taking a lot of the joy out of reading.’
You may think this article is completely unrelated to design systems, but you’d be wrong. Experts hypothesize that kiddos aren’t reading as much nowadays because the reading they’re assigned is joyless. It would be lovely to verify this hypothesis, but I’d say there’s serious merit to this conclusion.
How many times have we heard people don’t read documentation? A lot. But guess what, documentation is often written as though it’s intended to be a sleep aid. Yes, documentation needs to be clear and concise, but it doesn’t need to actively avoid being fun. People like fun—so add some fun into your documentation.
But once you view debt as narrowing what you can endure in a volatile world, you start to see it as a constraint on the asset that matters most: having options and flexibility.
I’m allergic to debt. All debt. Debt takes your hands off the steering wheel. We all hear tech leaders talk about the importance of velocity. However, I’d wager to say what they really want is agility. And debt absolutely obliterates agility.
Yes, design systems help teams move with greater velocity, but more importantly, they enable agility in two ways. 1. They reduce UI tech/design debt. It’s hard to overstate just how much tech debt can limit options. 2. Design systems enable macro-level changes in hilariously/frighteningly little effort. A color palette change or icon redesign can be a herculean effort without a design system. With a design system, rollout can take less than a day. Minutes at best.
Moving fast is great, but changing directions (without the gLoc) is perhaps the least understood value systems bring.
What you don’t see is what people in the past were more able to see. When you are in groups, you can be very powerful. You can change things. You have confidence when things go wrong that you don’t when you’re on your own. That’s why the whole concept of power has dwindled. We’re encouraged just to talk about ourselves and our feelings towards others. We’re not encouraged to see ourselves as part of anything.
There’s a lot in this article that’s tangentially related to design systems. I think the crux of why folks buck the idea of design systems is that it’s disincentivizing individual expression. Design systems think of people in groups which is in direct conflict with the world view of design system consumers.
I’ve come to the conclusion that 80% of design systems are about getting people to work as a group—whether or not they’re aware of it. And, boy is that hard.
So you see that there’s a good reason why many typefaces are not as legible as others. It’s simply not what they were meant to be – and that’s a good thing. We should have many more typefaces that are playful at the cost of being harder to read. But not in user interfaces. There, we certainly don’t need typefaces that are harder to read than they have to be and that have no personality on top.
This is a great post to read if you are one of the lucky few who have a say in what typeface is used in your design system. There’s plenty of chatter about stylistic choices of typefaces, but not enough about how to impact legibility.
It’s time to embrace wearing the marketing hat. By proactively raising awareness, building advocacy, and proving impact, you’ll transform your design system from a helpful utility into an indispensable centerpiece of how your organization crafts amazing digital experiences. The work won’t always be easy, but the payoff of an enthusiastically embraced design system will be well worth the effort.
I’ve spent the last eight or so years selling design systems. There isn’t a person around who’s more understanding of the importance of marketing. But… Marketing can quickly morph from a means to an end to the end-all. Yes, promoting a design system’s value is critical, but don’t forget that you ultimately need to deliver something worthy of promotion. It’s just too damned easy to get a taste of what good marketing can do and lose sight of the actual job.
Complexity signals effort. Papers with difficult ideas and technical details suggest blood, sweat, and tears. Systems with more components and features hint at more effort than systems with less. Because complex artifacts are viewed as requiring more effort, they’re also deemed as more challenging to create and thus more worthy. And because of the perceived effort involved, they’re often judged to be higher quality.
Man, this is a good writeup and it does a great job encapsulating how organizational dynamics make simplicity hilariously difficult. Complexity often looks impressive at first glance. Given many organizations don’t have time to devote towards a topic more than first glance, things all start to make more sense.
Simple looks easy. And easy doesn’t make people look smart.
…polish is something only the person who creates it will notice. It’s a paradox; polishing something makes it invisible. Which also means that pointing out examples of polish almost defeats the purpose.
This article is covering an important topic, but I just wish it was less highfalutin in how it discusses it. I’m not so certain all polish is invisible. I think polish is often easy to detect, but hard to isolate. But you know what’s really visible? Something that ain’t got no polish.
I’d argue that polish is not as invisible as it’s amorphous. Right up there with “craft”.
For us, writing equals thinking. And it’s a big part of how our team has worked. What was different about it this time was that we were sharing our work (what we wrote) much earlier. Because we found so much value in it, we’re now writing documentation earlier in our design process.
I don’t have any direct knowledge or experience with the Spectrum Design System, but I’ve been truly impressed with everything I’ve seen and read from the outside. The scale of Spectrum is bonkers—some of stats I’ve heard thrown around sound like video game numbers. I’d expect that scale to weigh the quality down, but that doesn’t seem to be the case here.
And I wonder if this article provides a small window in why that may be the case. It ticks a lot of boxes for things I have seen work—customer-focused thinking, documentation-driven design, sharing early and often. Kudos to team Spectrum, they seem to have a good things going.
Recipes serve as an important pressure release valve for the natural tension that arises between a design system and the products it serves. A recipe layer gives product teams the autonomy they need in order to make the best products possible while still working with the grain of the core design system.
I am a big fan of recipes, especially the “Compositions of design system components” variety. I’m such a fan, that I think all recipes should be collected/socialized within design system documentation. And if not directly in the documentation, directly adjacent to documentation. This is something I plan to noodle on in the future.
And on the subject of recipes, this is a lovely example of just that. I see no reason why a design system couldn’t have an equivalent bank of ready-to-use compositions that aren’t components (yet). Throw in a code view for engineers to yoink from and you have a really helpful resource.
Juice can add soul to software but is mostly absent. Because we underestimate how much feelings influence our lives. Even the definition of Juice states it’s non-essential. It is non-essential to functional requirements, but not to emotional. Emotion is essential to being human. It’s why music exists in every culture in the World. It’s why some of the great works of humanity are artworks. Not because of their function, but because how they make us feel.
If there was ever an ideal location for Juice, it would be a design system. The author makes a strong case for the value of adding juice to enhance experience, but it can go off the rails extremely fast. The magic about juice is that a little goes a long way. And that little amount needs to be the same flavor. Pineapple juice mixed with tomato juice ain’t going to delight anyone.
A design system can help direct, focus and regulate how much juice gets dispensed. And that’s a very good thing.
Big, flashy things get noticed. Quiet, boring things don’t. A lot of design system work is the exact opposite of glamorous, and this effort is no exception.
Boring things make the world work. Bridges, sewers, and design systems. The world would look significantly different if human psychology could maintain the awe of running water. But we don’t. This article has some interesting ideas on how to quantify the unnoticed value of design systems. But ultimately, the author lands in the same domain of fuzzy math that so many of us reside.
Design teams often follow these isolating practices despite strong indicators that successful digital products are made by teams that are deeply integrated with engineering. Not to mention, this waterfall approach to design slows down the work immensely. This is quite the paradox — one might wonder what design teams are spending so much time on that justifies being so detached from the technology they’re designing for.
There’s a lot to pull from this article, but the above quote is an important one. I marvel at the fact that it’s 2024 and the gap between design and engineering remains. I don’t think it’s going away anytime soon. However, I don’t see that same gap in design system teams. Which is why, among a slew of other reasons, that I think design systems are going to come out of this market correction stronger and with more influence. Even if we make boring things.
And no, it didn’t get past me that this article directly links to a super interesting critique on the harmful effects of design systems. I’ll probably write about that in a future week.
We’re pitching the value of a design system as a time-saving, plug n’ play collection of LEGO bricks when we really should be pitching the Building Instructions instead. You know, that little booklet that comes with all the cool sets that shows you how to build the thing step by step?
I once said that design systems are like legos, after you connect the pieces appropriately and then super-glue them together. Yeah, that’s definitely on one end of the spectrum of views, but I still believe in it. Yes, it’s nice to have some stray pieces in the box to deal with what comes up. But the core pieces were put together for a purpose. And that purpose was not to disassemble and make something else altogether. Why include building instructions for something already built?
[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 influence 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 vacillate 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.
Edit: It’s worth noting this post was inspired by Robin Sloan’s preceding thoughts on the subject.
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.