I was recently interviewed by
Lovers Magazine about what led me
into design and what type of things inspire me as a designer. I think it was refreshing to answer their
questions and really dive into the deep end of what ultimately took me where I am today.
I spent all my childhood in art galleries and observing my parents create, so you could at least partially
blame this creative environment for the initial spark.
I sometimes tend to forget that I’ve been working in this profession for two decades and many of the people
I meet inside and outside of work are just starting their careers. I’m not really saying that I’d be
offering any kind of career advice in this particular interview, but it’s still a brief look into one
person’s journey to become a systems oriented designer.
We’re excited to announce the first major release of
Nord Design System, v1.0. With this release, our design
systems team is shipping a number of new tools and features to improve the experience of designing,
building, and shipping products at Nordhealth.
Providing a good developer experience is very important to us. Developers should be able to start using our
tools in minutes, not hours, days or weeks.
Looking back in time, we started our design systems journey at the
end of 2020 with initial user research, but the concrete
design and development work on the system didn’t start before the late summer 2021 when
Eric Habich,
Nick Williams, and
David Darnes joined the team.
Now, 8 months later, I’m excited that we’re launching
Nord Design System and all of our tools for production usage! To
learn more about the new features included, keep reading below. 🎉
Why does it feel like the devices we use are getting slower over time? A smartphone I bought a few years ago
seems to be losing its edge when browsing websites. My computer struggles to play audio. Even my car’s
interface can’t keep up anymore after all the updates. Am I just imagining or were they always like this?
No, these devices aren’t actually getting slower, it’s the software that is
getting more bloated. Whenever new
hardware is released out in the wild, it takes only a few months until it becomes the benchmark for software
developers. Because hell, why not. We have all these resources to utilize, why wouldn’t we. Why give a fuck
about the needs of users.
If you’ve observed this too, it’s not just your imagination. Software is becoming increasingly complex and
requires more resources than ever before. As CPU power increases, software is expanded to consume that extra
performance. We live in the era of disposability.
When we started working on Duet Design System early last year, one of
our goals was to create similar component playgrounds as I had previously built for
Vue Design System. While this
seemed like an obvious decision at first, we soon realized that maintaining a code editor of our own
required far too much effort, especially since Duet’s documentation is a custom built platform created for a
specific organization’s needs.
CodePen lets you start a new Pen with code and settings that you send across programmatically. It also
includes a range of options to customize the editor.
We figured there must be a simpler approach. Maybe all of it didn’t have to be a part of the
documentation itself. The most important goal was to have a code
playground which would enable quick prototyping and testing.
This got us thinking. We were already using CodePen when we needed to
quickly prototype or design something in the browser. Could we utilize the same tool for the public website
as well to make the component documentation more interactive?
It’s August, 2018. I’m at the office, sitting by the window staring rain pouring down from the sky. A warm
cup of tea in my hand, about to sip it, but the phone suddenly rings. I don’t recognize the number.
I hesitate for a moment whether to pick it up or not. Maybe it’s again a telemarketer trying to sell me
something?
We had the urge to create a tech-agnostic instead of tech-specific system. A system that is based on web
standards and would survive the births and deaths of JavaScript frameworks.
Thinking of this particular autumn evening today, a year and a half later, I’m delighted I picked up the
phone. This one phone call ended up having a major impact, as the end result was the biggest
personal project I have worked on so far.
While I used to work with bigger clients and projects when we
lived in United States, this felt different. I personally sold the
project and were responsible for most of the things from
initial research all the way to the design
system’s overall architecture.
A few months went by after our first call. I went to see the client during a couple of occasions to plan the
possible collaboration. After some back and forth negotiation we ultimately started working together in the
beginning of January, 2019.
Ever read an article praising design systems and how they magically solve design and frontend challenges?
I’ve sure seen this being repeated in one form or another. Maybe not with these exact exaggerated words, but
the underlying message has been close. While there might be a spark of truth there somewhere, it can be
quite misleading to make this kind of statements without explaining what’s really required.
You can’t just hire an agency to create a design system for your organization and expect that the
system alone will solve something.
You might’ve seen or been on the other side as well, where organizations invest large sums of money to hire
external agencies to create design systems for them. These agencies often work completely detached in their
own silos and only claim to blend into the client’s organization. While this is a good business model for
the agencies selling and creating these systems, it rarely works out for the client organization.
Real life example of this behaviour: a manager at Organization Y hears about design systems and how
they solved the challenges of Organization X. They want to get on the bandwagon as well.
Agency Z sees this as a money making opportunity and sells them a team of designers and developers
who will design and build the system for Organization Y. The starting price is over one million
US dollars.
Vue Design System is a set of organized tools, patterns, and practices that work as the foundation for
Vue.js application development. What initially started as a quick-n-dirty
prototyping tool for a client of mine, has grown into a fully capable systems tool that provides an
environment where the pattern library and live application can be perfectly in sync.
What initially started as a prototyping tool, has grown into a fully capable systems tool that
provides an environment where the pattern library and live application can be perfectly
in sync.
For me personally, Vue Design System has become as much of a design systems teaching and learning platform,
as it is a tool that’s capable of growing from a prototype to a fully fleshed-out system that multiple
applications can depend on.
In this article, I will shed some light to the processes and workflow I use to get started with a new
design system project. An article, I would’ve wanted to come
across when first starting with design systems and trying to figure out the best approaches. While I’ve
written this from Vue Design System’s perspective, the concepts and processes I introduce here will work
with any tool.