Understanding Lean UX

January 25, 2013

On January 27, 2013, I’ll be attending a workshop at the Lean UX Week Singapore 2013. So I thought I’d like to do some preliminary study first from the web about it.  Below are my findings and thoughts:

What is Lean UX

  • Inspired by Lean and Agile Development principles
  • Emphasis is on designing and delivering the actual user experiences rather than producing deliverables
  • Traditional documents are stripped down to bare components, if not discarded
  • Favor on very short, iterative, low fidelity cycles rather than long detailed design cycles
  • Process:  Concept -> Prototype -> Validate Internally -> Test Internally -> Learn from user behavior -> Iterate
  • Focus on close collaboration, shared understanding and continuous customer feedback
  • bringing “Think-Make-Check” discipline to projects
  • methods include Guerrilla research, low-fidelity sketching and rapid prototyping as compared to “Fat UX” which includes  month long research engagements and reams of formal documentation.


  • to get a product to market quickly and efficiently
  • validates the product early on
  • validates business goals and identify market needs
  • team ownership of the design is established earlier than “Fat” UX
  • uncover hidden design constraints / designer’s wrong perceptions of the requirements quickly
  • uncover what will work and what will not quickly
  • systematic way of finding the core features that matters most to users that’s cost effective . e.g. coming up with a “Minimum Viable Product”
  • early feedback from users can help reveal what features are important and what are not, or if their mental models are aligned with the way the product works
  • provides a cheap way to correct usability bugs early on
  • minimizes “waste”, waste defined as  anything that is ultimately not used in the development of the working product


  • agencies who are paid for deliverables may have problem with it
  • if development work is outsourced to vendors, where documentation work is important to get work started, Lean UX may not work
  • the tendency of reducing creativity to pure production
  • the tendency to treat deliverables\documentation as not important and rely on sketches and prototype to communicate everything about the product. Prototype may not cover all use cases
  • Things to watch out that could stifle collaboration: Anti-Patterns by Bill Scott
    • Genius Designer – All design emanates from an huber designer
    • Tribal groups – As soon as team gets bigger, tribes reform around disciplines
    • The Stranger – When new team member joins, the lean team assumes the shared understanding will just happen
    • Bad Habits – Old habits will tend to creep back in
    • The Naysayer – A single naysayer can bring the team down in an instant
    • The Visitor – People cycling int and out of the team can cause disruption
    • The Magic Tool – Tools that empower prototyping can enable designers to work in isolation
    • Going Dark – When a team member goes into isolation for more than  a day, the team is losing valuable collaboration
    • Change of Cadence – Whenever the rhythm changes, it can bring productivity down
    • Too Many Cooks – while lots of cooks are great, the work needs to be divided up among different type of cooks
    • Not Enough Pizza – when team suddenly increases in size, the team is in danger of losing cadence, shared understanding and focus
    • Tower of Babel – it is easy to assume took quickly that team members are speaking the same language
    • You Got Mail – teams can revert to email over collaboration. Geographically distributed teams can fall into delivery over collaboration
    • Inmates are Running the Asylum – when engineers drive the design
    • The Perfectionist – the tendency of perfectionist to not share their work till it is perfect
    • The Weakest Link – team members who aren’t up to working in a “lean” environment or no solid talent can really cause a team to stumble
    • The Wall -walls between teams can happen when tribes form, or seeing other teams as separate delivery factories or geo-distributed teams
    • Tangled up – when services and experienced are not separated with the technology stack, rapid progress is hindered


As I’ve mostly read, it seems that the Lean UX method is already what some UX people are doing. I for one have been doing it, not fully,  but I just didn’t call it by that name. It’s bootstrapping UX in a sense. Now that it has a name, the frontrunners of the idea might have created techniques and some best practices of doing Lean UX. I think that’s what I’m interested to learn about more. My hesitations on Lean UX (and this might be my misconception about it) is that I find Lean UX to be restricting on doing more thorough research prior to design (i.e. if thorough research is labeled under “Fat” UX).  When we want a good concept to begin with and not just a good user experience output, I think research is very important.  Nevertheless, I think Lean UX is an efficient way to develop and launch a product quickly to the market.









