By trade I’m a product designer, focusing on people’s problems, not debugging computers. In high school, I took coding classes where I learnt Pascal and J# (yeah 😅). While I currently work in the tech industry, my knowledge of a front-end engineering is limited. So, when Chat GPT was released and its coding capabilities became apparent, I got excited — “I could now try out design ideas myself”!

A while ago, I created a small design asset library to test some Figma features. To make it more interesting, I challenged myself to make the library as lean and versatile as possible while keeping the minimal number of components. I tested the concept in Figma and it seemed to work well, so I decided to try to code it and see if it was feasible for production. That’s where Chat GPT came in handy.

Getting started

First, I needed to understand how UI libraries are created and packaged. To get a clear understanding of such a broad topic from GPT 3.5 seemed too complex. That’s where this article really helped me out.

Once I had gained a basic understanding of how web libraries work and my working environment was set up, I felt it was time to create my first component: a button.

A fresh install of Storybook already provides great examples of how to write a button component. While my AI prompts delivered similar examples, they were not exactly what I needed to achieve. I realised that I needed to learn a little bit more of code myself, and that’s where Chat GPT became handy.

Learning with AI

Searching for information on Google can be confusing when you don’t know the right terminology, and often results in lengthy documentation. This can further increase confusion. While having an AI assistant that provides concrete answers to abstract questions has significantly accelerated my learning experience.

Throughout the process I have learned my written prompts work best and give the most fun while learning for 3 cases:

• Learning a syntax
• Writing utility scripts
• Debugging errors

Learning Syntax

At the beginning, I was unfamiliar with many programming concepts. After researching some button examples, I became suspicious that I didn’t understand something. Therefore, a prompt helped me learn what to look for on the internet:

What would be the best way for react’s conditional rendering when component has 3 options?

AI returned 2 examples:

//ternary operator
option === 'option1' ? <Option1 /> : option === 'option2' ? <Option2 /> : <Option3 />

//switch statements
switch (option) {
 case 'option1':
   return <Option1 />;
  case 'option2':
   return <Option2 />;
  default:
   return <Option3 />;
}

I was already familiar with switch statements, so I decided to learn more about ternary operators. The Mozilla documentation provided a clear explanation, but without AI, it would have taken me a long time to understand what to look for. This simple concept guided me throughout the entire creation process.

Utility Scripts

Once I implemented the button as intended, I decided to add a style, and for that I needed icons. I wanted the learning process to be fun, so I decided to use my own assets.

The challenge was that I had a bunch of SVGs and needed to turn them into React components. The full prompt I used can be read here. To my surprise, the experience was better than I could have imagined when I asked:

Write a code that converts SVG files in a folder to react components in typescript

It returned a code with which I was unfamiliar, so I asked again:

How I’m supposed to run this code?

The received answer was so clear that I simply copied and pasted the code, updated the source and output paths, and had all the icons in my library within minutes! Perhaps it worked so well because there were already many similar examples on GitHub. I don’t know, but I must admit that the process was so efficient and quick that I doubt using any other example from the internet could be any faster.

Debugging errors

Gradually, I managed to implement multiple components, and the process was becoming tedious. Although I knew the order in which I wished to execute the code, I was still quite unfamiliar with the syntax. It made me struggle to avoid coding errors.

For a beginner, finding domain specific answers on Google can be scary at times. While having an artificial assistant by your side alleviates that fear. I just wrote some code, copy-pasted it into the AI and got a fixed version. Sometimes AI even reminded me what dependency package I was supposed to install. This process helped me understand what I did wrong, helped to improve my coding skills and boosted the motivation to continue.

However, when dealing with complex scenarios that have multiple dependencies, I felt like I had reached the limits of AI.

Limitations

I started writing the library styles using SASS, but during the process, I realised that there was a small chance that someone would actually try to really use it. I believed the chances would increase if the library used the popular frameworks. Therefore, I decided to transition from SASS to Tailwind CSS.

Unfortunately, using multiple CSS preprocessors together requires a bit of manual configuration. Although there are numerous examples on the internet, I spent two whole weeks stuck trying to find a working way to integrate Tailwind into an existing Storybook and SASS project.

Neither the examples I found on the internet nor the chatbot GPT provided working solutions for my specific stack. I even asked a professional engineer to review my code. Finally, I came across a 55-second video that provided clear information on certain details that I was unable to notice in the official Tailwind installation documentation.

Summary

I still struggled with migrating from SASS to Tailwind. However, I found this template and transferred all of my code there. I was able to create a working POC and test it with a few scenarios. You can preview the result by looking at the repository:

GitHub - domasmark/peacock-flounder: Simple UI Kit built using Chat GPT.

My process started with GPT-3.5, it wasn’t advanced enough yet to turn all of my ideas into reality with a single click. However, it certainly helped me learn and do things that I wouldn’t have even tried a year ago. Now we have GPT-4, AutoGPT, and many more tools that are sure to come.

The future can be scary, as we know that our work will not be the same as it used to be. Yet, it’s more exciting than scary. I am sure that design work will become even more expansive than ever before.

How AI-powered coding transformed the design process was originally published in GoPenAI on Medium, where people are continuing the conversation by highlighting and responding to this story.

Everything you need to know about what makes a button great.

Buttons are one of the main UI elements in interactive design. Some of the more complex interfaces can have hundreds of buttons on a single website. Most businesses measure their success by button clicks. So it’s crucial to communicate to the user how a button works and where it’ll lead them. Over the years, our design system has fine-tuned the craft of our buttons.

