Last year I made a calculator using modern web components in Javascript. I tried to replicate that in Figma today and found this.

Play the prototype here: https://lnkd.in/ek_ekZm7

1. Using variables, I can update the display of the calculator after a button press. I can also use conditionals to add some logic and make sure the displayed operations seem valid.
2. I was not able to do the actual calculation! There might be a way to do it with more time or a plugin, but I left it here since I wanted to keep things simple for now.
3. It took me a lot of time to setup the required variables and conditionals. Writing code, or copying and pasting code snippets is much, much faster compared to the tedious process required to prototype in Figma.
4. Figma is still missing basic concepts like functions, arrays, and loops. With those, making a calculator would become much simpler. It would also add capabilities like repeating lists of UI elements to make a todo app, a webshop, dashboard or any other advanced application. It amazes me that Figma still does not have a repeater grid like Adobe XD!
5. While variables and conditionals are now available, their implementation is still quite simplistic. We can’t nest conditionals, or just combine more than 2 cases in a conditional. I also found that string variables cannot contain any special characters.

There will undoubtedly be many more limitations like these, since Figma decided to build their own ‘programming language’. It still lacks a lot of capabilities that more popular and mature languages like JavaScript, C, or Python already have. It makes me wonder why Figma even decided not to use any existing language.

I will also predict that we will see much more advanced and amazing prototypes made by designers from now on. All kinds of simple games, text input fields, or animated effects can be made much more quickly. But because of all the limitations and the time and effort it takes to use the new prototyping features, it’s still very valuable to create prototypes with actual code or learn how to prototype together with developers.

Designers will also have a hard time keeping track of all the options and features that Figma offers. I can’t wait to see how the AI mentioned by Dylan Field at #Config2023 will help designers with this in the future ;)

P.S.: Take a look at the working calculator built with actual code here: https://lnkd.in/ei3B798H

Figma variables and conditionals: a reality check was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

For years I have been a proud user of Figma. Proud because it made me a better designer. Proud because I helped others become a better designer with Figma. But also proud because Figma made me independent.

If you have been in design for a while, you might remember the days when we used to design for web in Adobe Photoshop. Or Adobe Illustrator or Adobe Indesign, if you thought that worked better. You might also remember how hard it really was to use those tools for UI design, and how hard it was to get rid of them.

For a while, most of us adopted Sketch: A bold newcomer that broke the market for UI design tools wide open. And its plugin system opened up the space even further. But Sketch also had its limitations: mainly being a mac-only single-player tool.

The dawn of Figma meant that we could work across platforms with multiple users at the same time. It was scary at first, but Figma proved that it was both possible and reliable to work on the web in multiplayer mode.

Fast forward to 2022, and that very liberating tool is now being bought by the company that limited us as designers for so many years. It’s only logical that we are all upset, and maybe even a little bit scared for what is to come.

But there is reason to have faith in a positive future, and I will explain why.

Adobe has promised to keep Figma autonomously

We all know what happened to Flash after it was acquired by Adobe. The tool, once loved by users, designers and developers became a monstrosity that was eventually killed off.

However, I would like to remind everyone that ultimately it was Apple that killed Flash, for security reasons that existed long before Adobe acquired Flash. It was doomed to be killed off from the very beginning, and if you knew anything about the web you could see that coming.

Figma is not like Flash. It doesn’t have security flaws like flash, or the need for manual updates like Flash.

You might say that Adobe already has a UI design tool, directly competing with Figma. Would it be logical for Adobe to keep both tools separately? At this moment, we just don’t know. Adobe might as well give Adobe XD a different purpose, making it complementary to what we have in Figma now.

Moreover, Adobe has voiced its intention to keep Figma. Quoting Dylan Field, founder of Figma: “Adobe is deeply committed to keeping Figma operating autonomously and I will continue to serve as CEO.”

Figma will keep working on great new features

An organization like Figma is always working on new features to keep cutting the edges of innovation. That means that we will probably be seeing great new features in the near future, maybe even before this acquisition is completed.

If you follow some of Figma’s Figmates on Twitter, like disco_lu or miggi, you know this firsthand. These amazing people are always on the lookout for customer feedback, trying to find ways to improve Figma with new updates and features.

We also know that Adobe has a lot of capabilities that Figma currently does not have. Like rich photo-editing capabilities, advanced illustration features or intelligent image prediction. Some of these capabilities are already possible through plugins. But with Adobe in the mix, we might see these capabilities getting integrated in a better way.

Figma might not be acquired by Adobe after all

The merger acquisition that has been announced today is definite, but it is definitely not a done deal.

In the past, we have seen many of these mergers that were not followed through for various reasons. The most (in)famous being Twitter not acquired by Elon Musk, because of doubts about the number of real Twitter accounts.

But there was also Facebook forced to un-acquire Giphy because of possible harms in the market, and Zendesk terminating its SurveyMonkey acquisition after its own investors rejected the deal.

There could be various reasons for Adobe to not see through with their acquisition of Figma. They may find that the community backlash will be harmful to both Figma and Adobe.

Adobe shares have already plunged after the news that Adobe will acquire Figma. Adobe's remaining shareholders may try to stop this deal just as well.

And finally there is a possibility that government watchdogs will stop this deal. The market for UI design tools is not awfully big. With Figma being market leader, and Adobe already owning not one but three major tools in the market, Adobe might become too big of a player in this market.

Conclusions

To summarize, there are a lot of possibilities for the future at this exact moment in time. Figma might stay separate from other Adobe tools, or it might become Adobe Figma CC. There might be a lot of great new features, or a lack of new development. And to top it off, Figma might not even be acquired at all.

But tomorrow, you will probably still be drawing rectangles in Figma. It’s what you have been doing earlier this week, and you need to get that project finished before next week. So you’re definitely not going to switch back to Sketch halfway.

And 10 years from now, you will probably be working in entirely different tools. AI is already reshaping design tools as we know them, and it’s very much possible that it will also reshape our jobs in the coming future.

So let’s not worry too much about today, wait a bit and see where this is going. Then we can all decide for ourselves, and keep making amazing designs.

Do you have some thoughts about this acquisition as well? Leave a comment here and let’s discuss.

Keep calm and Fig on was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

There are two kinds of prototypes in this world:

Low-fidelity prototypes like sketches, paper prototypes, and wireframes. These are great for quickly communicating and validating ideas. But outside of the design studio, out in the real world, where concepts need to prove their worth, they often fall short.

High-fidelity prototypes like clickable mock-ups, coded experiences, or even a complete MVP. Combined with realistic mock data, these prototypes can validate successful business concepts. But in practice, they take a lot of time to create and risk increasing time-to-market.

What if we could get to high-fidelity prototypes faster?

Building a design system

Design systems are basically like lego blocks, allowing you to play and build quickly. At Metrixlab, where I work, a design system was initially needed to make things more consistent: The eco-system looked horribly inconsistent before I created the design system that is now used across applications.

Very often design systems are created in a pre-mature phase. This results in inconsistent UI and static documentation that needs to be updated manually. The key to success is to automate as much as possible so the workload is reduced, adoption is increased and focus will shift to design system government. I learned this the hard way myself, but John Gully and Marcello Summers created a excellent maturity model to showcase this.

So instead of focusing on getting from design to code, I decided to put my initial focus on distributing code. I created Angular components with automated documentation in Storybook and distributed the components with NPM so applications could be updated automatically. (The components live in Figma as well, but separately.) Surprisingly, this taught me how to prototype faster as well.

Of course, you don’t need to build your own design system for prototyping. You can use any existing design system like Bootstrap, Material Design, or Tailwind CSS. At Metrixlab, we chose to build our own design system so we could tailor it to our specific needs and brand. If you choose to use any existing design system, just make sure that it supports advanced interactions based on mock data that feels real.

Query builder

For example, I collaborated on designing a query-builder interface in Figma. It needed advanced functionality like if-else conditions, logical operators, and nested groups. After countless iterations on the most arbitrary details, I was noticing that the designer and product owner I worked with were mostly telling how things should work, rather than showing how they could work. That didn’t help, of course. We ended up going in circles, being misaligned, and not being able to validate with real users.

So I made the decision to leave behind Figma for this particular feature, and start prototyping in Angular. Besides a small challenge on the drag and drop, prototyping in code was almost as fast as prototyping Figma with our Angular design system. The major difference between Figma and code was the lack of limitations in prototyping.