Using The 6 Thinking Hats in UX Design Thinking Process

January 8, 2013

Having  read  the book  ”The Six Thinking Hats” by Edward de Bono,  I thought  if I use it as part of my UX design process, here’s how it would look like:

Research and Planning

White Hat – Facts and Figures

  1. Who are the users?
  2. What are the goals of the users? What are their needs and problems related to the product?
  3. What are the business goals? What are the business strategies related to this project?
  4. How does the current overall customer experience and service flow look like?
  5. What are the design constraints for this project? technology constraints? other constraints?
  6. How does current design look like? How does it perform? What are its limitations?
  7. What are the opinions of users about it? What problems do users experience with the current design?
  8. What similar products are out there in the market? What’s the state of the art for this domain? Who are the competitors?

Blue Hat – Control and Structure

  1. Who are the user groups? Which user group should I prioritize to work on?
  2. What are the user tasks? Which user task should I prioritize to work on?
  3. What are the problems/features that need to be addressed? Which ones are to be prioritzed?

Brainstorming Solutions

For each problem/feature for each user group:

Blue Hat – Control and Structure

  1. What underlying user intention/goals can be deduced from this problem?
  2. What underlying business intention/goals can be deduced from this problem?
  3. What are the possible solutions for this problem? What known design patterns can be applied to this problem?
  4. How does each solution look like? Screen flows, UI control? Do wireframes or sketches.

Green Hat – Creative Thinking

  1. How have the other competitors tackled this problem? How does their solution look like? What can you do to improve on their idea?
  2. What can be done differently from what the competitors have done?
  3. Not considering if current technology/system/resources can cater for, what  ideal solution can you think of for this problem?
  4. What could be a ridiculous/out of the box solution for this problem?
  5. Think of a word (any random word relevant to this problem). Use it to think of another solution. What solution can you think of?

Assessing Solutions

For each proposed solution, review it with a mix of the four thinking hats below:

Yellow Hat – Positive and Constructive Thinking

  1. What value/benefit/advantage does this solution provide? What problem does it solve?
  2. What  future features/solutions can be built upon this solution?
  3. I think this solution will work. Why?
  4. What are slight variations of this solution? in terms of layout? UI controls?

Black Hat – Caution and Negative Thinking

  1. What are the risks if I go with this solution?
  2. What are the disadvantages of this solution?
  3. What problems do this solution introduce?
  4. What are the weaknesses that we need to overcome with this solution?
  5. I think this solution will not work. Why?

Red Hat – Emotions and Feelings

  1. If I will rate how much I like this solution, how would I rate it on the scale of 1 to 10?
  2. What does my hunch tell me about this solution? Is it gonna work or not?
  3. What other unexpressed opinions do I have about this solution?

White Hat – Facts and Figures

  1. Do a prototype and usability testing on this solution. What’s the user feedback? What’s the feedback from the stakeholders?
  2. How does it perform against user goals?
  3. How does it perform against business goals?
  4. Is this the best solution?

Grids and the Rule of 16

June 4, 2011

I’m starting to think that there’s a candidate for the sweet spot when it comes to using grids in web or interface design and I call it the rule of 16 (disclaimer: not a golden rule). My first encounter with grids in web design is 960.gs. It’s a grid css template, which divides the page width (default width is 960px, hence the name) into 12 or 16 columns, along with all the padding and margin styling. It comes with a fixed pixel width template, and the percent width (fluid style) template. I’ve used the 12 columns. But lately I think 16 is better.

I think the grid of 16 columns is better because:

  • It’s a good number. The most widely used screen resolutions is better divisible by 16 than by 12 or some other number (see table below), i.e. the result is oftentimes a whole number. Which means we don’t have to round off values for each column width. This is good because we need an integer for pixel values (i.e. 80.25px is not allowed), and we don’t have to deal with the remainder pixels resulting from the rounding off.

  • It’s good for full screen adjust layout. If you want your interface to adjust and stretch to full width whenever users view your design from a higher or lesser screen resolution width, your design will scale better when using the grid of 16,  on the same reason stated above.
  • The layout is more flexible.  A grid of 2 columns is too restricting and a grid of 24 columns is more flexible but is hard to manage. The grid of 16 allows for more fine grained layout compared to 12 columns. We can use 4:8:4, or 4:4:4:4 for column ratios. One main disadvantage however, is if we want the ratio of thirds, 16 is not divisible by 3, unlike 12. In this case we can use 5:6:5.

