Implementing Lean UX in the real world
By: Jeremy Bird
Tags: Lean UX, UX, Lean Startup, Agile, Design Systems

SUGGESTIONS FOR IMPLEMENTING LEAN UX “IN REAL LIFE”

These experiences helped me come to some realizations that were eye opening. They led me through experimentation to learn a few key discoveries that are absolutely necessary for Lean UX to stand any chance of being implemented successfully at Enterprise Software-As-A-Service (SaaS) companies. In the time since, I have come to learn that there are 5 keys to overcome the obstacles that often prevent Lean UX from getting off the ground.

1. Implement a design system (or at least a component library)

A living design system is absolutely critical if you want to stand any realistic chance at moving quickly enough to be able to learn from customers regularly and release small batches of functionality to customers on a regular basis.

Often you’ll hear the words “Design System”, “Component Library”, “Style Guide”, and “Design Language” used interchangeably, but they’re actually not the same thing.

A “Component Library” is a set of pre-built components (also sometimes called “Atoms” in Brad Frost’s “Atomic Design”) that can be pulled in to create a design or user interface. These essentially are the building blocks from which layouts and interfaces are built. By standardizing components, both you as the designer and your developer colleagues can be on the same page and create designs and interfaces very quickly. It takes a bit of work to set up but once you do, they save you a TON of time in both design and development. That frees you up to focus on learning from the customer instead of spending weeks designing, prototyping, and building software before you can get it into someone’s hands.

A “Style Guide” is the standards for how to use the the components. When should you use the primary button vs secondary button vs ghost button for example. Or what grid do you use when? Or what should the standard margin/padding be between different kinds of components. Etc.

“Design Language” is all around the information architecture and content of your product. What tense should you use? Should you use playful or technical copy? What accessibility standards are enforced? etc.

Style Guides and Design Languages are very valuable, but they are not as crucial to Lean UX as a component library. So if you have to start somewhere, start with a component library.

Something else to mention about component libraries is that they are a product for products. Like any product you can build or buy. If you are going to build your own make sure your company is big enough to justify the investment. To be done right, a custom design system or component library needs its own product team. It needs a PM, UX Designer, and developers. You need to do research, and follow the same lean process you would on a product being released to customers. Too many companies think it’s a “set it and leave it” project. So they build components to very specific requirements and then paint themselves into a corner later. Then later it either becomes a bottleneck where you need a developer to add a new component but they don’t have time, or else it ends up not having the components designers need to design so they don’t use components from the library and in no time half your code is using the library and half are not.

My recommendation would be that unless you work at a large company that is willing to create a “Design System Team”, that you go the second route: buy. Actually, you don’t even need to buy. There are excellent 3rd party open source component libraries that have been thoroughly researched, built, and tested that you can use. This is actually the route I have always gone since most of the companies I’ve worked at have been small to mid-size companies with relatively small product teams. Here are some of my favorites:

Ant Design Web Component Library

Ant Design is one of my personal favorites. At first glance it looks just like bootstrap, but under the hood it is very powerful (especially for the flexibility it gives developers). The styles are very easily overwritable and they even support internationalization, Typscript, and have React, Angular, and Vue versions. It is also very easy to get up and running and has excellent design resources (Sketch asset library) that matches the web components.

IBM Carbon Design System Web Component Library

IBM’s Carbon Design System is also excellent. It is very thorough and has had multiple teams dedicated to it for many years. It supports vanilla JS, Angular, React, and Vue but has workarounds for other frameworks as well. Carbon has great design assets although overwriting the actual styles of the web components is quite a bit more complicated (though definitely possible).

NativeBase Mobile Component Library

NativeBase is a great mobile component library built for ReactNative and VueNative that are compatible with both iOS and Android. It also recently started supporting web components though I’m not sure how thoroughly those have been tested. It is very easy to overwrite the styles as well and even has a super easy way to do theming built in.

Other component libraries

There are many other 3rd party component libraries available. There is a great list available at https://adele.uxpin.com/

2. Decouple front-end and back-end code

One of the things that really sets many Lean UX attempts back from my observation is how long back-end development takes. Yet this doesn’t need to apply to Front-End code. Often, though, the front-end and the back-end are so tightly coupled together that all developers are forced to become “full stack” developers. Even with a web component library in place this really slows down the agility of your team because back-end work doesn’t have the luxury of iterating multiple times. One other side effect is that in “full stack” environments, often management hires back-end developers and forces them to also implement the front end even though most back end devs hate the front end. On the flip side front end developers have to learn back end which often isn’t their cup of tea. The two types of development are actually very different and there are very very few developers who are equally good at both. It requires very different skills to be an excellent front end dev than a back end dev and vice versa.

But, if you loosely couple the front end and back end code, and link them via an API with a shared data contract, this enables you to hire dedicated front end developers who can use that shared component library to quickly spin up UI code by pulling various components together. This can be done with a mocked back end as long as the data contract is agreed upon between front end and back end which allows the front end team, product, and UX to iterate together quickly based on customer feedback (following Lean UX principles), while the back end is built out.

