The Lean UX Manifesto: Principle-Driven Design

Advertisement

My colleague Ajay and I have been working at incorporating lean UX at the enterprise level for over two years. In studying it, I find that there’s a temptation to lay down rules, and if the rules aren’t followed… well, then, you can’t call it lean UX. At the end of the day, though, some lean UX is better than none.

If you were told to finish off the following sentence, how would you do it?

“You’re not practicing lean UX if…”

I asked that very same question on Twitter, LinkedIn and email to some lean UX thinkers1 out there. My personal conclusion is simple. Lean UX is a set of principles that may be used to guide you to better, more desirable solutions for users. It’s not a process in which each tool is rigidly applied.

Let me give you a real-world example. Co-location is a hot topic in the lean UX discussion. If you talk to experts and read their tweets and blogs, you might get the sense that if you’re not a co-located, two-pizza-eating team2, then you can’t practice lean UX. I know that this is not the intent of authors of resources on lean UX3, but it’s out there. Frankly, the situation is ideal, but if you work in a large company, it might not be the reality.

The value of co-location is obvious. As Jeff Gothelf describes in his book Lean UX: Applying Lean Principles to Improve User Experience4:

“Nothing is more effective than walking over to a colleague, showing some work, discussing, sketching, exchanging ideas, understanding facial expressions and body language, and reaching a resolution on a thorny topic.”

I couldn’t agree more, but in one of my projects, it’s not a reality. Our team is spread across three states, two countries and three companies. We believe, however, that we can still practice the fundamentals of lean UX successfully despite this, and I believe we do. Our methods might make a purist cringe, but we have a measure of success (and also measurable success).

ux-discussion5
No matter where your colleagues are located, you can all still practice the fundamentals of lean UX. Image by Claire Murray6.

So, what I really wanted to know when I asked the question above was, what are the absolute must-haves in order to be successful with lean UX?

Here are a few of my favorite responses to “You’re not practicing lean UX if…,” along with my reasons why (in brackets):

From Ha Phan7:

  • “… your collaboration sessions with the team don’t include business goals and strategies.”
    [As much as I want to focus on solving user problems, it won’t fly if we don’t consider where we are headed as a business and whether the activity fits in.]
  • “… you’re not defining KPIs [key performance indicators] and integrating analytics into each release.”
    [Without a valid measurement, we can’t know whether we’re solving the problem. We have to be able to point to at least one number to know whether we’re failing or succeeding.]
  • … you implement every single step in the design process, instead of picking and choosing from the design toolbox.”
    [Lean UX is a set of principles and tools and should be applied as needed. We shouldn’t be ticking every box in a project management cycle.]
  • “… you’re creating long design specs for the vision of the entire product.”
    [Users do not interact with requirements documents, specifications and wireframes; so, the quicker we get to the end product, the better. Let’s not get bogged down by deliverables in the interim. Rather, let’s create the lightest thing we can in order to communicate how to apply the thinking to the end design.]

From Jeff Gothelf8:

  • “… you are not managing towards outcomes (not outputs, feature sets, etc).”
    [At the end of the day, we need to consider the bottom line. Sure, we’re building products, but more importantly, we’re building a business. Asking whether what we’re doing will make money is important? And if it will make money, how?]
  • … you don’t have a willingness and the freedom or support to experiment.
    [This can’t be done without executive buy-in.]

From Melissa Hui9:

  • “… you’re spending more time working on documentation than thinking about the design and collaboration with team members.”
    [This is similar to what Ha said, but this identifies an interesting danger. Working on documentation tends to be a one-person activity that takes away from valuable collaboration.]
  • “… your development team is not seeing what they’re building until they have to build it.”
    [The development team should be fully engaged and involved in the design process. Again, collaboration is key.]

The Lean UX Manifesto

