Kanban Boards

Your constantly-updated definition of Kanban Boards and collection of topical content and literature

55 shares

What are Kanban Boards?

A Kanban board is a project management tool that helps teams visualize work and track project status in real-time. Borrowing them from the Toyota Production System, agile teams frequently use Kanban boards to increase transparency and limit the work-in-progress.

The Kanban method originated in the 1940s, when Toyota developed lean manufacturing processes to optimize productivity and reduce waste. The Kanban board is such an effective tool that it can be used by any team that needs to manage projects, not just teams practicing the agile methodology.

Structure of a Kanban Board

A basic board has three columns: To-Do, In Progress and Done. The team writes down all tasks on cards—one task per card—and adds them to the appropriate columns. Each member then picks up tasks assigned to them and moves them from To-Do to In Progress and finally Done. Some agile teams may include columns such as Review, Blocked, Releases, etc., depending on their process.

Example of a Kanban board in Github. — You can create a Kanban board through digital tools or go completely analog and use sticky notes. There aren’t any rigid conventions on how to label the columns. In our case, we chose to be a little playful with our naming and included an extra column for reviews.

© Interaction Design Foundation, CC BY-NC-SA 3.0

Kanban in Agile

In agile teams, the tasks on each card are typically (but not necessarily) written as user stories. Teams add the tasks or user stories for the current sprint in the To-Do column and aim to move all the tasks planned to the Done column by the end of the sprint.

Agile teams also commonly use a column labeled Backlog for all tasks that the team plans to work on in the near future. Teams may also use an Ice Box column as a placeholder for ideas and tasks that the team is not yet ready to work on but might consider down the line.

In organizations that have multiple projects moving along simultaneously, the Kanban board is sometimes divided horizontally into swim lanes. As opposed to creating a different board for each project, the swim-lane approach offers everyone on the team visibility on what everyone else is working on at any given time, without having to switch between multiple projects.

Learn More about Kanban Boards

Kanban is one of the several methods used by agile teams. For more industry insights, methods, tips and best practices, take the course, Agile Methods in UX Design:
https://www.interaction-design.org/courses/agile-methods-for-ux-design

Learn more about the philosophy and methodology behind Kanban, from which Kanban boards derive their name:
https://www.agilealliance.org/glossary/kanban/

Here are some examples of how organizations and teams can use Kanban boards for different types of projects:
https://clickup.com/blog/kanban-board-examples/

Read the origin story of Kanban and how it helped Toyota go from a loss-making organization to a global competitor within a few years:
https://kanbantool.com/kanban-guide/kanban-history

Literature on Kanban Boards

Here’s the entire UX literature on Kanban Boards by the Interaction Design Foundation, collated in one place:

Designing the Smallest Possible Thing

We conducted research with hundreds of people working on agile teams about their experiences in order to understand some of the biggest design problems they encounter. Designers who work in sprints of one or two weeks can be under pressure to deliver fast, skip research and cut corners, which can pretty quickly ruin a product’s user experience. One way to work in agile teams is to learn how to design small. We need to shift our mindset from "design everything at once" to "design the smallest possible thing."

One of the most challenging aspects of being a designer on an agile team is the fundamental idea of shipping code quickly and often. Designers working on a team doing one- or two-week sprints can feel tremendous pressure to cut corners, skip research and jump straight from idea to execution. Of course, we also realize that these are surefire ways to design the wrong thing, and badly.

In discussions about the difficulties of designing on agile teams, one of the most common complaints is that there is just no time! And that’s true in many cases. If designers want to work agilely and still design great, user-centered products, we need to stop designing faster and learn how to start designing less.

"We need to stop designing faster and learn how to start designing less." - Tweet This

We need to shift from a mindset where we design everything all at once and move toward a mindset of designing the smallest possible thing that can deliver value to our users. So, what does that look like?

Why We Design Small

Before we get into the how, let’s talk about why it’s so important to design, build and ship small things. It is not, as one might sometimes imagine, solely for the purpose of frustrating designers and researchers who sometimes like to have a holistic view of the things they are designing for often excellent reasons.

Finding the smallest thing we can to deliver value to a customer or user gives us quite a few benefits. For one, we get to deliver a potentially valuable thing to somebody who can start using it immediately instead of making them wait for dozens of other, unrelated features or changes. Frequently, very small changes or bug fixes can mean an enormous improvement in the user’s experience of a product.