3. Establish a user research practice first

One of the biggest blockers to Lean UX I have found is your ability to learn quickly enough from your users and customers. Part of that is having a component library in place so that you are spending time on solving problems rather than designing/building components on every project. The other part is being able to get your designs in front of customers quickly and efficiently. If you’re building consumer software, you can just go hit a mall, park, or plaza and stop people on the street whenever you need insights or use services like UserTesting.com to quickly get the insights you need. With enterprise software, however, that doesn’t always give you accurate results. The jobs to be done in some environments are so specific that you really need actual customers (or perspective customers in your space) to learn from. This can be a challenge that isn’t going to go away just because you’ve formed your Lean Team and implemented a component library.

My recommendation would be that establishing a user research practice should be one of the first things you do if you want to help your team work in a more lean way. This doesn’t necessarily mean that you have to go out and hire a dedicated user researcher. The biggest challenge to establishing a user research practice usually is finding participants. The other great thing about establishing a user research practice is that you don’t need to wait until you have a Lean Team to do it. Just talking to and validating ideas with customers can go a long way to helping you to be more lean as a company even if you are not able to implement any of the other Lean UX principles. The key is to get to the point that you are speaking with customers on a regular cadence (at least weekly is a good goal). Here are 5 suggestions of how to establish a user research practice that can help shift the focus from gut hunches to learning.

1. Start small, but start

It’s really tempting to want to build out a robust user research program complete with quantitative and qualitative techniques balanced across all 7 areas of usability, but start small. The truth is that the vast majority of companies today never get past the 80% worst usability problems, and all you have to do to discover those is just to get your ideas in front of someone. You don’t even need to be good at user research techniques, just get your ideas in front of users and the rest will take care of itself. It’s far more important to get some feedback regularly than to get methodologically-strict insights occasionally. As you progress in your UX Maturity, naturally you will want to focus on refining your research moderating skills, incorporate more quantitative research, etc. But for now, just do something. Until you get past the 80% worst usability issues, how good you are at research techniques doesn’t matter a whole lot.

If you would like more info on what this might look like when you start out, or how a research practice should scale as both maturity and the company grow, check out the excellent presentation by Danielle Greene at the 2019 Front Utah conference, “Scrapping your scrappy research process for scale”.

I would emphasize, though, before you can “scrap your scrappy research process”, you have to have one. So start small. Get research happening regularly, then worry about scaling it and making it more methodologically strict.

2. Involve cross-functional team members in your research

Even if you can’t form a cross-functional team to work with day-to-day, start to bring other people into your process. One fantastic way to do this is to make sure any time you are doing research you have at least 1 person in a role different from you involved or at least observing the research. Jared Spool recommends that all stakeholders should be exposed to real people using real designs for at least 2 hours once every 6 weeks. I think this is a great goal.

One other suggestion I have found to work very well is to involve stakeholders in selecting participants, planning the research, and debriefing after the conclusion of the research. Naturally, it’s best if they participate in the actual sessions as well, but if they can’t at least involve them before/after.

3. Create a research plan

While you don’t need to be overly concerned with technique at the beginning of your user research journey, one thing I have found extremely helpful to start doing after your research program gets up and running (that many design teams neglect to do) is to create an actual user research plan. Forcing yourself and stakeholders to sit down and define your objective, questions, method, etc can really give clarity and focus to your research and helps you to demonstrate ROI better to management if needed. It also helps you to focus on learning. There are various ways to go about creating a user research plan. The process I use (“DECISION”) is outlined below:

Decide on the main goal or objective of the research

Explore questions & assumptions (what is it you want to find out)

Choose a method (interviews, demos, usability testing, etc)

Identify participants (employees and clients)

Script or tasks

Identify schedule & budget (time, recruiting, & equipment)

Outline responsibilities

Nail the schedule down

It is also helpful to succinctly summarize your plan to be distributed to team members or stakeholders as needed. This can be especially helpful if you are wanting to take an out-of-state trip to visit customers in their natural habitat. For example, I use this 1-page summary. You can download an editable pdf or sketch file to help get you started if you like.

4. Create a User Research Panel

It can be extremely difficult if not impossible to schedule research participants once a week if you have to manually curate a list, work with support or sales to manually contact them, explain what you’re doing, then try to schedule the sessions with interested parties. It can take weeks just to schedule a single study. This doesn’t work in a Lean environment. You will have to do this at first, but your goal should be building up a user research panel of people who have expressed willingness to provide feedback in the future. At the end of every research appointment you do, ask if they would be willing to provide feedback again sometime or if it would be ok if you reach out to them with follow up questions. Often, you will get access to participants through other departments, but asking participants to join your user research panel will open the door for you to contact them directly in the future. Over time you will build up a group of people who you know are willing to help you which greatly speeds up the recruitment process. AirTable is a fantastic tool to keep track of everything. They even have some templates to help get you started.