After receiving these responses, I felt compelled to create a manifesto. The responses helped me to focus on the guiding principles behind lean UX. I like the ones cited above because they focus not on a particular tool, but rather on the seeds of innovation behavior. After reading all of the tweets and emails and then thinking about the current toolset, I boiled down the manifesto to what follows below.

I didn’t do it alone. I enlisted the help of two colleagues who I also consider mentors: Ha Phan, quoted above, and Ajay Revels, my lean UX partner in crime. Visit the Lean UX Manifesto website10 for more of the back story.

So, here is what we believe:

We are developing a way to create digital experiences that are valued by our end users. Through this work, we hold in high regard the following:

  • Early customer validation over releasing products with unknown end-user value
  • Collaborative design over designing on an island
  • Solving user problems over designing the next “cool” feature
  • Measuring KPIs over undefined success metrics
  • Applying appropriate tools over following a rigid plan
  • Nimble design over heavy wireframes, comps or specs

As stated in the Agile Manifesto, “While there is value in the items on the right, we value the items on the left more.”

How The Manifesto Works

Let’s take each of these in turn and see how we can follow the principles of lean UX.

Early Customer Validation Over Releasing Products With Unknown User Value

What if you worked at a company where usability testing just wasn’t done? Unfortunately, this is the sad state in which many of our fellow UX practitioners find themselves. How, then, do they follow the principles of lean UX?

With usability testing, we seek customer validation or early failure. Customer validation may be sought through other means as well. For example, does your company gather feedback from users? If that feedback is circulated, are you on the list of people who receive it?

Here are other sources of learning about customer needs:

  • Customer service representatives
    Their focus is on helping customers overcome experience issues. Try to speak to them regularly. They are likely documenting their calls, so see whether you can create some system for tagging experience issues that you can follow up on.
  • Sales representatives
    This is another group that is focused on the customer. They will understand what customer problems are out there to be solved. They’ll also know which features are important and which innovations customers want.
  • Website search data
    This is an invaluable source of customer desires. Search data can uncover website navigation problems and features or problems that customers are looking for.

Salespeople and customer service reps can be great sources of customer needs. 11
Salespeople and customer service representatives are great sources of learning about customer needs. (Image: Renato Ganoza12)

Collaborative Design Over Designing on an Island

Design should not be a solo exercise. Being a design team of one is no excuse. I use the design studio process13 and adopt the role of facilitator. Gather team members who own a piece of the project, and host a design studio workshop. Include at least the following people (adjusting to suit your unique organization):

  • Domain owner
    Your subject matter expert
  • Requirements Owner
    A business analyst or the person who gathers and writes the requirements
  • Data provider
    A data analyst on hand who is familiar with the analytics and can pull the info you need
  • Technology owner
    A developer, someone who understands the technology constraints and design patterns
  • Product or business owner
    A product manager or the person who owns this piece of business
  • Designer
    The UX or visual designer or person who owns the design and can facilitate the design studio
  • Researcher
    The usability analyst or UX researcher or person who owns customer development and persona creation

Solving User Problems Over Designing the Next Cool Feature

When you’re handed a requirements document, a thought-out solution, a feature, a brief or whatever artifact you receive to inform your work, begin by asking, “What problem are we trying to solve?” Ideally, you should clearly understand the customer’s problem. Design is problem-solving, so if you don’t know the problem, you can’t design a solution. If you do this enough, then the stakeholders will understand that you’re more than just a wireframe jockey. You’re a professional problem-solver with a system for creating solutions that make sense.

Measuring KPIs Over Undefined Success Metrics

You can’t measure success if you aren’t… er, measuring. Avoid vanity metrics. I love Dave McClure’s pirate metrics14:

  • Acquisitions
    Users come to the website from various channels.
  • Activation
    Users enjoy their first visit (a “happy” user experience).
  • Retention
    Users come back, visiting multiple times.
  • Referral
    Users like the product enough to refer others.
  • Revenue
    Users conduct some monetization behavior.

Applying Appropriate Tools Over Following a Rigid Plan

