UIEtips: The Flexibility of the Four Stages of Competence

Jared Spool

November 16th, 2011

Because my son is a professional magician, I’ve picked up a bit of magician’s lore over the years. Amongst the pros, they have a saying: “If you want to learn a new trick, read an old book.” Turns out, there’s a lot of excellent illusions which have been lost for years that, when you bring them back, feel new to today’s audiences.

It’s not too different in our world of design. There’s a lot of long-forgotten “old thinking” which is relevant with today’s thinking. In today’s article, I share an old model that has appeared on my radar over the last few years.

If you hang out with me, you’ve probably heard me say, “Good judgment comes from experience, and experience comes from bad judgments.” Today’s article describes a model that explains how that maxim actually works. The model is called The Four Stages of Competence, and has a myriad of uses in our design work.

Read the article: The Flexibility of the Four Stages of Competence.

What old thinking have you discovered lately? How do these four stages fit into your design work? We’d love to hear your thoughts below.

7 Responses to “UIEtips: The Flexibility of the Four Stages of Competence”

  1. Numisma Technologies Says:

    Thanks for sharing this very useful information with us.This is such a motivating post and i just loved reading it.

  2. Jim Jarrett Says:

    Cockburn and Boehm developed a competence model out of this as well for agile developers. I think their definitions are useful in other fields as well.
    http://agile2003.agilealliance.org/files/P4Paper.pdf

    They have a couple of sub-grades in the levels too (summarized from Table 2):

    Level -1: May have technical skills, but unable or unwilling to collaborate or follow shared methods.

    Level 1B: With training, able to perform procedural method steps … With experience can master some Level 1A skills.

    Level 1A: With training, able to perform discretionary method steps… With experience can become Level 2.

    Level 2: Able to tailor a method to fit a precedented new situation.

    Level 3: Able to revise a method (break its rules) to fit an unprecedented new situation

  3. cliff a Says:

    Great stuff. It reminds me of the old Donald Rumsfeld quote.

    I like to use this model to get a feel for where clients might be with UCD and usability testing. That might go something like this:

    - Unconsciously incompetent – calling a usability test a focus group or QA
    - Consciously incompetent – thinking maybe thery ought to attend one of these things and see what happens
    - Unconsiously competent – understand the value of testing but have a hard time not jumping to conclusions, solution-jumping, paying too much attention to outliers, etc.
    - Consciously competent – approaching the test and observing it in a fashion very similar to the usability engineer

  4. Juan Lanus Says:

    Hey Jared,
    The ticket to go from stage 2 to stage 3 is some training at UIE, isn’t it?
    Seriously ;-)

  5. Juan Lanus Says:

    I started caring about UI in the seventies (yes, there were computers then, albeit not PCs). I designed and implemented very successful UIs, pioneering the deployment of interactive apps in smaller business. Somehow I became unconsciously proficient without properly evolving, I thing I missed one or two stages. My learning was intuitive so I went from one unconscious stage to another unconscious one.

    When I started doing Internet UI, in the nineties, I eagerly devoured all the material available in the Internet and fulfilled the conscious stages. It turns out that I’m intuitive, a “lateral thinker” in De Bono parlance. And yes, the conscious learning augmented my unconscious skills.

    While at this learning process, I noticed another learning track, specific of UI design unlike Burch’s mode that is pervasive, and transversal to it.

    It’s about surface usability vs. structural usability.
    At first I understood surface usability, the kind of thing one can do by changing the controls in one page (type, appearance, location, labeling).

    Later on I realized that the real thing was what I call “structured usability”, related to the navigation through the pages of the site or application.

    Surface usability is characterized by a mockup, while structural usability is described by a state diagram. Let’s say that surface usability enhancements can ease structural usability issues, but not fix them.
    Surface usability is what a graphics designer does, while structural usability is mostly done by functional analysts.
    A nice tale about the problems of structural usability was the article entitled “The Customer Sieve”. The complete 2001 version shows how less than 50% of a set of online customers striving to purchase whatever will actually succeed, and that the most of them fall off track because they get lost.
    The current abridged version of the article is here: http://www.uie.com/articles/customer_sieve/

    These are the kind of issues that can be tested using techniques like paper prototyping: no-frills UIs focusing on the actions sequence.
    Another technique is “personas”. We used something similar in the seventies, only that instead of synthetic users we had real users, I chose the most cranky one and designed for her (I remember one…) with great success. As of then I did it rather unconsciously, now I’m conscious that I do it unconsciously.

  6. Dan Saltzman Says:

    Thanks for digging up this old learning and exposing it’s huge potential to new breed of UX professionals. Beyond all of the advantages already discussed, understanding these stage of competency also gives us an opportunity to look at some well-worn design considerations in a new light. For example, when considering how our designs will progressively enhance (or gracefully degrade, for the pessimists out there) from a browser technology perspective, we can now add in an additional consideration of progressive enhancement as it pertains to user competency as well. This gives us an opportunity to infuse the human element into a consideration that is often merely a necessary evil of cross platform experience design.

    At a higher level, though, understanding these stages of competency also provides a valuable window into a topic that’s been getting a lot of attention in the hallways here at EffectiveUI and more formally from our executive leadership – understanding our clients. While this might seem obvious, I see a lot of work going on in the client services space that takes the client for granted as a necessary gateway to the end user (and a paycheck). And while the end user should always stay firmly planted as the ultimate target, the clients that enable us access to those users are integral to the process themselves. And so, understanding and enabling them relies on a sort of melding of the model’s application to ‘Knowledge of Our Users’ (or understanding of the clients’ needs, in this case) and to ‘Our Users’ Objectives’ (or clients’ approach to their goals). By striving to become unconsciously competent, harmonious partners with our clients, we strive to fully align our strategic thinking with theirs in order to most closely understand their drivers for investing in user experience. As we move towards that harmonious alignment, we begin to help our clients move up the competency ladder with respect to their own objectives.

    So, why is this important? Because a knowledgeable, informed client is a formidable force inside of his/her organization. While it might make more sense for some to keep clients in the dark and to leave all of the UX work ‘to the experts’, I would argue that there’s always plenty of UX work to be done. And if the next time you engage with a client who, under your tutelage, has made a leap from consciously incompetent with regard to their goal of satisfying their user’s needs and their bosses’ demands to consciously competent, then all the better for your work together. You’ll have the opportunity to start the experience design process better informed and to ultimately achieve more together.

  7. Robin Koper Says:

    This article is spot on, thank you for your valuable insights! This is extremely useful to evaluate all team members including strategy, product, development, etc. or people that are less familiar with UX disciplines and UCD methodology.

    As UX professionals, we can use this information to help communicate and promote the UX disciplines and why they are important (e.g. research, information architecture, information design, interaction design, and visual design). I really like this holistic approach to the 4 stages competency!

Add a Comment