5. Automate the recruitment process

One game changer for me in my quest to speed up the recruitment process to enable Lean UX, was when I found this article on the AirTable blog around automating the recruitment process. It was a gamechanger and while I haven’t got it to run as smoothly as I would like yet, it is extremely helpful in speeding up the process.

The basic summary is to use NPS surveys (or some other survey type) to fill up the potential user research funnel, then at the end of the survey send an email to a segment of respondents asking if they would like to participate in a user research study. If they click the “yes” button in the email, you can then use a calendar-scheduling service like Calendly to automatically schedule research appointments based on your team’s availability. (You could set availability for every Thursday from 1pm–5pm for example). Once appointments are set, you can then follow up with details or instructions on what to expect.

If you’d like more information, check out the article. It has lots of great suggestions.

4. OKRs

Something else that can really help pave the way for Lean UX is to start to get the company (and especially the executive team) focused on outcomes instead of output. One of the best ways I have found to do this is to help them deliver your team “problems to solve” instead of “solutions to implement”. Most executive teams are very goal-oriented. They make and track revenue goals, EBITDA, and are very conscious of the roadmap. One of the tricky things, though is that roadmaps are typically linear commitments of features to be delivered by a certain date. Yet, software projects are almost NEVER linear. There are bumps in the road, detours, and ideally learning that cause us to need to pivot. All this causes “delays” when your measure of success is output.

To help shift the focus to outcomes, one thing I’ve found a surprising amount of success with is getting executives excited about Objectives and Key Results (OKRs). OKR is a goal-setting methodology originally perfected by Google and used by hundreds of other companies today. There are entire software products just to help companies implement and transition to OKRs.

The basic idea is that teams and individuals identify Objectives (problems to solve) aligned with Strategic Themes identified by the executive team, and Key Results (metrics that measure progress toward the objective). The how is left up to the team. Key results are like sign posts with a distance marker. They show progress and how far you currently are away from your objective. In short, they help you move from doubt to certainty.

For example:

Objective

Increase performance of product by Q4

Key Results

Eliminate 95% of bugs

Processing time reduced by 35%

UI job completion time reduced by 50%

The team is then free to figure out how they are going to eliminate the bugs, reduce processing time, and shorten job completion time. Every sprint or month the team can then report back to management on progress. With each small batch release, progress can be shown towards the key results instead of just outputting features. There is a lot of precedence for OKRs. Google and hundreds of other companies use it and have found success. Just Google “OKR” and you will find hundreds of great resources. If you need a jump to get you started, Perdoo has a lot of great information/resources at https://www.perdoo.com/resources/. They even have an overview spreadsheet you can check out with instructions, and examples of company, team, and individual OKRs.

This is all great, you tell me, but what about roadmaps? What does a OKR roadmap look like? Well, something like this:

Credit: Jeff Gothelf, What Does An Agile Roadmap Look Like

As soon as the executive team has identified the strategic theme, you can set quarterly OKR goals for your team. Then, clearly label any features that have come up as ideas “Features we are considering”. This helps put the focus on the fact that these features are HYPOTHESES. They may be right or they may be wrong, and that’s ok — and 100% up to the team based on their learning. You will also notice that the farther out you get, the fewer feature hypothesis you should have. That is because you will learn a lot between Q1 and Q4 so it doesn’t do much good to even brainstorm the how since all your work up until then will inform (and likely completely change) how you approach solving your Q4 OKRs.

So, then at the end of the quarter you evaluate your objective against your key results and decide whether you are good to move on to your Q2 OKRs. For example, let’s say at the end of Q4 we haven’t quite eliminated 95% of bugs using the example above. But we have eliminated 75%. Then looking at what we need to accomplish in Q1 of the next year we might decide that is good enough for now. So we move on to the next problem. Or, maybe we decide that we really HAVE to get to 95% and we’ve made a lot of progress but we’re not quite there. So we decide to bump Q1’s OKRs to Q2 and work on eliminating bugs for one more quarter. Now THAT is agile. It gives enough visibility to the executive team and board while still allowing the team to solve the problems and measure problems by outcomes and not output alone.

5. Show, don’t tell

Now, there are 2 ways I’ve found to go about a Lean transformation. You can evangelize the process and try to convince executives to change and let you do this new amazing process. Or you can SHOW them how it works and prove the value with your results. While it might be possible in small companies to do the former, the latter is almost always more effective. Changing culture and process is not an overnight thing. Be lean about implementing lean. Pick the very next thing you need to do to move towards the outcome you desire. Don’t forget:

This applies just as much to process and culture change as it does to UI projects. Just starting working more collaboratively and in a learning-focused way and people will follow you. Eventually you’ll get enough traction to propose doing a pilot with a cross-functional, autonomous, problem-focused team on 1 project. Then you show results from that. Then you take it to the next stage, and the next. I’ve even created roadmaps of process change before just so I can put my mind at ease that we are making progress and to plan out what the next phase(s) are.