We succeeded in implementing drag and drop, which made us experience things like we couldn’t before in Figma. We also mocked up some realistic data, which helped the product owner experience the prototype in a more realistic way. She could now feel like she was really building an advanced query that hadn’t been possible before in Figma. Soon, we found ourselves trying out the prototype with real users and got much better user feedback than ever before.

Survey builder

Besides the query builder, I also worked on a design for a new survey builder together with the same designer and product owner. The new survey builder had to be much more intuitive compared to its predecessor, so betting on a new design was hard.

When we started, I hosted a sketching session with the product team. Everyone contributed and we were able to get a consensus. The designer on the team then created mockups, which the product team implemented.

But after implementation, we found a problem. One group of users complained that there was no space to see the questions and answers together on smaller screens. This was partly because the mockups did not consider small screens, and partly because of how the product team interpreted the intended scrolling behaviour.

At first, the product team did not prioritize this feedback. They were focused on other, more pressing issues, and told the users to just ‘zoom out in the browser’. But when a second user group complained about the same issue, the launch of the tool became dependent on a solution. The product team then requested a design for some space optimizations.

I had been bothered for a while by the issue, and the decision not to prioritize the user feedback. So when the request finally came in, I was very eager to help with a redesign.

But I also knew that it was very important to get the implementation right this time. We couldn’t afford any more flawed interpretations of the design. Because the product team had been holding off on a real solution before, time was pressing now.

So instead of making more mockups, I opted for creating a front-end prototype as well. This front-end prototype could present the intended scrolling behaviour more realistically. And I also added some other improvements to interactions that had been disturbing me, without leaving room for false interpretation.

After the redesign, the questions and answers were visible together on smaller screens, and users loved it.

Take-away

These were just a few examples of how a design system can boost your prototyping. But the possibilities are endless as you can leverage native technology and create your own components. Of course, as a designer, you don’t always need to create these prototypes by yourself. You can team up with engineers to create the prototype with you and learn together. I’m also not advocating to ditch Figma or similar design tools. I find myself switching between Figma and Angular code a lot to quickly explore the look & feel before creating any hi-fi prototyping.

My next goal is to learn how to scale this approach across organizations. Many organisations, like Metrixlab, use a Scrum, lean or agile approach and release code to gain insights. But hi-fi prototypes that use realistic data can validate concepts without risking negative user impact. I think there is much to be gained from this design thinking approach combined with design systems and hi-fi prototyping.

What I learned from this:

• Hi-fi prototypes to test and handover design can be created quicker with design systems.
• Designers can do more if they know how to build prototypes in front-end code.
• By prototyping teams will learn that user feedback should be addressed early on.

Further reading

How design systems can help build and prototype better digital products | by Luis | UX Collective (uxdesign.cc)

A Maturity Model for Design Systems | by Marcelo Somers | Slalom Build | Medium

Prototyping with Angular. Since joining Google a year ago, I’ve… | by Edwin Lee | Angular Blog

Design systems: Prototyping on steroids was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

When new designers and developers join forces to evolve your design system it is tempting to start working in projects. You might even create some epics and sprints to move user stories from your backlog in a Scrum environment. But when your design system is not a full-time effort, this will work counter-productive.

Our agency WebNL was growing when we started a design system team. New designers and developers had joined our teams, and we also acquired another UX agency. With this growth came a need for better organising and standardisation of processes and tools.

Our new coworkers started to work on client projects and they needed a well-functioning design system to do that. Ironically, I found that making our design system into yet another project didn’t function well.

Starting a design system team

Last year we started a design system team. Before that, I was already doing solo work to create a Figma starter kit and coded components for our developers and designers. So why did we need a design system team?

Our teams at WebNL are seperated by profession: Creative, development and marketing. Each team is lead by at team lead, optionally assisted by a planning manager.

But we also have project teams. Each project team is led by a project manager and consists of several designers, developers, and marketers. Project teams may also vary across time.

So designers, developers, and marketers have to report to their team lead, but also to a project manager for different projects. Nielsen and Norman Group call this a matrix UX team.

Because of this model it’s challenging for our teams to share resources. We often don’t know what other people are working at, unless we ask them or hear about it in a standup. This results in work being done multiple times.

So we need more standardised components for these teams in order for them to work efficiently, but we also need more eyes and ears in these different teams to know which components they need the most.

But mainly our agency needed more components, more then one person could build and distribute on their own. To generate more components, a project was started.

Our design system project followed the convention of our regular project teams. We needed project management, research, design, and code to create components. So the project was started with a project manager, a ux researcher, a designer, and a developer.

Our first project

Our first task as a design system team was to create a site header and navigation component. The project manager had asked us for estimations and calculated a return on invest based on time saved in future projects. He wanted to use this project as a case to convince upper management of investing in more standardization.

His understanding was that upper management wouldn’t let us work on more standardisation before this project became a success. So we wouldn’t be working on any other components before this project was finished.

Research

As a UX practitioner, I was responsible for UX research. I wanted to move quickly, so I collected different navigation patterns, looked for occurences in competitors websites and our own websites. A week later I presented the results to our team in order to move forward.

After the presentation, I had planned to create guidelines together with our team. This was met with some aversion. We did manage to create some guidelines, but there was a lot of discussion about which variants of a new component would be most important and would be built first.

Design

Then our visual designer went to work. It had taken some time to find time in his schedule between client projects. But two months later he presented a slick clickable prototype in Figma.

The design introduced some inconsistencies with our existing design system. Our visual designer created the navigation component in a new file, with a duplicate of our design system templates. Other designers were starting to wonder which file they should use.

Our visual designer showed that he could listen to designer feedback, implement feedback quickly and understand how systems work. I decided to have my design system files archived and let him maintain the visual part of our design system. This way we made sure that designers knew where to find our design system.

Development

We hoped to start development sooner and have the navigation component in our codebase fast. But it was just as difficult to find time in our developers schedule between client projects. We also changed our asset bundler to Webpack during that time, and we optimized for Google page speed, which also took some of our time.

Two months later, four months after the project was initially started, we still hadn’t been able to find time for the development of our navigation component. In the end, I contributed by taking over development of the component.

I coded the navigation component in Storybook. I would be able to test multiple variations of the component, share the component with my team and have automated documentation. It was exciting to start using this promising tool.

Storybook turned out to be problematic in our workflow. People didn’t understand all the buttons, tabs menus it had. And those people also weren’t used to testing components in isolation.

But more importantly, Storybook didn’t fit in our code stack. We used Vue’s inline-templates to optimize for SEO and compatibility with our backend framework Laravel and our CMS. Storybook did not offer support for Vue’s inline-templates with Laravel, but required single-file-components instead.

I built the navigation component to support both single-file-components and inline-templates. This didn’t work. Having the same functionality in two different places wasn’t scalable and introduced a lot of head-aches. We decided to stick with inline-templates and adjust our navigation component.

Eight months after the project was started, our lead frontend developer merged our code into the main branch of our codebase and the navigation component was released.

Problems with design system projects

When we started our first design system project we estimated a quick release. This didn’t happen, because on numerous occasions our project got deprioritized. As a result the release was rescheduled numerous times.

That didn’t come as a shock to us. Working in an agency we know that client work is always prioritized. We have to move fast for clients in order to deliver. Prioritizing large internal projects over client work is most often not an option for us.

But our design system project becoming a bottleneck was a problem. I wasn’t allowed to do research on new components. And our visual designer had to wait for the research since we used a Waterfall process. Simply because our team assumed that we weren’t allowed to work on new components. I felt that this assumption was wrong.

Earlier this year, I attended a talk by Sander Hoogendoorn, Agile coach, speaker and writer. He talked about agile, scrum and how they fail in a modern-day software development environment. According to him we should STOP doing projects . This message appealed to me, even though I work at an agency where we make money from doing projects for clients.

The solution Sander provided was continuous delivery. This is not a new concept, and it’s getting more attention lately. Especially in DevOps, where launch cycles are mostly automated nowadays. With continuous delivery, features are divided into smaller parts that can be released when they are ready.

The reason why this message of continuous delivery appealed to me was that our design system project became stuck. We had a growing amount of components waiting to be researched, designed and built. Designers outside our team were also asking for new components.

But our resources were limited, our navigation component was too large and our project it was blocking the development of other components. It was clear that projects did not work here.

Improving the design system process

When we started our design system team, I had wanted to establish a design system proces by making a design system process puzzle with our team.

I was introduced to this tool in a workshop organised by Angi Studio, and I had used it to help some students with their design system project. At both times I had been amazed at how the puzzle gave a clear picture of what a design system process should look like.