What do you think?

Walmart’s costly mistake

May 17, 2011

A colleague forwarded a post about Walmart’s $1.85 billion dollar mistake that struck me for a while. That kind of led me to that cliche-ish “You don’t have to lose billions. Learn from others’ mistake” thinking. Relating this article to user experience design, it somehow reinforced a lot of things that I already agree with.

  • Observing what people do is more important than asking them what they want. What we say and what we do are not necessarily equal. Surveys and focus groups have their value, but they’re just not enough. They give a hint but they don’t really tell what the actual behavior is. That’s where  the problem is, because during the time of actual use, the user behaves according to different contexts, scenarios and needs that might not be uncovered during surveys and focus groups sessions. These sort of things are not easily articulated. Also, we can factor in survey questions mistakes (e.g. anchoring) that could produce biased answers which might not align with actual behavior. For more insight, see Jakob Nielsen’s Usability 101 post.

  • Asking the Why questions is better than just asking the What questions. Don’t get me wrong, I believe user feedback is valuable. But we should begin to ask Why questions Why do you do want that? Why did you do that? Why do you think that’s important? and then follow up the answers with another round of why’s. This is how we uncover unarticulated decision making processes. Rather than just asking What do you want, X or Y? What will you do? What is important to you? Both set of questions will definitely produce different set of answers.

  • User experience design should be balanced with business goals in mind. Sometimes we go overboard with “passion” for customer experience and satisfaction, to the point that business goals are overlooked and the bottom line is significantly affected. Had it increased sales, Walmart’s “Project Impact” would have become a glorified case study of how focusing on customer satisfaction vs. profits actually benefited the company more. We still can’t tell if Project Impact would be good in the long run, but I think it must have been because the customer satisfaction solution results did not align with the business goals that Walmart “fired the senior executives in charge of the failed strategy”, as Phil Terry put it in his article. In design thinking, we have a problem, a goal, and a set of constraints to work with, from which we can come up a solution that solves the problem and accomplishes the goal. As designers, while we can have a lot of experience goal objectives to be thrilled about, we must not set aside business goals as one of the parameters and success metrics that we have when designing (and testing) a solution.

A huge loss from a giant corporation like Walmart will certainly get our attention. The best thing we can do is to learn from their mistake and examine our methods. How about you? If you’re in Walmart’s shoes, what lessons would you have learned?

Flow Theory and User Interface Design

May 8, 2011

Mihaly Csikszentmihalyi’s book title “Flow: The Psychology of Optimal Experience” rings a zen idea for me when it comes to ui design. If there’s something called an ideal accomplishment for a user experience designer,  it is to provide the best experience, isn’t it? So how do you define the “optimal” experience then? The optimal experience is when people experience the flow.

Quoting from the book, “flow is the way people describe their state of mind when consciousness is harmoniously ordered and they want to pursue whatever they are doing for its own sake”.  If you haven’t read the book yet, you can find a summary from Wikipedia’s Flow Theory and Mihaly Csikszentmihalyi. Basically, flow is being in “the zone”, that state when you’re so focused with a task (e.g. writing, playing a video game, cooking, etc.) that you begin to lose track of time and the world around you, and you’re not bored or anxious, but rather you get a sense of enjoyment by just doing the task.