Sometimes, of course, a change can have no impact whatsoever, or even a negative impact, and that’s a really good thing for us to find out as soon as possible too. By shipping smaller things more frequently, we have more chances to get feedback on our ideas and execution.

If something is going to be a massive failure, sometimes you can find out very early by shipping a small version of it. Imagine all the features you wouldn’t have created at all if you’d known how they would perform! Imagine all the value you could deliver to users if you weren’t busy building enormous versions of things that nobody wants. Delivering small features early gives you information that can help your team make a decision about whether the rest of the feature is worthwhile.

By breaking things down into shippable chunks, we can deliver value early and often and get feedback on our ideas before sinking tons of resources into them. That doesn’t sound so bad.

Unfortunately, it’s really hard to do well—and if you do it badly, it’s much worse than just designing everything up front.

Why It’s So Hard to Get Right

It doesn’t seem like it should be harder to design small things than it is to design large things, and yet many designers struggle with it for excellent reasons.

First, as designers, we’re often trained to think about products and experiences holistically. This is a good thing! We want to know the entire experience a user will have with a product. Indeed, we know that designing things in several pieces can provide a disjointed and inconsistent experience.

One designer we spoke with explained it perfectly. Her team was tasked with designing the information architecture for a very large site with many different categories of content. The engineers wanted to get started working on the code for searching the content, but she felt uncomfortable delivering the taxonomy for only one category, because she knew that—once they looked at other categories—they would find many more things that would require searching once she’d evaluated the other types of content in the system. After all, you don’t search for books using the same criteria that you would use to search for shoes or cars. She didn’t want an incomplete model that would just have to be changed later.

This leads to another reason it can be difficult to design on agile teams. Many of the people we spoke with reported that they very rarely got to iterate and improve a design once it was in the wild. When teams don’t return to incomplete or narrow versions of features, it can cause designers to shove as many details as possible into version 1.

And, of course, it can be very traumatic for designers to know that a feature is out in the world, imperfect and never to be improved. That is our work. We want it to be perfect. We want it to solve problems for people. We want to include it in our portfolios without blushing. These are all perfectly reasonable reactions, and they make it much harder to compromise and agree to design a small version of something when we are convinced that something bigger would be better.

What Designing Small Means

Just because something is difficult to get right doesn’t mean it necessarily has to produce a worse outcome. It may just take a bit more work to do well. Despite the well-founded complaints of many of the designers we spoke with, designing smaller things doesn’t have to mean designing worse things.

In fact, many of the people we spoke with found tremendous value in delivering value in smaller chunks, provided they remembered a few key things.

Small Isn’t Bad

Image depicting Jobs4Pets.com website

Example of a small, yet important view feature on Jobs4Pets.com.
© Daniel Skrok and Interaction Design Foundation, CC BY-SA 3.0

Often we refer to the first version of something that comes out as an MVP or Minimum Viable Product. Unfortunately, people often miss the very important “viable” part of that term. When you create the very first version of a new feature or product, it may be small, but it also has to be viable. It shouldn’t be buggy or impossible to use or otherwise bad.

Remember, we build something small and get it in front of users in order to learn something. That’s the whole point of producing something that people can start using. All we learn when we ship a bad or buggy or unusable product is that people don’t like things that are bad! Then, we have to figure out whether people aren’t using our new feature because it’s not the right thing or it’s the perfect thing but so poorly executed that nobody can stand using it.

Small Isn’t an Unrelated Mishmash of Features

Another difficult thing about designing, building and shipping in small increments is that we can lean toward shipping a lot of little features that get prioritized because they can be built quickly.

Imagine you’re building an interface that lets people search and apply for jobs. There are many things to include. For example, you need job postings with descriptions of the jobs that users get from potential employers. You need an interface that asks job seekers to submit their information. You need a system that lets potential employers review the applications. You’ll probably want some sort of profile or account pages that let both sides of the process store their information so that they don’t have to re-enter everything every time they post or apply for a job.

Each of these larger systems has multiple smaller features inside it. For example, the application process might have a feature that lets the job seeker pause an application and come back to finish it later. Or the posting feature might let employers repost a job description if they need to hire another person.