When our process became stuck it seemed like a great oppertunity to re-evaluate our waterfall/SCRUM process and see if we could gain from continuous delivery, while starting work on more components.

It was hard to find support in our team. Others didn’t see a need to change the status quo, and assumed they were right about following a pre-approved schedule. In order to encourage them I talked to one of our directors.

I had worked with this director on our first design system and knew that he would approve of working on more components if it would help us standardise. When I talked to him about our design system becoming a botttleneck, he recommended scheduling a meeting with him and our team to discuss doing more components.

I used the meeting to do the process puzzle as well. In the meeting I explained how the design system process puzzle worked, and I provided the materials. But the process puzzle was quickly set aside when a lack of general understanding of our existing process became clear.

Some people didn’t know about the release cycle initiated by our frontend developer. Others didn’t know about how the installable packages in our codebase were used to release components. And even others didn’t know about the already existing backlog or our Figma starter kit.

In the end we didn’t do the process puzzle and just discussed how we could get things moving again. The initial assignment for our project manager was extended to include research, design and development of other components. We also decided to collect these components in a backlog and set up a kanban board.

To document these decisions I layed out the process puzzle after the meeting. I did this on a part of my desk were people could see it. This way I got feedback from our team without having to organise another meeting.

Other people in our agency gave feedback as well and the puzzle was changed each time someone walked by. When no more changes were being made, I digitalized our process into a visualisation.

Process visualisation

Our process starts with standardisation by our design system team. We have a shared backlog that contains a list of components that we want to build. These components are researched to generate guidelines, best practices or requirements. Then the components are designed and developed. After each step in our process, we do a review.

The second step in our process involves releasing. During development we need to choose an installable Composer package for each component. The components are then released in those packages by a senior developer.

When a component is released in a package, we can also release the component in Figma as ‘available in code’. We communicate those releases to our design and development team in standups, tech meetings or email.

While the components are being used, we can measure how they perform. We can measure the experience of designers and developers by doing surveys. We can measure the time spent on adjusting components for clients by measuring time logs. We can measure the user experience by doing usability testing, surveys or web analytics. Or we can measure SEO impact in web analytics.

Each measurement can result in a new component request or an update request. These requests should flow back to our design system team.

At the moment we haven’t set up these measurements specifically for our design system. But we are already logging our time, doing usability testing and collecting analytics for clients. These existing metrics could be converted into feedback for our design system team in the future.

Finally we made a Trello board to track progress of these components. This Trello board should be public to everyone in our agency so everyone can make requests on our backlog. In the future we could guide these requests by setting up an automated form with general questions that would then convert any submitted forms into Trello cards.

Evolving process

Moving to a continuous and agile workflow isn’t always easy. Especially when people inside an agency are accustomed to working consecutively in waterfall. For client projects we use scrum and kanban to estimate tasks and log issues, but design and development are often seperated by a waterfall process.

When we came up with new components after our process meeting we prioritized the components. Then our project manager created a new project in which we would do research, design and development in a waterfall process all over again.

When development started, a backender had done some work that we could use. But there was no design for his work. We proved that we could work in an agile and continuous flow by involving our designer and including the backend work.

In other cases priorities change, and we have to abandon a predefined roadmap. Early this year, I encouraged our team to implement Webpack as our default asset bundler. This wasn’t on our roadmap, but we needed it to modernize our codestack and create compatibility with modern front-end tooling.

A few months later this change proved beneficiary to page speed scores on our websites. We were able to make some improvements which hadn’t been able without webpack. This delayed our work on the design system, but by making these improvements we were able to build better components.

A final example of evolving workflows is changing tools. I started using Storybook to build and test multiple variations in components in isolation. I later found Storybook wasn’t optimal for codestack and workflow. But I still needed a place where I could build and test different variations of our component.

That is why I built Storybase. It’s a package for Laravel applications and it is compatible with any html component, including Vue inline-templates. Storybase renders our components on the server so we can optimize them for SEO while testing. It also allows us to mock data in Laravel for each story. And finally each story is also embeddable in our documentation.

When I built Storybase our site navigation component was already in its final development stage. But we started a client project with some snowflake components that introduced a lot of variations. I installed Storybase into the project and documented and tested each component there. This helped a great deal in convincing my fellow developers of the value of such tools. I now plan on using Storybase not just for our design system development, but also for each client project.

Takeaways

• Don’t build your design system in waterfall projects or scrum sprints. It’s simply too big. Establish a backlog with components and make sure the tasks for these components are small so you can work on them continuously.
• Set up a process with your team early on so you can get on the same page about which steps to take before components are released and when to build new components or update older ones.
• Use a tool like Storybook to document and test variations of your components, or create your own tool for this.

Stop doing design system projects was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

Back in 2018, when I started my job at WebNL, I was asked to look into ways to improve the bridge between design and development within our company. I came up with a system that automatically extracted design tokens from Sketch designs and translated them into SCSS variables. This was also our first design system.

For numerous reasons this first design system failed. You can read about how it worked and why it failed in my previous article.

Why design systems fail, and how to make them work

In the article you are reading now I will talk about our new design system at WebNL. It is still about improving the bridge between design and development, but without the complexity of automation and the urge to cut down on time.

Switching to Figma

Our first design system was mainly shut down because we were forced to overhaul our codebase. But there were also a lot of problems that needed to be fixed. So we decided to start from scratch.

We learned that Sketch, the tool we had been using, wasn’t the best tool for building design systems. So we chose not just to start with a new codebase and a new design system, but also with a new design tool.

Figma became our new design tool. It’s great for building a design system because of its component library feature. Components can be shared in a library across design files, and they can be pushed and pulled like code in a version control system. For us this was much better than what Sketch offered at the time, even in combination with Invision Design System Manager.

Also, Figma launched an api that could be used to read their design files in other applications. One of my problems with Sketch in our previous design system was that they repeatedly changed the structure of their api and file system. That required me to keep changing my automation in order for it to keep working. Figma promised to keep changes in their api to a minimum.

I was still concerned with Figma’s performance in the browser though. Sketch was already performing badly with big design files. It could only be worse in the browser, I thought. But I was wrong. Figma managed to make their browser based design tool faster than native design tools, even when multiple people were working in the same file simultaneously.

This convinced me we had to switch from using Sketch as our main design tool to using Figma. But deciding that for myself wasn’t enough. I had to convince my entire team.

My boss was already positive towards Figma, that was encouraging. But our designers liked working in Sketch. They had no reason to switch. Getting them to learn a new design tool wouldn’t be an easy task.

I started by making a roadmap. First, I would start sharing articles and tutorials. Then I would demonstrate how to use Figma in person. Finally, when there would be enough trust, I would ask people to try Figma for one or two projects. It would take me some months.

But after six weeks, everyone had already been convinced. It turned out that when our ux designer had been convinced, the other designers were willing to follow. We made the switch to Figma and I was ready to build a new design system.

Making the switch wasn’t really the end of it though. At first, there was a lot of complaining about trivial stuff like dropping images inside frames, or creating masks. This worked a little different inside Figma and Sketch, which required designers to get used to those kind of things.

By being patient, willing to explain and showing confidence in our new design tool, I tried to convince everyone that there was really no reason to go back to Sketch.

After a while, two new designers joined our team and were able to get used to Figma quickly, while they had also been using Sketch before. This proved that we had made the right choice, and that there were really no big drawbacks.

Researching user needs

I also learned some other things from building our first design system. People using the design system have to be involved often and early on. And besides that, I also learned that our designers didn’t like atomic design or big combined components. A new design system needed to be restricted to small and general components like buttons and input fields.

Our designers had also become sceptic towards design systems because they started to feel it limited their creativity and heightened the risk for errors. But we still needed some kind of starter kit to close the gap with our developers. So instead of talking about design systems, I talked about starter kits, components and documentation. Things that people could actually understand and use.

Around the same time, I went to a meetup at another agency called Angi Studio. They specialize in creating design systems for their clients. They also developed a tool called the Design System Checklist. It originates from an exercise created by Nathan Curtis.

Picking Parts, Products & People

In the meetup, the checklist was used as an exercise. I decided to use it as a survey for our design team, so everyone could share their opionion anonymously. I collected the results and created a combined list of the parts that needed to be in our design system.

The survey showed our designers still wanted templates in their starter kit. I had avoided templates in our first design system, because I wanted to give designers building blocks for their designs. But even these building blocks became too big for our designers to work with. So I was surprised they still wanted templates.