Buttons allow users to control the product and achieve their goals. It can help them navigate the interface, modify content or both.

Principles

As Google explains, a good button design follows 3 principles. It must be Identifiable, Findable and Clear. We keep close to these principles at Wix.

Making a button clear

A button must clearly communicate what it does, with zero space for interpretation. Text is the primary element that explains intention.

Of course, you can include an icon which helps to identify and understand the context. But without any text, it’ll lack full meaning. The text is a promise of what exactly will happen when that button is clicked.

Sometimes buttons need to include multiple messages, where the text and icon can even have different meanings.

Case study

In 2019 the OS Team at Wix decided to change the button hierarchy. When we first launched, our design system had buttons with text only in our primary CTAs. Any secondary CTAs we had on the page were indicated with just a button — no text. After our update, we turned all our icon-only buttons into text or text + icon buttons. This small change led to a huge increase in click rate for “Create New Folder”. The top bar actions next to the primary CTA got more exposure too.

This visual comparison shows how the upper layout won the test against the bottom layout:

Making a button findable

Actions must be located where users expect to find them. The main action must always be visible and positioned in the top area. Navigation actions can look neutral but also must be visible. Only the least important actions that don’t affect the main path (e.g. “delete”) can be hidden under popovers.

Avoid placing tool actions with navigate buttons in the same list. Users might not expect to find buttons that are out of context.

Making a button identifiable

Users must easily understand which interface parts are static and which are clickable. Wix uses blue color for all major actions. Lighter blues can be used only as the button’s background color.

In some cases, like on colored backgrounds, the blue color can’t be used due to the contrast. Then, text, contrast and shape plays the major role in making the button look recognizable and distinct from the rest of the environment. Following Web Content Accessibility Guidelines helps to provide a good text contrast, so the majority of users will be able to read it.

Text

Text is the primary element that explains the button’s intention. It should be clear, predictable and simple. Start with a verb to encourage action. Verbs must tell the user what happens once a button is clicked so they can predict the next step. Use simple language that will be recognized by any age group.

Case Study

Wix’s Photo Studio Team performed an A/B test which showed that users engage more when buttons are displayed with text. The application tested three layouts; icon only, text below the icon and text on the side. Versions with text won the experiment.

After a failed test, the layout was reverted to the original.

This study showed that text plays a crucial role in making buttons clear and actionable.

Text in context

A button’s text should reflect the context. Make sure the user is aware what action is available. For example, alert modals appear fast and change the layout. Therefore, the potential actions must be very clear.

In modals that just state the facts, like “Success” or “Two users can’t edit at once” it’s ok to use less descriptive buttons such as, “Got it, Thanks”.

Icons

Icons help users understand the context. However, icons can often be misinterpreted. Icons don’t encourages users to take action in the same way text does. For this reason, you should use single icon buttons with caution.

Icon buttons work great for professional tools where a user will regularly click buttons and memorize them. Placing icons next to a button with text will increase the chance of being noticed by users.

Case Study

Side navigation testing showed that Wix users engage more with drill-in buttons that have arrow icons.

This study shows how text and icons can give additional context when used together. This helps users understand what buttons leave the page and what buttons display more options.

Hierarchy

Applications tend to have multiple actions. Some actions are always used, others just occasionally. Not every button needs full attention but all buttons must be discoverable. A good hierarchy means every action will be discovered easily when needed. There are multiple techniques on how to create a good hierarchy.

Placement

The most important actions must be put in the most visible area; at Wix it’s the top of the page in the right hand corner. The lower the button, the less discoverable it’ll be.

In languages written left to right, users start to read from left, that’s why it’s good to display the main call to action last on the right side. Users can take an action once all options are already presented. According to psychologist Herman Ebbinghaus the first and last elements in a sequence are the easiest to memorize. This tendency is called the serial position effect and it’s used in UX design.

Emphasis

All buttons must be recognizable actions. Use emphasis to achieve that. Note that not every button must be emphasized at the same level. A single page should have only one main action. Other actions should be secondary or tertiary.

Style

Each button can have a style based on its own intention. A set of styles creates a design language which customers use when working with an application. There can be a different style for general, navigation, social share or upload buttons. Each brand product can have its own set of button styles.

Size

Buttons can appear in multiple sizes. Large buttons should appear in large and spacious layouts, tiny buttons should be used in small and crowded spaces.

Summary

A well organized hierarchy between the actions creates harmony on the page so it’s easy for the user to read and understand. For example, Wix Seatings Map Builder shows how button’s different properties make a clear hierarchy between actions — primary, secondary and least important.

• Primary: Highest contrast, crucial for the main goal.
• Secondary: Recognizable on the screen without any clicks, assisting the main goal.
• Least Important: Hidden under the Icon Button and are not really connected to the main goal, e.g.: “Edit Ticket”.

Each action has a clear text label that helps users to understand the button from first glimpse. Icons in the buttons are plain and recognizable by industry standards.

This article is a collection of experiences from multiple designers from many teams. A big thanks to everyone who shared their case studies, insights and feedback or simply designed great products that inspired this article.

Article was written by Domas Markevičius, edited by Wailana Kalama.

Is there a topic you want to see covered by the Wix UX team? Let us know by filling out this form.

Designing the perfect button was originally published in Wix UX on Medium, where people are continuing the conversation by highlighting and responding to this story.