So the question is how do we design interfaces so that our users experience the flow with whatever task we want them to accomplish? It’s all about working the user’s consciousness. We have to make sure the following are integrated/achieved in our  design.

  1. The goal must be clear.
    • Every task is related with a goal (sometimes task and goals are terms interchangeably used) . A goal is a state, a desired result in the future (e.g. 100 twitter followers). That state or the process toward that state must be communicated clearly.  You may have to make the goal visible. You may have to make it interesting or you may need to emphasize it in your interface. You may have to make it present all the time.
    • some goals are made clear by displaying it in numbers (as in score boards in basketball)
    • some goals are inherently clear visually e.g. tower destroyed (as in Warcraft)
    • There are levels of goals: as in basketball, goal 1: the ball goes inside the basket. goal 2: the team’s end score is higher than the opponent’s. goal 3:  the team wins as champion the tournament.
    • Goals contribute order to consciousness, the same way having a to-do list organizes you and makes you productive. The opposite of entropy in consciousness is the optimal experience according the author.
  2. Give the user a sense of control
    • basically this means giving the user the right controls for her to reach the goal. As in user interface patterns, navigation, gestures, buttons, keys, etc.
    • the next level would be giving the user the “sense of control”. make the user feel that she can achieve the goal through your design. this means that you may have to remove the perception of complexity through your design (I’ve read Don Norman’s article about how some culture prefer seemingly complex products). Giving the user the sense of control, also means taking away her fear of failure or loss, and this means providing exit, escape, error recovery or undo mechanisms in your interface.
    • this also means presenting the right level of difficulty according to the user’s skill. One of the core ideas of achieving flow is that you should be working on a task that has the right amount of difficulty (challenge) and you have sufficient skills (ability) to accomplish the task . High challenge but low ability causes anxiety, while low challenge and high ability causes boredom. That’s why we usually experience in games where we are presented early on with a tutorial, and then afterwards we progress through levels/stages upon accomplishing short goals, so that we get just the right challenge for our skill level. That is what keeps us interested with the game. This idea contributes to the optimal experience, as this is where enjoyment comes in. If you succeed doing an easy task (no challenge), you wouldn’t enjoy it as much as succeeding in a task that is harder (enough challenge that is) to achieve.
  3. Provide immediate feedback for every action.
    • In a flow experience, you need to know how well you are doing every step of the way. A violinist needs to know whether he/she is playing the right note. Every note tells her about the effects of her action on the instrument, and whether she is playing the piece perfectly (which is the goal). Likewise, an interface should give immediate feedback for every user’s action if possible.
    • Levels of feedback could be 1.) control feedback as in showing button pressed, 2.) information feedback as in confirmation messages, detail views, or 3.) goal feedback like LinkedIn’s profile completion.
    • What makes feedback valuable is that it’s a symbolic message to the user  telling her whether or not she is accomplishing the goal, which in turn orders her consciousness, and makes her feel good (the optimal experience).
  4. Force concentration by directing the user’s attention.
    • Information must pass through consciousness before it becomes useful. If you’re not aware of the red car in front of you and a friend is waving at you, what good is it to you. Reactions are only possible if something has caught your attention. Likewise, if we want users to act/react, we have to get their attention (e.g. emphasizing the button).
    • Attention is energy, a psychic energy that is. Therefore it is a limited resource, just like time or money. We cannot attend to all things at once because of our limited processing capacity. We can only therefore allocate attention to specific items at any given time. In fact it has been studied that “the senses take in billions of bits of information every second, but only about 40 are processed by the brain” (see Attention). That’s why “manipulation” of attention” is important in user interface design.
    • If you are able to sequence the user’s attention optimally by taking away distraction and unnecessary information, showing hierarchy and emphasis so that information is digestible, disclosing progressively a handful of screens and controls only when needed, showing transitions, and keeping the user occupied with feedback that’s important for the accomplishment of the goal, then that’s where flow happens.
    • When the user gets bored or confused or lost, it means something’s wrong with the allocation of attention.

Giving a flow experience to your users will be quite an achievement. Think about the video/pc games that you have been addicted so far. They were successful compared to other games out there because of the flow theory and some other factors, of course. But I believe flow theory is not only applicable for games. We need airline reservation sites, budget tracking mobile apps, or project management software that give us flow, where the interface design does not get in the way but rather help us focus and forget everything except the task and the goal.

My Notes from Tim Brown’s talk “Change by Design”