Lean UX should be a flexible process. As I started to develop the process steps for one cycle, I found myself overwhelmed with the number of tools being recommended. My advice, similar to what I’d say when creating a minimum viable product, is to apply the minimum tools required to get you to “pivot” or “persevere.”

Here are a few tools that I’ve found useful (not an exhaustive list):

  • provisional personas, right sized for the effort;
  • persona map (which we learned from Menlo Innovations);
  • assumptions, with the riskiest identified;
  • design studio;
  • paper prototyping in early stages;
  • digital prototyping (HTML preferred) in later stages;
  • guerilla design assessment (a better name for usability testing);
  • co-location wherever possible.

The design studio method is popular for collaborative design15
The design studio method is popular for collaborative design. (Image: visualpun.ch16)

Everything else should be applied as it makes sense. For example, if more customer development is needed, then take the time to interview as a team and to internalize customer needs. The lean startup world has no shortage of tools. Use only the ones that make sense to your project and that get you to a validated solution faster.

Nimble Design Over Heavy Wireframes, Comps or Specs

The goal is to release a product. Once it’s released, users won’t interact with the wireframes or requirements document as part of the product. They will interact with the product itself. So, try to spend less time on your design artifacts.

How can you lighten your wireframes?

  • Lighter annotations and more presentation
    I’ve found that if I take the time to present my unfinished wireframes to stakeholders, I will get valuable feedback sooner and save time.
  • Co-design
    If developers, quality assurance testers and business analysts are involved in the design, then they will share ownership and internalize the annotations. When this happens, you can pass off sketches as wireframes because team members will already understand the interactions.
  • Paper prototypes
    These serve a dual purpose. They get you to design validation (i.e. usability testing) sooner, but they also demonstrate the interactions. No need to write detailed wire annotations if the user can see the interactions firsthand.

It’s All About Principle-Driven Design

This all boils down to something that I call principle-driven design. As stated, some lean UX is better than none, so applying these principles as best you can will get you to customer-validated, early-failure solutions more quickly. Rules are for practitioners who don’t really know the value of this process, while principles demand wisdom and maturity.

By allowing principles to drive you, you’ll find that you’re more nimble, reasonable and collaborative. Really, you’ll be overall better at getting to solutions. This will please your stakeholders and team members from other disciplines (development, visual design, business, etc.). To quote the late Stephen Covey:

“There are three constants in life: change, choice and principles.”

That pretty much sums up lean UX.

(al, il, ea)

↑ Back to topShare on Twitter