Now, as a designer, you might think you need to release all of those things to make the job board useful. But that’s really not true. What you do have to do, though, is make sure that you design and build things in the right order. You wouldn’t design the ability to repost a job before you designed the interface that let people post a job in the first place, right? And you wouldn’t want to design the interface that lets people apply for a job before you figured out a way to let them look at different jobs they might want.

Every time you design and release something, it should be something useful, and it should build on the existing interface in a rational way.

Small Is Useful

Most importantly, whatever you release should be useful to the expected user. If you have a very large user base, it might not immediately be useful to absolutely everybody, but it should be something that can be used by a specific segment of your customers, at least enough that you can get feedback on it and make it better in the next iteration.

Can you think of the smallest possible thing you could build for a job posting site that would make it useful? What is the least amount of design work you could do to deliver something that could be tested with users?

How Do You Design Small?

There are a multitude of techniques for designing small things that are still useful and usable and that can be improved and grown through iteration. For example, you can:

Understand the Goal

The most important part of designing small is understanding the core goal of the feature or product you’re creating. If your goal is too big or poorly understood, it’s very easy to just continue adding feature after feature because “somebody might want it.”

For example, imagine you’re designing the job board mentioned earlier. If it’s a general job board for any sort of job and any sort of user, you’re going to design it very differently than if it’s a job board for a highly specific industry in a particular location. Aiming too broadly will affect everything from your search options to the number of jobs you expect to show, to the requirements for the application form.

By zeroing in on the specific value you want to deliver to a well-defined set of users, you will already be on your way to designing a small, focused feature or product that will ultimately serve you much better than a large feature designed for “everybody” and useful for nobody.

Experiment with One

Let’s say you’re designing a reporting dashboard for your job searching site. It can be tempting to ideate broadly and try to understand all the possible different reports that employers and job seekers will want and then design them all.

Image depicting Jobs4Pets.com website

Example of a reporting dashboard for Jobs4Pets.com.
© Daniel Skrok and Interaction Design Foundation, CC BY-SA 3.0

While it’s perfectly reasonable to spend a bit of time to understand which reports may be most useful, consider only fully designing and building one at a time, preferably prioritized by which you think will deliver the most value based on your research. Why would you make your users wait to see the most valuable report just because you haven’t finished designing the least valuable one? What if you’re wrong and people don’t need reports at all? By designing and releasing one report at a time, you’ll learn more quickly while hopefully delivering value to your users on a regular basis.

Image depicting Jobs4Pets.com website

Designing and building one component at a time will help deliver the most value to your users.
© Daniel Skrok and Interaction Design Foundation, CC BY-SA 3.0

This obviously doesn’t just apply to reports. If you have multiple similar things that you’re planning on releasing, look at whether it’s possible to start with one and then add more later.

Start without Code

Often when we are asked to design a new feature or product, there are many different ways we could design it. We can spend a ridiculous amount of time in meetings debating the best way to implement something.

Ideally, we’d get to build many different versions of something and just see which ones people like better, but this leads us to another problem: code is expensive. Prototypes and experiments, on the other hand, can be quite cheap.

Instead of jumping straight to designing fully realized features that will immediately be built by engineers, try designing experiments to learn the best way to build something. Try a concierge test or a Wizard of Oz experiment. Build a few interactive prototypes to test with users.

There is no rule that designers can only design pixel-perfect interfaces. We can also be experiment designers.

Don’t Deliver to Everybody at Once

One thing that makes designers hesitate about shipping an imperfect or unfinished design to people is not wanting to disappoint their users. After all, launching something that’s half-baked can end up reflecting very badly on the product and the company.

On the other hand, offering something that’s a work in progress to a small group of users who may have opted into early releases is an entirely different story. Testing out a new design on a few dozen or even a few hundred users can offer tremendous value to the team in the form of crucial insights and potential problems without risking disappointment for the whole user base.

Stop thinking that you have to launch every new feature with a press release and a marketing push. You’re still delivering value to users, even if you’re only delivering it to a few dozen beta testers or some internal folks who have volunteered to try things out. You’ll find that you’re a lot less concerned about failure if it’s done on a smaller stage, and you’re a lot less likely to fail if you’ve tested out your designs on smaller audiences first.