December 5, 2010
These are some of my notes from Tim Brown’s talk entitled “Change by Design” last November 10, 2010 at Esplanade Concert Hall, Singapore. The event was organized by The DesignSingapore Council and The Design Society.
  • Design used to be big. Lately it became small and sometimes people see it as just making things look good.
  • Design will be big again. If we use design for creating change. If we apply design thinking to everything
  • When designing consider the balance of desirability, viability and feasibility.
  • Apply design thinking to problems.
  • Design starts with humans, their needs, motivations, perspectives, aspirations and behaviors.
  • Sometime we think before building. How about build first to facilitate thinking. That’s where prototyping comes in
  • Prototype quickly in order to filter through ideas and for best ideas emerge. Start with low-cost materials, or low-fidelity output.
  • Prototype is not limited to software mockups, or product prototypes. We can also make service prototypes. Where we role play a service solution in quick and cheap means.
  • Sometimes we design so that people would buy. This is design for consumption. How about designing for participation, where the aim is for people to participate.
  • The process is: understand the situation, then solve the problem by prototyping.
  • 3 things that support behavior change: Norms, Rules and Tools. If you change these 3, you can induce behavior change.
  • Your network (friends, families or social network up to the 3rd degree of separation ) influences the way you behave.
  • So when we design to encourage people to change, we have to work in the context of network as well.
  • Stories are powerful. It can be used to create or initiate movements.
  • Design thinking starts with asking questions. To get the right answer/solution, ask the right questions.
  • Everyone can be a design thinker, but not everyone can design very good. Just like everyone can write, but not everyone is a bestseller author


Information Architecture Perspective

April 30, 2010

I’m recently reading the Information Architecture book, 3rd edition, by Peter Morville and Louis Rosenfield and it’s a great book. As I started out on the book’s intro to IA, I experienced a little bit of a mind shift. I suddenly found out that everywhere we can see information architecture but we just don’t see it instantly. There’s information in every thing, and there’s information architecture in every thing. There’s a division, a classification, a grouping, or a compartmentalization in all objects and the set of components give away  information as to how an object is structured. The mind shift reminded me of The Matrix, where every object is actually information (a series of characters, symbols and numbers, flowing on the screen) and it’s just us making things in our minds what we see.


Information architecture of a basic recipe

Information Architecture, as defined by the book in the context that I was referring to above,  is the structural design of shared information environments. Let me show you what I mean. One example in the book was about a food recipe. A recipe is divided into 4 parts, the name of the recipe, the list of ingredients (further structured into 2 parts, which is the quantity and the item), the steps for cooking the recipe, and the number of servings that particular recipe can provide. This is information architecture. There’s a standard design in the structuring of  information in a recipe, so that components are clear, recognizable and easily understandable which makes the content useful as a whole to the user.

What’s bothering me was the realization that every object has an info architecture in them. It’s not just the Web where you see textual content to which info architecture can be derived. Physical objects also have info architecture in them.  We just don’t see them that way.  Say for example, a house’ information architecture is comprised of the “subconscious label” door , the window, garage, garden, etc.  A human has head, upper body and a lower body portion, which can further be structured into smaller parts, systems, etc. Even up to the lowest unit, we have the DNA, and it’s structured into strands labeled as A, G, C, or U,  the information needed to possibly create a human clone.

Tranlating visual object to information by labeling

Seeing visual objects as information through subconscious labeling

We have the ability to interpret a visual stimulus and translate it into information. When we can’t make a meaning out of something then that specific thing is not useful to us. If you see an object from the moon that’s totally weird, nothing similar to compare to, then that object remains useless to you until you find  any info or meaning that you can attach to it. That tells us something about the way we should design things. That this information architecture thing has its significance in the way we should design physical products or  pure information products like websites.

The goal is to make the division of parts clear, and each component easily recognizable. And we do that by putting information architecture into what it is we’re designing. At the end of the day,  our goal is to make a design where the user are able to identify the parts or groupings, label them subconsciously, and successfully map the function and purpose of each component as to how he/she originally thought they should work.  We are talking here about shared environments, so the collective result should be that our design is easy to understand not just for one person only; it shouldn’t solicit confusion and error among the majority of  users. Finally, I think the perspective of an information architect is that everything is information. A product has to be designed well by structuring  its parts and components well, so that users can immediately make sense out of that object and use it as seamlessly as possible.