In our new design system, I decided to use both templates and small building blocks. Designers would then be able to choose, or use a combination of both. This way they could kickstart their design with a basic structure from a template, or start from scratch with just some small building blocks.

Building a starter kit

Before I started I knew I would still have a hard time convincing our designers to use the starter kit. They were used to working from blank pages for every new project. Of course they would have to recreate buttons and typography styles for every new project this way, but they simply didn’t care. They were just creating pages.

But when frontend developers see the design, they need to turn it into a system of different components. When a designer doesn’t think about that while creating the design, turning it into a system will be more difficult. So I started with making a styleguide in Figma consisting of basic colors, typography, buttons and input fields already in place as a system which designers could use.

I explained to our designers why other frontend developers and I needed to see a styleguide alongside their designs. They understood they could help us out, and they became willing to use the starter kit in their workflow.

Next, I needed to create templates from these components and styles. From our survey I knew that our designers and frontend developers wanted templates for homepages, product pages, article pages, search pages, contact pages and category pages. Since corporate websites are the kind of work we mostly do, I started with templates for homepages, article pages and contact pages.

Another complaint we had was that websites were always designed for desktop, but never for mobile. Partly, this is because of the way we work. In our company the frontend engineers are responsible for making a website responsive. But sometimes designers and clients have their own opinion about mobile design. So I made sure to include templates for mobile screen sizes as well.

And because corporate websites come in all kinds and sorts, I made these templates as generic as I possibly could. I even used a photo resembling the default background of a well known operating system. But for the webshop templates, like product, category and search pages, I could take a different approach.

Webshops have lots of pre-existing patterns that users have become ‘used’ to. They expect this kind of behavior from a webshop, and deviating from this is not recommended when making an mvp. Because of this I was able to make these templates fairly detailed. Best practices like GDPR compliance could all become pre-fabricated.

When we first used these templates to create a new design for a webshop the results were great. Our designers would normally be able to produce just three or four templates, but we were now able to create four extra pages in the same amount of time. This enabled us to agree with the client on more details before development started.

I also created templates for our dashboards. These templates contain components like tables, graphs, charts, tooltips and modals. The components are build in a way that allows them to be resized easily without breaking constraints.

Documentation in Zeroheight

Before we switched to Figma, we briefly used Invision Design System Manager to write documentation for our designs. Design System Manager also offered an option to convert design tokens into SCSS variables, reducing the need for us building this functionality ourselves like we did before.

Sadly, Design System Manager didn’t offer support for Figma at the time. But this didn’t stop us from making the switch to Figma. I trusted that support for Figma would be coming soon, and if not, some other tool would fill the gap. And I was right. After a few months, we discovered that Zeroheight offered the same functionality as Invision Design System Manager did, but for Figma.

We’re still not using this functionality in Zeroheight though. Because of our experience with our first design system we learned that we weren’t ready for automation yet. In the future we might start using automation again, but not until our design system has reached enough maturity.

Despite this, Zeroheight is really great when it comes to documentation. I used it to explain the styles, components and templates in our design starter kit. And I also used it to document our code with snippets and examples.

Since we rebuild our codebase, our components are built with Vue, Laravel and BEM. This means that we use seperate HTML, SCSS and Javascript files, mainly for SEO reasons. So I also need to show these seperately in our documentation.

In Zeroheight I could do this by embedding examples from anywhere on the web, like Codepen or a Storybook. But I prefer using Zeroheights codeblocks, which offer the same functionality but the code is stored in Zeroheight. That way other developers can also edit the examples in our documentation.

Right now we have our design components and code components right next to each other. Designers and developers can compare them, and see what they need to create designs that feature pre-existing code components, or they can see which code components they need to quickly turn designs into code.

Adoption among designers and developers

It’s one thing to create a design system, but it’s also important that other people start using it. So a lot of my effort this year went into talking with other people about what they needed, and how they would use certain parts of a design system.

Getting our designers to use our design system was a success. They particularly liked using the pre-existing styles, buttons and input styles in Figma because it saves them much work and they know that frontend developers can understand their work more easily.

Getting them to use the templates in the design system was a bit harder. But using the templates in pilot projects helped a great deal. When we used the templates to create a new design for a webshop, the designer who worked with me got a better understanding of the value of these templates.

Another important factor in getting designers to participate was listening to user feedback. Over the year, there were multiple moments where I asked designers what they thought about working with the design system, and what they thought could be changed or added to the design system.

Adoption amongst developers was a bit harder. Of course they would use the styleguides created by designers. And they would build reusable components with our new codebase. But getting them to use and contribute to the documentation did not work out yet.

To raise awareness about the documentation, I put out messages on Slack each time I created a new component. And everytime someone asked me a question, I pointed them there. But a lot of times I heard that they had forgotten about the documentation, or the address had ended up somewhere between their bookmarks.

Next year: A design system team and process

To see how a design system ranks on maturity, John Gully and Marcel Somers from PatternPack have created a maturity model for design systems. Their system ranges from inconsistent, where a design system is absent, to governed, where the pattern library process is built into the organisation.

A Maturity Model for Design Systems

Comparing our design system to this model, we managed to get from inconsistent to beyond manual. After we ditched our first design system, we have now built a new documented pattern library that also contains code snippets.

I could even argue that our designers are at the governed stage. They use the design system in every new project and they are contributing. But our developers are not at the highest stage yet. They are still not looking at or contributing to the documentation enough. So next year, there are two things I would like to do to improve this.

First, I think our design system deserves to have a name now. We are now at a stage where I tell people we have a design system, and they should use it. But people keep forgetting that the design system exists. So we need something for them to remember: A great name.

The second thing I want to do is setting up a design system team and process. I can no longer maintain the design system by myself. It is growing larger at a steady pace, and changes to design and code are always needed. We have actually already started on building new reusable components in a team. But I am still looking for the right process which doesn’t just support building components, but also involving users and writing documentation.

By working as a team, I would also like designers and developers to collaborate more. The gap between designers and developers might become a little bit smaller this way. In 2020, I would like to do a series of sprints by keeping a backlog withuser stories, creating new styles, components and templates for our design system, and write more documentation about it.

Takeaway

After starting from scratch, our new design system has grown and is now being used across WebNL. I have learned a lot from our previous attempts that I used to make our new design system a success. But there are still things that can be improved next year.

Involve others early and often. Building a design system takes a lot of time and effort. Involving others in this process without rushing into things has helped me a lot. But still, involvement of others can be improved for us.

Name your design system. When your design system has reached enough maturity for it to be used, you need a name for it. When you have a name, people will remember it more easily and you can start promoting your design system.

Set up a design system process and team. At a certain point, your design system will grow too big for it to be maintained by one person. Set up a process and divide roles for UX researchers, UX designers, developers and project managers so they can contribute more easily.

Leave a comment if you’d like to share your experience with building a design system or if you have any questions.

Why design systems fail and how to make them work in 2020 was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the Netherlands, we have a holiday called Saint Nicholas (or Sinterklaas). It’s very much like Christmas nowadays. We like to say that the idea of Santa Claus was stolen from Saint Nicholas, but there has probably been some interchange of different concepts and ideas over the years.

Anyway, the festival in the Netherlands gave me the idea to compare it with Cialdinis principles of influence, because it has so much influence. And since Christmas is very much the same and much wider known, I will compare Cialdinis principles with Christmas and Santa Claus in this article.

Fun fact: You can also use Cialdinis principles of influence to explain other holidays, relationships, career development and all kinds of personal objectives.

Reciprocity

“We like to to give back for what we received in the form of a behavior, gift or service. We are obligated to invite people back or return favors.”

Christmas is all about reciprocity. Children show good behavior if they know they will receive gifts from Santa. We send back Christmas cards to people that sent us Christmas cards. We are invited to have dinner at other places, and we invite people back for it later. Or we pay them back with more gifts like wine and chocolate.

Commitment and consistency

“We like to be consistent with things we have said or done before by committing ourselves to those things.”

We’ve celebrated Christmas last year. We’ve celebrated it the year before. We’ve probably been celebrating Christmas since we were young. We’re not going to stop celebrating anytime soon right? It’s the most wonderful time of the year. Also, we’ve been planning this for months, picking our Secret Santas, trying out recipes for the Christmas dinner, and planning what we like to gift to other people.

Social proof

“We are more likely to believe claims that are approved by people like us or people we know. If more people agree, we are even more likely to believe.”