Accept Some Imperfection

With all that said, it’s important for teams to get over any fears of imperfection we may have. The truth is, none of our products will ever be perfect; moreover, in many cases, we don’t even know what perfect is. Obviously, we should not be shipping software that doesn’t work or is buggy or insecure to people. But we also don’t need to spend days or weeks obsessing over every pixel and every bit of polish if we’re not even sure that the feature is useful.

Think of all the hours spent grinding out gorgeous designs for products that nobody ever uses. Think of how much more useful it would have been to spend those hours testing ideas and finding a product that people actually want to use before putting the work into making everything perfect.

Commit to Iterating

Of course, if you’re going to accept imperfection, your team had better also be willing to commit to iteration. When we asked designers to tell us their biggest complaints about working on agile teams, many responded that they hated that their teams never iterated. They worked really hard to ship things fast and then never went back to refactor or improve the features. Sometimes they didn’t even measure the results of the features.

This is explicitly anti-Agile. Agility requires iteration. It requires improvement and refactoring. If you never go back to improve (or kill) your imperfect features, then nobody will feel safe releasing something they think might be imperfect. We have to commit to learning from our users and constantly improving features and products that are already in the wild, not just shipping endless features into the great abyss of user indifference.

The Take Away

One of the reasons agile teams can struggle with design and research is that it can be a challenge to design small, discrete things that still fit into a greater product vision and don’t sacrifice quality. If designers want to get more agile, they should learn how to make small things, get feedback and embrace experimentation, iteration and refactoring.

References and Where to Learn More

Here’s a primer on Concierge and Wizard of Oz tests from Kromatic:
https://kromatic.com/blog/concierge-vs-wizard-of-oz-test/

Read the Agile Manifesto:
https://agilemanifesto.org

Laura Klein explains why there’s nothing wrong with aiming for "good enough":
https://www.usersknow.com/blog/2016/5/23/good-enough

Image

Learn more about Kanban Boards

Take a deep dive into Kanban Boards with our course Agile Methods for UX Design .

Agile, in one form or another, has taken over the software development world and is poised to move into almost every other industry. The problem is that a lot of teams and organizations that call themselves “agile” don’t seem to have much in common with each other. This can be extremely confusing to a new team member, especially if you’ve previously worked on an “agile” team that had an entirely different definition of “agility”!

Since the release of the Agile Manifesto in 2001, agile methodologies have become almost unrecognizable in many organizations, even as they have become wildly popular.

To understand the real-world challenges and best practices to work under the constraints of agile teams, we spoke with hundreds of professionals with experience working in agile environments. This research led us to create Agile Methods for UX Design.

In this course, we aim to show you what true agility is and how closely agile methodologies can map to design. You will learn both the theory and the real-world implementation of agile, its different flavors, and how you can work with different versions of agile teams.

You will learn about the key principles of agile, examples of teams that perform all the agile “rituals” but aren’t actually agile, and examples of teams that skip the rituals but actually embody the spirit.

You’ll learn about agile-specific techniques for research and design, such as designing smaller things, practicing continuous discovery, refactoring designs, and iterating.

You will also walk away with practical advice for working better with your team and improving processes at your company so that you can get some of the benefits of real agility.

This course is aimed at people who already know how to design or research (or who want to work with designers and researchers) but who want to learn how to operate better within a specific environment. There are lots of tools designers use within an agile environment that are no different from tools they’d use anywhere else, and we won’t be covering how to use those tools generally, but we will talk about how agile deliverables can differ from those you’d find in a more traditional UX team.

Your course instructor is product management and user experience design expert, Laura Klein. Laura is the author of Build Better Products and UX for Lean Startups and the co-host of the podcast What is Wrong with UX?

With over 20 years of experience in tech, Laura specializes in helping companies innovate responsibly and improve their product development process, and she especially enjoys working with lean startups and agile development teams.

In this course, you will also hear from industry experts Teresa Torres (Product Discovery Coach at Product Talk), Janna Bastow (CEO and Co-founder of ProdPad) and Adam Thomas (product management strategist and consultant).

All Literature

We conducted research with hundreds of people working on agile teams about their experiences in order to understand some

639 shares
5 mths ago