I'm a New York based UX Designer in Financial Services. I believe that better, more innovative solutions come out of a group and use Lean Startup methods to facilitate collaboration.

  1. 1

    Why are some UX-Designers so obsessed with Design Principles and rather pathetic and incoherent Manifestos?

    How can you call Lean-UX “flexible”, when you list so many Guidelines, Rules and “Insights”as important and mandatory to be allowed to call it Lean-UX?

    It shows that Lean-UX is just another Anglo-Saxon Business Hype, driven by cute Buzzwords and empty Gestures towards those who hold the Purse.

    I wish our so called “Community” would be able to differentiate between Philosophy, simple Production and Controlling Methods as well as how to do Business, guide Clients, Teams and run a successful Project.

    Some practical Tips that MIGHT apply to some Projects, but not all of them. Don’t beat it into a Manifesto or Rules. Dogmas are for Religions.

    2
    • 2

      absolutely.

      this reads as another pile of meaningless management consultant bs couched in as abstract a language as possible to sound expert without saying anything constructive.

      the worst part is that clients, not understanding any of this, buy into this jargon and associate it with expertise.

      :sigh:

      -2
      • 3

        Totally agree with both of you.

        0
        • 4
          • 5

            I think you’ve all missed the point. Enterprise environments are different from small-scale implementations of UCD. This post, to me, resonates because of its applicability. Trying to carve out a niche where you can effectively design and deliver working enterprise products is much easier said than done.

            This post, and the ideas therein, are no more inflexible than the Agile manifesto – which believe it or not, has been around from years and still isn’t embraced in many enterprise environments. There are PRINCIPLES here without etched-in-stone rules. If that’s not flexibility defined, then I don’t know what is.

            To the OP, thanks for the pragmaticism. I’ll be sharing this amongst my team.

            4
    • 6

      The article might have brought the idea that these are rules, but it’s more like a guideline like the Agile manifesto.

      Each company has its reality, and implementing lean UX or Agile is not as easy as following this guideline. You have to take some of those ideas and leave others to create your own process that fits your business needs.

      As for me, I like the idea of more collaboration and less paperwork.

      1
    • 8

      Without having the experience working in a Lean environment or fully understanding the benefits of it, and also being a UX designer in that capacity, it’s probably hard to fully grasp the relevancy of this topic as a whole.

      There does tend to be what appears to be a lot of ‘jargony’ type words within methodologies like Lean (Agile falls within the same wheelhouse of jargony, manifesto-type methods). The fact is, these methodologies work for some teams, and their terms and the ‘rules of engagement’ help to keep practitioners mindful of what it is they’re working toward (not just deliverables but the actual purpose of what they’re building/designing).

      Even within highly flexible methodologies, there needs to be guidelines to keep you on point and to keep you within the right mindset.

      0
    • 9

      Its hard to digest such modern-art kind of articles when in reality the same output can be achieved with some simpler thoughtful moves. All we need to do is pretend that we are the user and evaluate what we have done from that perspective. May be its a trick from the stone age, but still it works pretty well while this one doesn’t. But sure, this article is going to be helpful for a lot people.

      0
      • 10

        I strongly believe there’s no way you can effectively put yourself in the shoes of the user when you are also the person designing/developing the software.

        0
        • 11

          But you, like anyone else lives and functions as a consumer on some level, no? If you can’t imagine yourself entering a user flow (to purchase the food you eat daily, your laptop, your design software, the car or transport pass you need to get to work, etc.), then you really may be too involved in your work..

          Any great artist has the ability to remove his/herself from a project, or as painters do- take a step back to re-analyze. The key is to use your *own* experiences as a user, to make the experiences you develop for others, that much better.

          You don’t need a rigid list of guidelines to do it, as most companies, organizations (and their clients) will differ to some degree. There’s a core set of logic that will always apply in UX and collaborative efforts, but putting a name on them just takes time away from getting the job done. To each their own though..

          0
      • 12

        Agree, agree, agree.

        The first five bullets in the manifesto are things you better be doing anyway. They are pretty much just parts of any good UCD.

        The last “Nimble design over heavy wireframes, comps or specs” I want to dismiss out of hand for the word “heavy.” How do you say “While there is value in the items on the right…” when you dismiss it so hard.

        I like people who do Lean, I like the work that comes out of Lean workshops for the Lean group in SF, but I cannot stand any manifestos or other rules that determine if you are lean enough, or which ruin my work by making sure we don’t write down why we made decisions, or enough to make sure that dev does the right thing.

        0
      • 13

        That’s pretty bad advice. For example, when designing a travel site aimed at wealthy Australian 60+ year olds, I couldn’t accurately just put myself in their shoes. Even having conducted tests for a long time, there was still no way to know some of the things I learned. A better ‘trick’ than attempting some of these methods? Sorry but don’t think so.

        1
    • 14

      Sadly, most people like “short” lists, especially when they are over-explained. Posts like this one are a waste of time for both – writer and reader.

      0
    • 15

      I agree with you as well. Creativity needs structure and process to reach a final goal, but every person, team and project is different. There is no single process that is perfect for everyone.

      0
    • 16

      Totally agree!

      0
  2. 17

    Coming up with a workflow that works takes lots of time and energy in UX. A lot of times we realize that we have to fail often and create many iterations of design and purpose behind design that still have to get sign off and sometimes work goes unnoticed in little things that make experiences a better one for the viewer. Testing often and testing early is a huge step in the right direction in the process. I for one enjoyed this article and understand the necessity to have a organized workflow that works but understand it varies for every different team. Great job.

    1
  3. 18

    Martin Christensen

    January 8, 2014 4:17 am

    This is simply great! I concur, have nothing to add. Great to have a manifesto. Thanks!

    0
  4. 20

    Great read! Especially with the Early Customer Validation piece, I am constantly thinking of ways to streamline a process with our internal Sales & CS reps for feedback and collaboration.

    Thanks!

    0
  5. 22

    Summarizing and labeling philosophies, steps and processes, like this article does, helps the ux and design community better interact with the clients that fund our trade and add credibility to our practices. There will always be a community of clients that avoid due-diligence and hire design consultants that speak the jargon but have no body of work and references indicative of them being an expert.

    As an experience designer I first became an expert at visual design, then interaction design an ideation. When I took these skills outside an agency and went direct to clients as an independent I had to learn the business side of consultancy. Articles like this one would have been invaluable to me at that time and helped me explain what my portfolio reflected but I lacked the vernacular to explain.

    I applaud Anthony Viviano for taking the time to empower our community.

    0
  6. 24

    It’s never an easy process managing UX design within a Lean environment, so it’s nice to see some of the lessons a few of us have learned the hard way boiled down into one succinct outline of some great ideas for best practices.

    What I have found is the most difficult to manage while attempting to maintain Lean is client input and involvement. Sometimes efforts to deliver what we can measure and what is actually solving a problem doesn’t satisfy a client who is devout in their belief that design-by-committee is a superior tactic – which inevitably leaves the project with considerably more documentation and bulky wireframing/prototyping than is ideal (or necessary).

    Then again… wrangling clients is always the struggle isn’t it ;)

    0
  7. 25

    The principles and/or philosophy of effective UX design haven’t really changed in the almost 30 years I have been in the field. Tools improve that allow for better or faster design, and occasionally, a new and interesting technique evolves. Every now and again, someone decides that they need to rebrand UX. Lean UX/Agile UX is just another one of those rebrandings, driven by development’s use of agile and scrum. Make no mistake though, what makes agile development possible is providing thorough design and requirements to developers.and that’s not always fast (although it’s faster than it used to be).

    0
  8. 26

    Concept of Lean UX itself originated from sticking too much into usability principles.
    No matter whatever you call by the names….design standouts on it own.
    Its governed by time,repetition,novelty etc and not by principles.

    In recent, every guy who calls himself UX designer was praising apples skeomorphisms , minimalistic whatever…until android/windows came with their new “Authentically Digital”
    principle. Now the same apple is following them(IOS7).

    Its all NAME sake ,called upon the situations….until some bold designers completely turn the whole table upside down.

    0
  9. 27

    Good post Anthony. Much appreciated and fully agreed.

    0
  10. 28

    I continue to not understand very clear how design could be NOT establishing a plain, and be without (just enough?) research. On my point of view, it’s very difficult find a way to integrate lean approach and (user? experience?) design into an iterative-incremental method.

    Otherwise, it’s not impossbile, but having a team of strong believers, ready to go out of their comfort zone, seems to be the basic requisite. Manifestos could be very useful to gather these people.

    Nice article.

    0
  11. 29

    Good article. Informative . Thanks for sharing!

    0
  12. 30

    Lots of great ideas, thank you.

    0
  13. 31

    “Nothing is more effective than walking over to a colleague, showing some work, discussing, sketching, exchanging ideas, understanding facial expressions and body language, and reaching a resolution on a thorny topic.”

    This might be effective from a time resource allocation PoV. Because you can share your ideas or feedback fast.

    But from an organizational PoV this is not so effective.
    It might work for brainstormings or when helping a new colleague, but complex work is done with organized written information, otherwise you would have to record every meeting.

    Coworkers should use the face to face situations to talk about their problems and needs, to laugh and get to know eachother personally, to relax and defocus. And they should be able to do this more often.

    Work is well synthesized in a task management interface so that they don’t waste time trying to figure out what needs to be done.

    This is not automation / people becoming robots, it’s minimizing the workload and giving workers more spare time to think about solutions to their own problems.
    It’s like a confort zone, the basis for creativity / innovative ideas.

    It’s almost as strange as this:
    “There are two kinds of companies, those that work to try to charge more and those that work to charge less.” – Jeff Bezos

    “The development team should be fully engaged and involved in the design process.”
    This sounds so much like IBM. And their design suck so hard it’s not even funny.

    I’m not saying developers shoudn’t come up with design ideas, I’m just saying they should focus on being the best at their job.

    0
  14. 32

    Interesting read. Appreciate your effort.

    0
  15. 33

    If you are responsible for designing your product/service/torture chamber/water bottle/whatever, then how you want to work is entirely up to you. You can pour exhaustive documentation into it, or you can draw on the back of a fag packet, and just build it. None of this matters.

    If you are responsible for defining how an existing thing functions, you don’t have any visibility of your company bank account, and can’t make the final decision on what you’re doing then you can try whatever method of working you like, inevitably the person who makes the decision for whatever reason that what you have done is right – in-spite of hiring you based on the belief you know what you are doing then you can pick any method of working you want ultimately, you’re still going to be sat in the boat heading down the waterfall.

    0
  16. 34

    I cam across this article because I was looking for ideas on how to approach a project that I have initiated for client – ‘complete rethink of their business infrastructure’ as it happens the clients shop window is their website but there’s soooo many facets to this that it has evolved in to a bigger issue of ‘what the hell are we?’

    Now… before I start. I’m not a designer, although I have created brands and worked for the best part of my life in design agencies. I’m also not a marketeer, although I manage several clients’ marketing strategies aaaand I’m no ‘technically minded’ person but I’ve implemented several systems for client. Basically I help businesses get $h!t done…. for good or bad and thats my issue here.

    Isn’t it better to just get stuck in, build something quick and gauge? Surely we all understand that there is no real definitive answers to these UX conundrums? We’ll never complete a UX project because it’s never ending and always changing: seasonally, demographically, technically, environmentally. It’s a puzzle you can never finish.

    “You’re not practicing lean UX if…

    …you’re writing articles”

    0
  17. 35

    With all due respect,

    The moment I saw the word ‘lean’ I knew it had to be the same old agile methodology story repackaged in some form. Good designers (I am sure the author is one), programmers would do just fine with or without any of these agile/lean/mean methodologies. For most part, these just become a drag and nothing else. Anyone with some common sense would have been doing whatever is the common sense part of these methodologies.

    Thanks,
    Gypsy.

    0
  18. 36

    Do completely understand that applying all of it exactly isn’t possible. But wht it means is that customize as per your company and your requirements.

    Thanks Anthony, It was interesting :)

    0
  19. 37

    I see Lean UX as collaboration over documentation. Also, dive-right-in over planning and assigning. It works for new products where there are a lot of unknowns. Once you have a mature product, small enhancements and an optimized dev team (offshore) will push you towards traditional deliverables. So there still is a place for detailed specs. Lean research etc. this the right tool for the job nothing more nothing less and adjust along the way.

    To be successful at lean UX you have to instill courage within the team to share half-baked ideas so the divergent process still happens. Once a team sets up a formal specification document the team naturally gravitates to it as the starting point. It becomes the comfort zone. “This is what we need in the end so I’ll be productive and get right to it”. When a team has courage to share divergent work individuals tend to focus on products not projects. This is the fastest way to unify a diverse team and innovate.

    I use “courage” as the means. Does everyone on your team feel comfortable running wild on the whiteboard with an idea they have? If not, individuals will continue to hide behind the perfected deliverable which is a time-suck and talent waster.

    0

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top