All around us, people are celebrating Christmas. It’s kind of hard not to notice it. It started when we were young, and other children wanted to know what we got for Christmas. And now, we’re discussing with our friends, family and coworkers what we are going to gift our children and loved ones.

Authority

“We are more likely to believe claims from people that have a certain authority on a subject, like experts, professionals or scientists.”

Santa Claus. He is the number one authority on Christmas by now. Companies use him everywhere, from print to tv commercials and the biggest billboards. He’s everywhere telling you to be good and and start shopping early. Also, a lot of companies seem to know exactly just what you should buy as a gift this year.

Liking

“ We say yes to people we like. We like people who are similar to us, we like people who pay us compliments, and we like people who cooperate with us towards mutual goals.”

We celebrate Christmas with the people we like. Right…? I know, there’s probably some relatives we meet during Christmas we don’t mind not seeing. But even if that’s the case, we give them fake compliments during Christmas dinner so they will like us back. And it’s the same with Santa. We wrote kind letters to him when we were young, and now we’re trying to work with him delivering his gifts to our offspring.

Scarcity

“If there is less of something we already want, we will want to have more of it. A product, services or an offer that is only available today, will attract more people than an those that are also available tomorrow.”

Will Santa be able to come this year? Can his elves make all these presents in time? Will his reindeers be kind enough to carry his sleigh another year? Can the villain be stopped from ruining Christmas? It’s a theme that comes back every year in movies and other places. Suggesting that Christmas might not continue creates scarcity, and makes us want it even more. And the stores will close on Christmas Eve, so you better get your Christmas presents in time.

Unity

“The more we identify ourselves with others, the more we are influenced by these others.”

At Christmas, we want to be together. Together with loved ones, family and friends. Why? Because we want to unite ourselves with them, getting a feeling of unity. And we don’t want some silly argument ruining our Christmas dinner, because that will destroy our feeling of unity. Then we might as well stay home.

Cialdini at the Christmas table was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

A few years back I did an interview with a creator outside of the design field as part of an assignment. I also had to write an essay about how their workflow differed from my workflow as a product designer.

When I got the assignment I just knew I had to interview a comic artist. I used to draw comics before I started in product design. I even wanted to be a professional comic artist for a while, although that didn’t work out for me.

Then I realised I actually knew a professional comic artist who might be willing to talk to me. I had been lucky enough to get drawing classes from comic artist Milan Hulsing at an art academy where I had studied before.

Milan Hulsing created a large number of Dutch comic books, and won a number of prices for his work. He is most known for his comic book titled ‘City of Clay’ about a story in Egypt.

In my interview with Milan I learned more about art and storytelling, and how it could actually improve our work as product designers. So let’s see what comic artists do and learn from it.

The interview with Milan

At the time I visited comic book artist Milan Hulst at his home in Delft. I recorded our interview and transcripted it afterwards. During the interview I asked Milan to sketch out his own workflow. But instead, Milan wanted to show me the process of making his drawings.

Creation process

Milan made a drawing for me to explain how he works. He always starts in a traditional way by sketching with pencils on paper in order to get a basic idea of proportion and composition. Next, he will start cleaning up his sketches by working on a light box.

It’s called the the blue version. A lot of comic book artists work that way.”

Afterwards he might work in black ink over the blue lines and scan his work to copy or color digitally.

“Now come the pretty lines and you can leave out some things. Then you might only see this and that line because the light falls over there.”

Design is bad

In the other part of the interview we talked more about the workflow of designing. I wanted to know how Milan designed his stories. But I noticed Milan was actually not very enthusiastic about design.

When we were talking about his illustration course, he mentioned how the students following his course were sometimes forced to design. It’s something he didn’t like.

“I never understood that. Like when you receive an assignment to define a problem for a festival. Like spending a long time in a waiting line, or not being able to see the stage if you’re short. Then they have to find a product to create a solution for that problem. It’s an illustration course, not a design course. For me that’s another example of the weird conception which states that design will find its way into all of the arts.”

But when I asked Milan about how he designs his comics, he was able to identify some steps in his own project workflow. This workflow doesn’t start with a problem. Instead, it is about adding something nice to make things more attractive.

Milan designs three major parts in each story. These are (1) the setting and moods in the story , (2) the structure of the story and (3) the characters in the story.

Finding a mood

Milan emphasized how important the story is in a comic. To be able to tell a story, Milan needs a mood because it is essential to how a story will feel.

“A story needs a certain mood to communicate what you want to achieve with it. So a story is really always directed at a mood.”

To get to the right mood, Milan will look at work of other authors for inspiration.

“Of course I always have some examples in mind. Those are examples that I won’t copy, but they will guide me a little bit. Like for my newest book I have three other authors where I know I’m headed at.”

So the workflow of Milan starts with reading.

“Well I really like reading. And it’s interesting to realise which images you have in your mind while reading a book. At least for me… This makes it easy to work from inspiration, because you experience something while reading a book.”

For example: for his newest book Milan used instances of work from other authors and he looks into historical resources. Then he would start making sketches. This way Milan worked out a rough, sketchy version of his comic book ‘De Aanslag’ before he started to work on the final version.

Structuring a story

After reading, Milan told me about the structure of his stories. For this, Milan likes to create an event based timeline.

“…If you want to make a connection with designing, it is good practice to create a timeline with events. As I said, you can tell a story in many ways. You can tell it flat so it will turn out to be very boring, or you can tell it in a mysterious way, for example. But it can be quite convenient to have a dry version of your timeline.”

Then Milan will make sketches and page spreads.

“I worked out my last book completely in rough sketches before I began. […] At a certain moment I will make pdfs with the comic book pages in order. Then you’ll see how a page works in a spread with two juxtaposed pages. This way you get an idea of how the book will work.”

The finalization of the comic is not separated from the process for Milan. During the finalization a lot can change in the design. Actually this is seen as a frustration by Hulsing.

“Naturally the design is not separated from the comic. It’s not like I make a design first and then make the comic following the design. It’s part of the same workflow. You have to crystallize a lot of stuff out of there, because you don’t want to change your style in the middle of the comic book. And sometimes that’s frustrating, because you’ve made progress and you want something changed, but it can’t be done since you started it that way after all. But a lot of times I recreate the first pages. For ‘De Aanslag’, my last book, I had multiple versions of the first chapters, I think.”

Character design

To design characters Hulsing creates backstories and sketches, to design the story structure he creates a timeline, and to design settings Hulsing conducts research. In order to come up with any of these three parts Hulsing first tries to find inspiration.

To design the characters in a story Milan makes use of background stories in which he makes choices about what and what not to mention in the final story. He explained what this looks like in the interview.

“Years and dates with information next to it. With that you can decide what parts to leave out entirely. But when you have them, in your head, it will guide how people act and how they talk to each other.”

Besides using background stories Milan thinks deeply about what a character will look like.

“For a comic you need to be able to repeat characters and be able to draw them from all sides. That is a first importance. People need to be tangible. A character has to be maintained in all scenes, in the style that comes with it. And next to that it’s just the basics of character design.”

Milan explained this to me by drawing a character.

“This is also how it works when I design characters. I will use the shape of a potato for this character.”

“You will try very much to draw something from a shape. Like a head for example.”

Collecting feedback

Milan also shows his work to other people to evaluate the quality of the story. He does not do this often, but when he does he will show his work to a befriended comic artist during the process. And he will discuss the structure of the story with his editor later in the process.

“There’s one colleague that is involved in everything from the early beginning. He’ll receive anything I make, I email it to him. But other people, like the person that edits text, that’s all in the end.”

What can we learn from this?

Taking a peek into the workflow of other professionals is fun. But to ensure that we can learn from this sneak peek, we need to compare our own workflow to the workflow of the professional.

On the one hand, we need to understand the similarities between the workflow of the professional and our own workflow. If there are no similarities, we cannot compare anything. But if there are a lot of similarities, we can start seeing patterns.

On the other hand, we need to identify differences between these workflows. These differences might make us understand why we do things differently, and maybe we can see things we hadn’t thought about before.

The comic artist as a designer

At the most basic level designing can be described as a process which starts with a problematic situation and ends with an improved situation. The way this process works can be divided in two steps: Analysis and synthesis.

By analysis of our research, an existing situation can be examined more deeply. This search for new insights and findings might ultimately be combined as synthesis into a prototype for an improved situation. This model is called the Analysis-Synthesis Bridge Model

The process of Milan Hulsing shows remarkable similarities to this model. Even though Milans choices in coming up with a comic story are very intuitive and he does not have a design problem, Milan still documents historical situations and existing books in order to make a prototype. He evaluates these later in order to make his own comic books.

Despite this, Milan sees himself more as an artist than a designer. To find an explanation this, we need to dive into history a little bit. In 1970 John Chris Jones, one of the first advocates of design thinking and user centered design, wrote a book called ‘What is designing’.

All those years ago, Jones wrote about the difference between designers and artists. According to him, a designer is trying to predict the future effect of their proposed design. But artists are working in the here and now, and this is also what comic artists do. A comic artist isn’t trying to solve a problem. Instead they just take inspiration and create something new from that.

But Jones also provides an exception for artists who are planning ahead in their work. This is clearly the case for comic artists, because in their workflow they need to maintain the story structure, the mood and the design of the characters. According to Jones these are artist that occasionally work with the prospects of a designer instead of the impulsiveness of an artist.

Differences and similarities

As you can see in the table below, there are a lot more similarities between the workflow of comic artists and the workflow of product designers.

They both look for inspiration, do research, make journey maps, use brainstorms, take design critique, develop and deliver. For a comic artist, this means reading a lot, creating timelines for stories characters, collecting feedback from other artists, making the actual drawings and dialogue, and getting their comics published.

But there are also a few differences between these workflows. Let’s take a better look at these differences.

For product designers a problem statement is crucial because they need to design for my clients and users needs. On the contrary, for comic artists a problem statement would be limiting, they seek to create original and personal content.

Product designers can take mood into their brand design. But for them, mood isn’t essential like it is for a comic artist. When you experience a story, you want to be captivated by its mood. But when you are looking to buy a product, mood can be a major distraction.

Comic artists create characters that are way more detailed than personas that designers are working with. The visual appearance, timeline and background stories of comic book characters are more detailed than a persona will ever be, simply because a persona is just a tool and a character is not.

Product designers use prototyping and user testing to validate their work. Without it, they can’t create compelling experiences for their users. It’s easy because we can keep changing the final product. We can do an infinite amount of iterations.

Comic artists do some prototyping by making thumbnails and sketches. This way they can tweak the results early on. But they mostly do not test this with users, because their work is final and not easily changed. There is only one major iteration for them, besides making multiple publications. Because of this they validate their work early on with other artists and later with experienced editors.

Besides the workflow, there’s one more difference: The autonomy of the work. The entire process, from idea to comic book, is in the hands of the comic book artist. Support is limited to editing and printing books. A designer on the other hand has to deal with many different stakeholders like clients, users, managers and developers. Because of this a designer is more often part of a team.

How can designers benefit?

These differences exist because the story is the ultimate goal for a comic book artist. For a product designer storytelling is only a means to an end, where the end is a final product or a solution for a user.

The result is that we don’t use mood and characters in the same way as comic artists do. But what would happen if we take our persona’s one step further, and make them into characters that experience mood? We could view them as performers on a stage, actors in a movie, or characters in a book.

We would start by giving each character a timeline. NOT just a timeline for today, this week, or even this year. A timeline for their entire life. Then we see where their timelines meet. The touchpoints in our customer journeys would suddenly become much more interesting, as we could envision rich dialogues and more complex emotions because of a historic context.

When we do this, we would also create much more empathy for our personas. Suddenly we would understand much better why our users are showing bad behavior. Or we would understand why they tend to prioritize certain human values over others. It might be because of things they experienced in the past.

This way of describing personas could also help us find the problems that we need to solve with our design. If we just look at a lifestyle of a persona, or the obstacles in their life, we might jump to conclusions and come up with bad solutions. If we understand their life story and history, we could find problems that are more essential to our users. Perhaps a central paradox that wouldn’t have been obvious if we didn’t look further back.

What product designers can learn from comic art was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

You don’t have to copy your competitors, or ignore them instead. By using two user testing methods explained in this article, you can see what your competitors are doing right and wrong instantly to start learning from them.

When I started my career in UX, people were always telling me how they liked this function at service X that they had used or seen. Then they asked me to copy it. That made me feel bad, because it was basically like stealing work from other people.

Other people were telling me that I should never even consider copying functions from existing services, because the fact that it worked for them did not mean that it would work for me. But that also felt wrong, because if someone else had already spent time inventing the wheel, why would I try to do it all over again?

For a long time I didn’t know what to do with this. I copied some functions other people had already made, trying to see if that would work for me. I also tried to come up with new stuff that no one had ever done before, trying and see if that would work.

That was until I started to do competitive usability tests. And it worked really well. I had already done my fair share of regular usability tests. So I knew how to come up with a hypothesis, make a user scenario, set up a user test and collect results to analyze and report. Doing this with competitors was easy.

What you should know before you begin

One thing that is really important to know when it comes to testing with your competitors is that you should be collecting comparitive data. You’re always collecting data when you are doing a usability test, but this time you need to be able to compare the data from a competitor with the data of your own service.

When I started testing competitors, I had the luck that my colleagues pointed me in the right direction. We had mapped main functions in the website of our client and two important competitors as a benchmark, and we were wondering what these functions were worth. But we also wanted to have some statistics that we could show to our client in order to convince them.

So in the usability test, I asked users if they could try and find these functions in the websites of our client and their competitors. For every user that could find a function on a website I would add a point to that website. After five tests, I could calculate the exact scores for every website, and compare them to each other.

This technique is called a traffic light usability test. There are a number of ways to use these kind of usability tests. You can also look at how long it takes a user to perform an action for example, to measure and compare how hard it is for a user.

Stop (or traffic) light usability testing reports

So far I have tried two kinds of competitive usability tests, and they both worked really well for me. I will explain for each of them how they work and when you would use them to do research on your product or service.

Function Benchmark Test

The first test is used for when you need to find out how your product is performing compared to its competitors. You want to know how far ahead or behind you are compared to other products, or you want to know where your focus should be. I had the following hypothesis in my case.

My marketing website about my kitchen store has a lot of functionality compared to the websites of my competitors, but a lot of users still choose their services over mine. I think their functions are easier to find compared to the functions on my website.

Preparation

To test this hypothesis, we began with a list of all the functionalities on the website of our client and those of two competitors. We didn’t think it would matter if there were functions on our list that were not on the website of our client. If they were on the website of competitors, we still wanted to know if users could find them and why.

Next, we chose two competitors that were most relevant to our client. There were actually a lot more competitors, but we couldn’t make users look at all of them, that would simply have taken too long.

We also set up screen-recording and eye-tracking.

Testing

We invited five users for our tests. We explained to them that they were going to get a list with functions that they needed to find on three different websites.

Because we didn’t care about how long it took them to find a function, they did not have to follow any particular order. They could just browse the website like they would normally do, and tick off any functionality on the list they came across. While they were browsing, we asked if they could tell us what they were doing and why.

After looking at each website, we made sure our users checked the list one more time to see if they didn’t forget any functions. We recorded their answers digitally, so we could easily collect the results in a spreadsheet and calculate the scores.

Analysis

We looked back at our eye-tracking and recording data to see what users did. Often, users told us that they found a certain functionality while they found something else. Or they told us that they did not see a function, but their eyes actually went over it. In that case it probably just didn’t seem interesting to them at the time.

Because we had recordings we could rewatch the tests later to see if users checked off any functionalities incorrectly. Knowing about this was vital information because it told us something about why they could not find certain functions.

Results

In the end, we had three scores for every website that we wanted to compare. We knew which website performed best, which functions were easy to find, and which were not. But most importantly, we knew why functions were hard to find because we asked the right questions and analyzed our recordings.

We were able to confirm that despite our clients website having more functionality, the functionality on the websites of competitors was easier to find. But more importantly, we were able to tell why those functions were hard to find.

We discovered that functionality was scattered across the website of our client, while competitors offered their funcionality in organised flows, resembling the way people find inspiration for their new kitchen in real life.

We even discovered that men and women prefer different flows when it comes to buying a new kitchen. While men want to start planning and visualising, women are more likely to look for inspiration and respond to personal style.

New Function Test

The second test is for when your competitors are offering a functionality that your website does not have, and you want to know if your users could benefit from this functionality on your website. In my example, where we wanted to check if product reviews would be relevant to our users, I had the following hypothesis.

My pet food webshop does not enable users to leave reviews and read reviews of other people, but other pet food webshops do offer this functionality to their users. I think my users will also be interested in this functionality.

Preparation

Normally when you would like to test a new function, you would need to build a design or a prototype that users can see and use before they can tell you anything insightful. But when your competitors already have similar functionality that you can access, you can just use that to show to your users in a usability test.

In my case our client gave us a list with competitors that offered similar webshops. We chose two competitors that had the product reviews we wanted to test, and where those product reviews worked well in our experience.

I also set up screen recording and eye-tracking.

Testing

I asked five users to take a look at product pages on each website, and decide whether they would be interested in buying the products offered on those pages. I did not explicitly tell them to look at the reviews, because I wanted to know if they would focus on the reviews by themselves.

For comparison, I also added a product page at the webshop of our client for users to look at, but without the product reviews. That way I could see how users would react if there were no product reviews, in contrast to the product pages with reviews.

During each test, I would ask users what they were looking at, why they were looking at it, and how it influenced their choice in deciding to buy a product. After each test, I would only ask users to fill out one quesion: Would they be interested in buying the product, and why.

Analysis

Often, their choice didn’t stroke with what their behavior showed according to the scores, eye tracking and recordings. But when they were asked to choose, they opened up and started telling more because they thought they were given control of the research.

Tricking your users like this can bring you insights that you wouldn’t have been able to expect. This way you can find out what else you can look into for new research. Or you can come up with new unexpected concepts you can now also test.

When I was done testing, I could see on which pages my users most likely wanted to buy a product. By looking back at the questions I had asked from my notes, the sceen recordings and eye-tracking data, I could see that users almost always looked at the reviews if they were present.

Results

I found out that most of the time users didn’t base their choice on the product reviews primarily. But they still looked at the reviews for a number of users. They wanted to see whether their own choice would be confirmed by other users, or whether there would be positive reviews from users who had a pet animal similar to theirs.

But sometimes my users would tell me they didn’t think reviews were relevant to look at, because they had already been advised by their vetirinarian to buy a specific product for a disease of their pet. In the test however, those users still looked at the reviews because they found the reviews entertaining to read.

The users also told me what they liked about the presentation of the reviews on the product pages. Some aspects made things more clear to them, while others were disturbing to them.

So after the test, I could advice our client not only about the relevance of product reviews to them, but also about how to implement this feature. Even though I hadn’t designed or prototyped anything myself.

Start testing

When I started my career in UX, I didn’t know about competitive usability tests, or even about usability testing in general. Because of that, I also didn’t want to feel bad because of looking at competive products and copying their functionality.

But now that I do know about these techniques, I know how to learn from competitive websites and I have found a way to tell clients exactly what they should and should not copy.

I hope that you, after reading this article, also know what to do with competitors and you can really start learning from them instead of just copying functionality that your clients have seen and like.

If you have any questions about these kind of usability tests, feel free to ask me and I’ll try to answer as best as I can. If you still think functionality of competitors should never be copied and have good reasons for this, I’m also welcoming you to let me know by commenting.

Don’t feel bad, user test your competitors was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

This article is the second part in a series about design guidelines. Also read part one about design guidelines and part three about organizing a workshop.

To create design guidelines for human centered design, we will need to take a look at the context of our design problems. Without understanding the context, we won’t know which problems need to be fixed by the design. To do this, we can use existing methods, like human centered design and the golden circle. But while these methods are powerful on their own, they won’t enable us to create design guidelines yet. So I’m proposing a new method based on these existing methods that makes it easier for anyone to create design guidelines for human centered design.

Design guidelines workshop: How I got design done

Human centered design

By now, you might know that the context of design problems mostly consists of business perspective and user needs. We try to understand why our clients have certain needs, and we want the services and products we make to be received well by the users. This is not only because it earns us money, but also because we want our actions to have purpose.

As a UX engineer at WebNL, I research human behaviour in order to make the products we make perform better with users. So I do a lot of user interviews, usability tests and journey mapping. But I’m also responsable for creating frontend code while realising the user experience. I have to keep in mind the limits of device processing power, network speed and search engine optimalisation. I can’t have good user experience without knowing the boundaries of technology, simply put.

So a lot of designers combine the business perspective and user needs with a third factor: technology. Together, they are combined to create human centered design. This just means that humans are involved in all steps of the design process.

People: Users and consumers in need of services and products

Business: Organisations offering services and products

Technology: The advantages and possibilities of modern science

We can create design guidelines based on people, business and technology. But a lot of human centered products and services still fail, ironically since they’re still not solving user needs. And that is mostly because businesses do not understand the why behind user needs. So to create good design guidelines, we also need to know why.

The golden circle

A method that teaches us more about the why is the golden circle, created by Simon Sinek. As an advertising executive, Simon looked at businesses and found out they mostly start with what. They sell computers or make software. Then sometimes they look for how and why to justify what they do. But simon also saw that the most successful companies start with why. This way he learned that companies should look for the why if they really want to know what and how. That is what he called the golden circle.

As it turns out, Simon’s model is not just a great motivator for companies to find out why they do what they do, it’s also a reminder for us designers to find out why we are designing things. But in itself, the model isn’t enough to create design. It doesn’t tell us how we find out the why behind the design, or where to look for it.

A new model: The golden filter of UX design

Since human centered design and the golden circle aren’t enough to create design guidelines alone, we might try to combine them into a new model. A model that gives us a more concrete way to handle things. First we would need a starting point, because we can’t start with the business, the user and technology all at the same time.

Let’s think about human centered design again and turn it into a design process. If it really should be human centered, people should come first in our design process. If we would start with business, we would need to limit our resources right away in order to make profit. And if we would start with technology, we would need to think about the limits of technology right away. By starting with humans, we make sure there are no limits to our creativity. We’re just trying to find out what our focus should be.

I’m not saying you should forget about business and technology. We just need to postpone those factors so we can explore more freely. Later we can combine humans with the business to get real again. This works a litle bit like a filter. We mix those two ingredients, human and business, together and a result will come out of it. That way we create design that matches both humans and the business.

But like mixing cooking ingredients in reality, it’s not really that simple. When you want to understand what your users need, it is important that you know what they do, how they do it and, most important of all, why they do it. It’s like the golden circle from Simon Sinek. If you don’t know why or how, you won’t really know what you need to do.

The golden filter — User research

When I’m doing user interviews, I’m usually trying to find out the layers behind the actions of users to find out what, how and why. I always like to find out why the most, because often users don’t think about why they do things before you ask them. When you ask them, they find out something about themselves they didn’t know yet.

The things users want to have or want to do are called attributes. They might want a good pair of sneakers, or they want to eat healthy. We can ask about these attributes, or observe them.

When you ask users why they like to have a good pair of sneakers, or why they want to eat healthy, they’ll most often answer with consequenses of those attributes. A good pair of sneakers might give them the ability to run further, while eating healthy might give them more energy. Knowing about these consequences, we will also know how the attributes satisfy their needs.

But we can still go one step further. When you ask users about why these consequenses are important to them, they really start thinking. They’ll probably say that running further is important to them because they like to achieve, and that they need the energy in order to achieve. Achievement is a human value, it reveals the identity of your user because values are the reasons why they do what they do.

Like pouring water into a filter to get to the gold, we can put users through a filter of interviewing and observing to find the values behind their needs.

Now that we know the values and the consequences of the attributes that users are after, we can think of how we can make these attributes better. The sneakers need to be durable, and the food has to provide energy. These are good design guidelines, right? Wrong. We haven’t thought about the business side yet.

When you’ve done user research, you can create persona’s from user values, map a user journey to identify user problems and define a problem statement for the problem you want to solve. However, these steps are not part of the model. They are left out intentionally, because persona’s, journeys and problem statements are just tools to identify and communicate user needs and problems. It’s good practice to use these tools, but they are not the end result you should focus on. Also, when choosing a problem to solve, you might want to know what kind of problems your business can solve, and which it cannot. So let’s have a look at the business perspective first.

The golden filter: Business perspective

When it comes to business perspective, we can simply sell attributes as a solution to users. We can sell shoes for people to walk in, or we can sell food for people to live. In essence, this is what doing business often comes down to. But as Simon Sinek showed with his golden circle, a business can be much more successful if it knows why. So we need to find out how and why a business can help people better.

Luckily, we already found out why users want certain things. If we take their values and combine these with corporate values, we can figure out the why of the business. Corporate values are made from the combined values of the people that work in a business. Apple is a company that has always strived to be creative. Nike is all about achievement. And Disney gives us pleasure.

At WebNL I’m working together with a strategist to identify corporate values in client companies. The strategist will do research to find out which corporate values exist in client companies. These corporate values are important because they can be used to create a vision and mission statement: A short description of what a business wants to achieve and why. Together, these corporate values, vision statements and mission statements form the reasons for why a business exist: a business motive.

Mission statements and vision statements contain the final goals that a business wants to achieve. But the statements are not specific on how these goals and smaller goals can be achieved: They lack strategy. A strategy can tell us to create better communication through storytelling for example. This is a part of brand strategy. But sometimes the products or services that a business offers need to improved. In that case we need a concept or product strategy.

In the end, we will have a strong brand, a strong service or a strong product as a final solution. This is what a business produces, based on how it does this and why it does this. So instead of going down the filter, this time we are going up. The same thing happens with a real filter. If you throw water down at one side, it will shortly be pushed up at the other side before going down the drain of the filter.

The golden filter: Creating design

Finally, we will want to create design that meets business perspectives and fulfills real user needs. To do that, we need principles that are based on the corporate mission and the user values that we found earlier in our process. We can use those principles as widely applicable laws in our design to ensure that the why of the business and the users is represented in our design.

Next, we can create guidelines from those principles. The guidelines will tell us how to apply principles in a more specific way. But keep in mind that they’re still recommendations: They don’t tell us what to do with our design but rather the direction it should follow.

The final step is to create a set of rules that we can use to create visual design, wireframes or prototypes. They are like criteria that need to be met, or a checklist of things that need to be crossed of. Good rules tell us what a product or service should feel like, look like and behave like.

The model is now complete, as design will come out of the filter like clean water. But like a real filter, you can use the filter multiple multiple times to ensure that nothing is left inside the clean water.

Since strategy and consequences also tell us how, they are both on the same level as guidelines. We can use them to check if the guidelines are right. The guidelines need to tell us which consequences of attributes need to be achieved. And they should also comply with the strategy that is set to achieve business goals. If the guidelines do not match with the strategy and the consequences, maybe they need to be reformulated.

The same thing applies to rules. They are on the same level as solutions and attributes. We should be able to create the products and services that make up solutions by following the rules. And the rules should be what users expect of these products and services. Again, if they are not, maybe the rules should be changed.

But wait, what about technology. In human centered design, there are three main factors: Business, people and technology. But unlike business and people, technology does not have it’s own why. Technology is dependent on the why of people and businesses. They choose which technology gets development time. So it didn’t feel right to include technology in the model.

But technology is still a factor in making rules: When making rules they have to be feasible with current technology. But this also applies to ethics and laws, for example. So to make rules research has to be done into requirements and feasibility.

Conclusion

To create design guidelines, we need to have a clear view of the context of design problems. To get this view you can use the golden filter of UX design. The model teaches us how to create human centered design, while also taking account for the business, technology and other factors.

Using the model, we can create design that will out-perform common solutions that are just user attributes and nothing more. This is because we use the model to create guidelines and rules from user research and a business perspective. Finally we can check if our design meets those guidelines and rules.

In a best case scenario, we can continuously use the filter in an iterative design process to make sure that all the aspects of design stay in the right connection. Updates can be made when more user research comes in, our when a business shifts to another positioning, while ensuring that the design stays in touch with new insights.

The golden filter of UX design was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

This article is the third part in a series about design guidelines. Also read part one about design guidelines and part two about the golden filter of UX design.

A while ago I created a workshop for a project in order to align stakeholders on design guidelines. The workshop was a success, but I wanted to improve things. So later I repeated this workshop with a group of students in collaboration with Tim Laukens and Celine Duijndam from the University of Applied Sciences Rotterdam. You can read more about the results of this workshop and design guidelines in my article about design guidelines.

Design guidelines workshop: How I got design done

In this article I will explain how you can organise a design guidelines workshop yourself. I would like to gain experience by organising this workshop more often, but if other people can join in we might be able to improve things even more together. If you share your own experience after organising the workshop, new insights can lead to a solid workshop format that will help more people in creating good design guidelines.

The workshop assumes you have already done user research, collected user values and created design principles. In the workshop you will generate the design guidelines. You can do the workshop together with other designers and stakeholders in order to create consensus.

As facilitator of the workshop you need to reserve a space, invite people and get workshop materials like sticky notes, writing materials, or a whiteboard. In the workshop you will also need a decider, someone who can have the final word on important decisions to speed things along. This can be you as well, but you could also ask a product owner or scrum master to be the decider.

A workshop also does not have to take more than one hour, if you have a decider for when discussion gets stuck, and if designers and stakeholders are already up to date with most of your research results. There are four steps we need to take in the workshop.

1. Introduction and research summary.
2. Writing design guideline ideas.
3. Putting them on the map.
4. Deciding on the best.

1. Introduction and research summary

20 minutes

At the beginning of your workshop, your participants will probably need an introduction on what you’re going to do. But some participants won’t even know what design guidelines are, so they will also need an introduction on design guidelines. Tell them about the difference between principles, guidelines and rules, and how user values and corporate mission are connected to design guidelines.

Next to an introduction of a schedule and design guidelines, a recap of your research insights is also a must-have. Again, some of your participants may already be up to speed, but for most participants a summary of the research can be a good refresher.

In my own workshop, I was able to summarize our research in just 20 minutes because most of the stakeholders were already up to date. If your participants are not at all familiar with the research, you can just ask them to read a report as preparation for the workshop.

In the workshop with students, I had to explain more about what design guidelines are and why we use them. So instead of 20 minutes of introduction, I spent 15 minutes on describing the ideology, and another 10 minutes later in the workshop to describe the findings of a case used in an exercise.

In my workshop, I didn’t show any design principles. But I do recommend to show them, because I saw some participants struggle to generate guidelines because of this. It can also help if participants know about user values, consequences, a mission statement and a strategy. Read more on this in my article about the golden filter of UX design.

Design Guidelines: The golden filter of UX design

2. Writing design guidelines ideas

10 minutes

When you are done with your introduction, the group can start coming up with design guideline ideas. Distribute writing materials and sticky notes, and tell participants they have 10 minutes to write down any guideline they can think of.

Participants can use the principles, your user research, your mission statement and strategy to convert them into design guidelines. Ask them how your principles can be actualized and let them write down their ideas on this. But they can also use their own experience and knowledge to create design guidelines. This is actually more interesting because you might otherwise have missed that experience.

The guideline ideas don’t have to be perfect. They can be composed of keywords, and they can come from outside of your research or strategy. Your participents can become blocked if you ask them to generate final design guidelines, so make sure you tell them anything they come up with is valuable and discussion follows later to decide on the final guidelines.

Any participant should be able to come up with around 10 guidelines. So in the end you should have at least around 40 to 50 sticky notes with ideas written on them, depending on how many participants are in the workshop.

3. Put them on the map

20 minutes

Some guidelines that your participants come up with may overlap, some may not be as important as others and some can be downright impossible to achieve. So it is important to discuss the guidelines and put them on a map. This will take another 20 minutes in the workshop. I like to use something called a MoSCoW matrix for this process of mapping guidelines. But you can also use an Eisenhower matrix or an impact-effort scale.

For the MosCoW matrix, draw two arrows across a whiteboard of flipover sheet, one vertically on the left and another horizontally at the bottom. The vertical arrow represents a scale from very important to not important at all. The horizontal arrow represents a scale from lowest effort to highest effort. When you’re done you can ask participants to put their design guidelines on the scales.

In the end you can divide the scales into four areas. You will have the most important guidelines that also take the least effort in the top left corner, the must-do. In the other corners are the should-do, the could-do and the would-not-do.

But be aware, almost everyone likes to think that their design guidelines are the most important and take the least effort. If you would let everyone have their chance, you could end up with all of the sticky notes in the top left corner of the scales. To prevent that from happening, you can ask participants to take turns mapping a guideline from someone else, and explain why they would put it somewhere. This is a great way to spark conversation and making sure that everyone agrees on the guidelines.

4. Deciding on the best

10 minutes

Also make sure that you limit the amount of guidelines that you will implement. Take for example just the top 10 from the top left corner, and leave the rest for a later moment and put them in the back of your mind.

The last 10 minutes of your workshop you can spend on taking these top guidelines and making sure that everyone agrees on them. Take the design guidelines from the wall, and read them out loud so everyone knows which design guidelines are at the top. Then ask participants if they agree that these design guidelines are the most important ones.

Almost certainly, someone will disagree and remind you of a guideline that didn’t make the top or come up with a new one. At this point things might get stuck between stakeholders, but your decider can step in and take the final decision.

And if you’ve got any time left at the end of the workshop, ask feedback from participants so you can make your workshop better the next time.

Organizing a design guidelines workshop was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.