From a talk at Mozilla. Note that the start of Steve’s talk seems to be cut off—you’ll want to skip to 11:47, where it actually starts.

Duration: just under an hour

Portigal Consulting
Steve on Twitter

Today on Radio Johnny, Chris Baum talks with VP, User Experience at HUGE Brooklyn, Emily Wengert. Emily discusses her 2012 IA Summit presentation about designing with context. She covers how these ideas developed, what they mean when approaching a cross-channel design project, and gives examples of each of the contexts she explored in her talk. Her premise is that digital channels emerge more quickly than our typical design approaches are able to apply. Designing with context allows you to focus your design efforts in a way that lets the design process work across channels more effectively.

Quotes

“ While untangling why I didn’t agree with a client’s request, I realized that part of it was they wanted to think about mobile as just mobile…They weren’t thinking through what they could really be doing for their business at different moments. I wanted to get them to stop thinking of the channel, but that’s how they organized themselves.”

“Because of that one really sharp right-hand turn in that project, we’ve been able to shift the feature set they were developing and be able to talk through how to prioritize features that matter in different contexts to make sure you weren’t dropping the ball in any particular context…Fortunately, the business goals have started to align even more strongly with that kind of positioning of thinking about these different moments and delivering on them. That’s only given us more firepower behind the scenes.”

“We should really stop offering less on the phone, because they might just be at home, even with their laptop 6-8ft away. It suddenly means we have to stop turning mobile into this dumber thing…mobile is actually smarter b/c it has so many other things (gyroscope, GIS, access to other data that you keep in your phone)… we have to stop oversimplifying it to the point where we’re not helping people very much.”

Notes

* Follow Emily on Twitter @wallowmuddy
* Overview of Emily’s IA Summit presentation

Your organization invents something no one else does (as well, yet). The rest of the process goes like this: I have this tail. I put it on the donkey. I spend money testing and fixing the tail to get it closer to what the donkey wants it to do. I also spend money on marketing and sales people to convince the donkey I have what it needs.

Why do we waste money like this? It’s very easy to get caught up in the excitement of innovation. Most of us hear about something that can be done and adore taking it one step farther. Example: technology is able to discern between voices speaking? Why not make a mobile app that can measure the give-and-take in a conversation? Never mind the fact that the app would be an awkward contribution to any conversation, even if used covertly. The initial perception to seeing the results probably be “Hey, cool gadget!” or “Do you think I talk too much!?!?” Ironically, it would be a great application to use for ourselves as we practice running these deep conversations with possible customers using as few words as possible. But who were the designers empathizing with when they designed the talk-o-meter?

Often we receive a command from someone like, “figure out a cool way to mash up these two huge databases about London that’s visually interesting.” I encourage you to push back on the command a little and perfect it into something involving your empathy for people. “Figure out a visually interesting way for people who are moving to London to explore which neighborhood to live in.” This empathic perspective might require more than just the original mega-databases specified in the original request. In addition to housing prices and commute times, you will want to allow folks to choose crime history, traffic flow, noise and air pollution sources, special tax zones, income levels, school scores, restaurant reviews and ages, tree counts, architectural types, or frequency of art galleries or non-franchise cafés— whatever is important to them. All this information does exist as data. Now each person can identify their own unique considerations when exploring neighborhoods in a city. Now you are designing with a person as your primary concern, rather than letting data or technology limit your thinking.

In old school philosophical style, I will begin with my proximate enemy. My proximate enemy is the concept of “feedback loops.” Patina’d with a touch of the de riguer, “feedback loops” are often referenced as an accounting of social media’s virality. These loops describe the mechanism of social media participation. Feedback loops exist, in other domains, it is true. And feedback loops are a common feature of systems. But social media, and social tools in particular, are social systems, not mechanical, biological, climactic, or other operational systems. Social systems are reproduced not by system processes, but by meaningful exchanges among participants: in short, people.

Feedback loops

Feedback is an amplifying recycling of a source, say, a Fender Stratocaster in the hands of one Mr. Hendrix. It owes to the distance between two elements: a pickup, and a speaker. Close the distance between the two, and the signal tone amplifies itself, resulting in distorted feedback. Love it, but not an explanation of social media use, because it is acoustic.

Feedback loops fail as an explanation of social media engagement because they are a reproduction or amplification of the same: a single source. Social systems are reproduced on the basis of communication. And communication is dialogical. That is, it involves two or more participants in meaningful exchange. The common “feedback” features of social — likes, retweets, follows, comments, and so on — depend on the actions of individual users. The secret sauce, then, is in facilitating and amplifying not a single signal, but the coupling of signal. For one signal, a response. The response of an other (user).

Social action is awareness

Social engagement is built on social action. Social action is action of users aware that there are others. Not all social action solicits direct responses and replies, but all social action has in it the appeal to a response. In face to face situations, a look of acknowledgement suffices much of the time. But in mediated social contexts, there is no unilateral means of securing acknowledgment. Social media are built on separation, absence, and deferral. So the intrinsic appeal of social action — a feature, if you will, so fundamental to human social interaction that it must be accepted as a given — always remains. It is residue, ambiguous and unresolved, and it is the first key ingredient of our special sauce.

Social action is dead unless taken up by somebody. All of culture, all of language, and all of speech is “designed,” if you will, to make the improbable more probable. That is, to make communication more probable. Familiarity of meanings, use of a structured form of expression, norms and etiquette and innumerable practices all conspire to make it more likely that we are able to communicate with each other. So then, the challenge for any social tool is to make communication more probable.

Given that in mediated social systems, users sit at small backlit boxes reaching through the wire to share their thoughts and activities, the “design” of the application through which they engage necessarily structures and organizes their experience. But all of our socio technical systems harken back to original forms. Social tools are still part telephone. Part telegraph. Part radio. Part television.

You wait for a reply. The phone rings. It calls you — you are being called to answer. You place a phone call. The phone rings — a voice calls out: “It’s for you.” This is the system coupling of social action: action – response. And it is what becomes more challenging in social tool design, for unlike the phone, social tools are designed for asynchronous use.

Asynchronicity is distance. Distance not in space, but in time. Nearness, closeness, and immediacy are the human experience equivalents of space. This distance is inserted into social action and comes to separate action from response. The appeal — our first ingredient — is now at work. For it takes the form of waiting: urgent, distracted, compulsive, patient, or forgetful waiting.

Communication is a type of action system that by its nature is open-ended and ongoing. As it is how we maintain our relationships, it serves the purpose of allowing us to always resume interaction. And provides means by which to handle the gaps in between. Social tools, then, are built on action systems that are open-ended. They have no ending or conclusion, and are literally never finished. (Which is why it’s not really stories, but narration, which best describes social sharing activity.)

Communication wants to be probable

Given that communication wants to be probable, and given that mediation makes communication improbable, social tools use features and action designs that increase probabilities of communication. The Like, the retweet, the vote, and even the follow are system elements that serve as proxy communication. They are indirect symbolic expressions and actions. Same for all, but meaning something unique to each user each and every time they are used. These symbolic social actions in other words enable communication by other means: technical means, symbolic means, and within a social system that has ways of presenting these social actions to others.

Because these social systems are networked, any action taken that is captured and represented by technical form (like button click > “username liked this”) is displayed to others (a user’s friends), according to context (feed, page, etc). This leaves us with something very unique. A form or medium of communication quite different from the directly coupled ancestor of the phone, or the broadcast ancestor of radio and television. This unique property is distribution: propagation of a social action throughout the medium, if you will, according to “sharing,” display, privacy, and other design rules baked into the social system’s logic (just think Facebook timeline).

We saw earlier that the residual feature of social action is the appeal; the unspoken, if you will, of all that is said. Now this is complexified. For mediated symbolic action has a functional dualism: it appeals, and it propagates (distribution). Here we have the fundamental amplification of social media: a social action taken is visible (heard) in many “places.” It is a kind of action dislocated from space and place, and instead reproduced by system logic and rules in “contexts” “elsewhere.”

Social action is split

Now given that all social action seeks acknowledgement (directly or indirectly), mediated social action is split in two. The appeal is split from the action itself. For each additional context in which a social action is represented (say, a Like that appears in many friends’ feeds, on pages, in notifications, on phones, etc), its author’s intent is lost. For it’s a given that the author has not intended to “like” in front of each of his or her friends, to be seen in their feeds, or notified on their phones. A new form of communication is thus born — and all users must develop skills and competencies with which to interpret and handle what their friends mean, as well as what’s going on.

The dual function of the symbolic social action, an appeal split from propagation of the action’s represented form, complicates communication further. For there is but one possibility for communication as a kind of social action, and it is the response. But responses no longer mean what they did, when communication is unmediated and direct (as between people talking face to face). Furthermore, any response is itself a new social action, itself now with an appeal, and itself now propagated to contexts elsewhere.

Distribution

And so we have the second ingredient of our secret sauce: distribution. We are far from the feedback loop. For we have neither the closure nor the recycling that make up feedback. Rather, we have a much less efficient system of communication. What might be considered noise. And not just the noise “generated” by the propagation of social actions, but the meta noise, if you will, of all the lost intentional signals.

Which is where design comes in. Design of social must answer to the needs and interests of social action, not just the needs and interests of individual users. But social architecture has a growing portfolio of plans and blueprints at its disposal. And accompanied with an understanding of the dynamics of social activities, a sense for how to lay out social designs for increasing complexity over time.

Closure, still, is the first order of business in social interaction design. Closure makes communication more probable. In so doing, it decreases noise (noise being a form of redundancy). And so the social interaction designer asks not “what feedback loops do we build into this?” but “how do we facilitate social closure through other users?”

Closure is closeness

We mentioned earlier that distance in human experience is closeness. Closure is closeness. Jimi’s guitar feedback was closeness — proximity to the amp. But as speed of feedback. And in mediated systems, because they are technologies, closeness is a factor of speed (or time, as duration). The notification increases speed. The realtime feed increases speed. Speed reduces waiting time, and accelerates the process of communication.

Temporality

And so we have our third ingredient: temporality. All human affairs take time. Time not measured in minutes or hours, but felt and experienced: as tedious, dragging, plodding, or urgent, impatient, distracted time. Time has stretches, and spans; it has rhythms, cycles, and repetitions. It becomes habit, and pastime. And is lost in distraction, ephemera, and its own passage. Time, as we know it, has past and future. As past, it is recollection; as future, it is anticipation and expectation. No time, in human terms, is entirely unorganized, and all time, as we experience it, has meaning.

So the real real time revolution is not the revolution of speed alone. It is the revolution of im-mediacy. Approximation, by proxy of proximity, of immediacy in mediation. Design of socio-technical systems making increasingly running claims upon our awareness and attention. In short, getting ever closer to the presence in absence of that open state of talk which is the normal condition of everyday life.

Now many social systems designers have gone at the abstraction of social into design forms and rules. Gamification is one example of something interesting gone badly wrong at the hands of abstraction. Game mechanics, too, are oft but a shell of something compelling dislocated from the eventfulness of games and reified into codified sets of rules and recommendations. Design like this gets nowhere close to the grist because it takes its abstractions as real. Soon the map precedes the territory.

Designing for social makes use of much simpler factors. All social action appeals to others. All social action communicates. All communication is coupling. People understand the appeal of social action as acknowledgment. People understand the action of communication as response. People engage in communication through reciprocity and reciprocal action. All occurs over time, in order, and the more synchronous the experience the more present it feels.

To design social tools you need only to understand the distance at which you operate from the realities of human experience.

It turned out that despite my brand-new degree in human-computer interaction, I wasn’t the well-rounded practitioner that I needed to be. I was far from a UX craftsman.

Luckily, I landed a job by the seat of my pants, and even more luckily, I scored a fantastic mentor. She was whip-smart, patient and supportive, and she shaped me into a bona fide strategist and user experience architect. This story ends happily for me, but I was lucky, and that’s frightening. It shouldn’t be a matter of luck whether a hardworking user experience professional can learn how to produce quality work; it should be standard and expected.

As Lane Halley puts it, “There’s often a mismatch between academic programs and the demands of employment.” We need to address this mismatch. We should comprehensively train those new to the field so we can be confident that everyone calling themselves a user experience practitioner is capable of actually doing the job.

We can do this by taking the practice of user experience seriously as a craft, and training new practitioners as craftsmen. What do other crafts value? How do other crafts grow their talent? The German Bakers’ Guild makes for an excellent case study, full of inspiring examples that we can mine and apply to our own field.

Guilds care about building foundational skills

Germans demand over 300 varieties of fresh, high-quality bread, and about 70% of master bakeries in Germany belong to their local guild. German bakers take very seriously the task of growing new talent, and incoming bakers take very seriously the task of becoming a baker. It takes quite a lot of work to become a master baker; one doesn’t decide to do it overnight. It starts with about two years as an apprentice, attending school half time and getting their hands dirty in the bakery half time. Apprentices can then become journeymen, and with another couple years of night classes, they can qualify to be a master baker. (The privilege of taking on new apprentices requires additional certifications.) All in all, this amounts to six to eight years of training.

Why do they go to all this effort to train their bakers? Isn’t bread kind of a simple thing? Nope. Baking is a craft, and master bakers care deeply about maintaining a high standard of quality for their products. This system allows guilds to determine what foundational skills are necessary, and then lay out a path for acquiring those skills. Apprentices don’t just learn how to follow bread recipes, but instead acquire a holistic, sensory understanding of math and chemistry and ratios, one so rich that they’ll know by touch whether the bread is done and by taste whether the yeast is fully fermented.

Similarly, the user experience profession has foundational skills that are essential in producing quality work, and user experience problems can’t be solved following a simple recipe. All the pretty wireframes in the world doesn’t do any good if you haven’t nailed down essentials like active listening, storytelling and problem-solving. These are some of the skills that make user experience valuable, and they should be taught and practiced at that foundational level.

What ideas can we steal from guilds today?

How can we bring these principles to UX? We could overhaul UX and institute a guild system, or more immediately, we could look for little things we can do on an individual level, as mentors and bosses, as people with something to teach.

1. Hire for potential

Someone who wants to be a baker in Germany really wants it; it’s their calling and their passion. This is a quality we should look for in UX as well. We should be picky and take on those who have the greatest potential over those who know the greatest number of software tools. We should hire someone who is curious, someone with humility, someone who genuinely wants to learn.

2. Set expectations

In a guild, everyone knows what their role is: the master, the apprentice, the guild organization itself. Similarly, user experience as a field needs to set expectations for these relationships. Mentors understand that in bringing on someone green, they’ve committed to shaping him or her into an accomplished craftsman. They understand their obligation to provide this person with learning opportunities, not just crap work.

Similarly, a good apprentice understands that they are to develop foundational skills and they won’t be rock stars right out the door. These skills (storytelling, problem-solving, listening) are not sexy skills to the untrained eye, but they are really damn important. Someone whose expectations are set accordingly will be absolutely thrilled for the opportunity to develop these skills.

3. Provide mentors

It’s essential that new craftsmen see how accomplished masters handle tricky situations, and receive personal guidance and feedback from those masters when they themselves take on challenges. While it’s not always possible in tough business environments to create a true one-to-one apprentice:mentor model, there are many ways to satisfy the core need to expose practitioners to brilliant problem-solvers and the creative solutions they employ. For example, while pairing juniors and seniors together on projects is actually fairly common, it isn’t always done well. Sometimes the pair opts to divide and conquer rather than doing things together. Alas, it’s not helpful to stick the junior in a back room to churn out wireframes while the master goes to an important strategy meeting.

It’s essential for the junior to see the senior, the master, in action. Equally important is the opportunity for dialogue about and critique of the junior’s work, so that the junior can learn and grow and improve.

4. Build a network

A guild is a network of professionals. If you’re part of a guild, you know all the other bakers in town. User experience professionals also build vast networks of personal connections, and in fact, that’s how a lot of us got our jobs. We should pay it forward and help new people get their own networks started. Don’t be the only designer this person knows, because that’ll just suck for both of you. Introduce them to people, take them out to happy hours, and be creative about helping them grow their networks so that when they leave your tutelage, they have a network to build on.

It’s worth the work

We may not be able to institute guilds overnight, but perhaps we don’t need to. There are things we can do tomorrow as individuals, and every little bit counts. Even if you don’t have much experience yourself, there’s always someone, a student perhaps, who can benefit from your knowledge and experience.

Growing people who are capable of doing all that UX requires is no trivial task, but it’s important. The good name of our profession rests on it, and our ability to work with brilliant, inspiring colleagues rests on it. If we take it upon ourselves to grow our professionals, we wind up with smart, competent people who make functional and delightful things, who are a delight to work with. That’s worth working for.

Midwest UX 2012

Want to know more about this topic? Leanna Gingras will be one of the speakers at the Midwest UX Conference in Columbus, Ohio (US).

Leaders want to see how well an idea works before investing time and money developing it. Leaders don’t want to waste resources. They want to feel confident. They want their investors to feel confident, and their employees to feel confident. They want to know the organization has done everything possible to ensure success and done everything possible to discover concealed opportunities.

Notice the focus on the organization, almost forgetting about the people the organization serves.

Leaders are all about making the organization successful. Organizations, in turn, are all about making their customers successful. Or that’s how it’s supposed to be. Frequently leaders seed the organization with organization-focused goals, and the people you are trying to help become secondary.

Notice, too, that fear of failure and desire for confidence are emotions. The leaders I know would be unlikely to say, “I guide this organization based on emotion.” Instead, most leaders focus on knowledge that will create a feeling of confidence, and frequently this gets defined as statistics, numbers, graphs, and projections.

Don’t fight this. Empathize and turn your insights into valuable material for him or her.

We’ve all heard the word “fluffy” associated with qualitative knowledge. If quantitative research is seen as producing reliable, incontrovertible facts, then qualitative research is seen as the opposite—the soft, made-up, inapplicable knowledge. You’ve probably observed this tacit “definition” a few times. How do we convince people it isn’t true?

The dictionary says quantitative is “measurement describing quantity, as in cost, members, or ages.” Qualitative is “distinctions based on relative characteristics.” Qualitative research involves descriptions, rather than numbers, because the data can be observed, but not measured. For example, in many projects I have observed participants talking about how they distrust sales people and marketing materials because it’s all predicated on “getting money out of me. Of course they’re going to say it’s wonderful and will make my life better. They don’t really know whether it will work for my particular circumstances. What they promise may not be true for me.” There is no way to put a number on that description. Yet it is an observable trend, a philosophy of doubt that many people follow in their evaluation and purchasing process. This trend should not be ignored simply because it cannot be represented by a measurement.

Stories are data with soul

Here’s another way to see the value of qualitative data. Dr. Brené Brown is the author of The Gifts of Imperfection and in a 2010 TED Talk, she has an interesting definition which you can use to persuade people away from strictly quantitative research. She says, “Stories are just data with soul.” I like that phrase. It references both the descriptive, rather than numeric, aspect of qualitative knowledge. And it references empathy. When you can walk in the shoes of other person, make decision like they make decisions, react like they react, then you have gotten in touch with the soul of their being.

Getting outside our routine surroundings takes a little effort. You have to ask for names of people to talk to and find out if they’re willing to talk to you. Much of this can be done by recruiters or social media these days, but I swear you have to get out and talk to people. Don’t let a glass pane materialize between you and the participant (read: camera lens, laptop screen, touch screen). Technology puts us at a remove from the people we want to empathize with. Conversation puts us in their head. When someone suggests, “Set up two video cameras, one at regular speed and one on time lapse to try to find patterns in behavior, and then do some casual shadowing observations without the cameras,” it smacks of being too caught up in the researcher/analyst role. You can only guess at what is going on inside people’s minds and hearts. You must ask them and listen to their stories to find out for sure.

How do we do this comfortably? Harness your natural curiosity about the way other people think. You like making things better—but for whom? Question yourself. Usually you can make things better based on your own perspective, but to understand someone else’s perspective you need to do more than observe and interpret.

Today on Radio Johnny, Jeff Parks talks with Andrea Resmini from the 2012 IA Summit in New Orleans about his presentation “Groundhogs In The Source Code: Navigation as Cross-Channel Sense Making”. Andrea describes the ultimate goal of navigation is that of helping the end user understand the places and spaces in which they interact. Drawing on Hollywood movies like Groundhog Day and Source Code – and classic stories such as Dracula as metaphors – Andrea takes listeners on a quest to help them find their way through a variety of interactions.

Quotes

“I was trying to make the point… when we say ‘navigate’ we really want to say ‘understand’. It seems simple to make but it’s actually very, very complex if we don’t structure the experience of the reward.”

“The people who are actually investigating video games, and in general interactive spaces, are always dealing with how do you look at this – how do you criticize this, how do you look at these [spaces], and how do you theorize…I look at a game, for example, as if it were a story and that’s how I criticize. Whereas another faction says that, no that is not the way as a game is a very peculiar thing and it should be investigated as an actionable space – the story has nothing to do with how we should look at a game…. a number of people are recomposing this fracture [noting] both of these are true…and the way we can do that is the way quests are built.”

“I think the best point for us as IA and UX designers is that quests are actually a way to reconnect fragmented pieces of a narrative into one single cohesive experience. Which was the whole point of the talk since we were talking about cross-channel experiences, which are by definition something that is very fragmented over a number of devices, environments, places, and contexts. Quests seem to be a good way to think about a way of reconnecting something, not just the story.”

Notes

* Follow Andrea Resmini on Twitter @resmini
* 2013 IA Summit announced for Baltimore
* Andrea is one of the founders and Associate Editor at the Journal of Information Architecture
* Thank you to sponsors IA Summit for your support.

The problem, for me, is this: It is becoming just another way for UXers to talk to ourselves about ourselves, and in the process continues to position UX as a tactical discipline with little strategic value.

At its best, it challenges us to bring a “think-make-check” discipline to our projects, thus transforming how our organizations create valuable digital products. As such it is a key part of formulating product strategy. At its worst, it indulges our laziest propensities and reduces creativity to pure production (see David Malouf on The Corruption of Making in Design for an eloquent take on this). To me, there’s way more promise in the former.

In this discussion, I’d like to explore how Lean UX gets us closer to being strategic actors not just more efficient and productive bit players.

The purely tactical

Here’s the stuff that for me is purely tactical, of little long-term consequence, and least compelling; yet these ideas have good traction within our discipline and often dominate our thinking of Lean UX.

Deliverables and documentation don’t matter anymore

Some tendencies within Lean UX treat deliverables and documentation as the equivalent of clerical work, or worse as “waste.” To me, systems with any strategic value to our organizations require you to think through complex user stories. This will require some thought experiments, many of which need to be written down and shared with others who are not part of the small, co-located team. I have to agree with Austin Govella: “Deliverables are not the problem. User experience practitioners are not in the deliverables business. We’re in the business of finding and evaluating problems and solutions.” Sometimes it takes deliverables to facilitate the thinking process.

Further, anyone who has needed to communicate design decisions for a complex set of use cases to a team that is not co-located with you knows that you have to document what is going on. The fact of the matter is that you’re going to do it anyhow. Questions will arise about what happens under different use cases. If you haven’t documented these, then you’ll either miss them in your design (and have to rework), or you’ll end up communicating your assumptions in writing — probably via the ephemeral medium of email — when questions inevitably arise. Just do it formally and get it over with. The extended team will thank you when it comes time for testing. (Yeah, that still needs to be done.)

Prototypes communicate everything

“The prototype now become[s] your documentation. It is ‘the Spec.’ Very little if anything more is needed” (Lean UX: Getting Out of the Deliverables Business). A prototype can be many things, but the complete specification is impossible (unless you’ve embedded notes in it, or you’ve hooked it up to a fully representative database). If the prototype communicates everything, then it is–by definition–the product. You haven’t built a prototype; you built the thing itself. Prototypes work well for getting stakeholders to remember requirements that they “forgot.” They work well to test with users when lower fidelity deliverables won’t do it. They work well to communicate to developers how transitions between screens work. But a prototype can’t, by its nature, cover all use cases. You’re going to need to document the exceptions not covered in the prototype.

Waste is the thing to be avoided

It’s not all about production. To arrive at what is truly valuable, you need to overproduce and throw stuff away. You learn from “waste”. Thought experiments that seriously and honestly engage a complex problem are not waste when they fail. They teach you something about the right solution. That’s not waste. Documentation that helps an offshore development team efficiently turn around code is not waste. It may seem like waste to those who think documentation is “boring” or clerical. But it isn’t waste. Get over it; write it down. The prototype and your sketches are not covering everything.

What’s Old Is New Again

Finally, much of what passes for Lean UX isn’t new, which is why so many UXers claim to have been doing it all along without realizing their business-as-usual approach needed a(nother) brand name. (Check out this blog post.) Anyone who has done a clickable prototype to test some assumptions with real users was doing it. (See @DesignStaff’s recent post, which doesn’t mention Lean UX but makes a compelling case for a UX technique that has existed well before we embraced the “lean” label.)

All that aside, I do like Lean UX

Here’s what makes the most sense to me, and what I have found truly transformational in my own practice no matter the size and complexity of the project.

Business-savvy design

Good, business-savvy design has always been about systematically finding the core features that matter most to users – no more, no less – and finding them at the cheapest possible cost. Design is almost always a process of trying to identify what is really valuable to users and what is less important. Doing it systematically is smart business and good design. Lean UX in this sense is good business..

Moving as quickly as possible through the “think-make-check” loop

Giving yourself time to think about the problem you’re trying to solve is important. But don’t assume you’re right. Spend your “thinking time” figuring out what you need to learn and what you can build to get the right answers. This is the work of a UX strategist. Writing down hypotheses and describing how you’ll validate them is hard work that is valuable whether you’re consciously doing “lean” or not. Some of those hypotheses will not be strictly related to UX. Some of them may go the heart of the overall Customer Experience your organization is trying to create. Knowing when your invalidated hypothesis is more than a system issue is an important strategic skill. You’re going to need to communicate that — with a deliverable, in writing.

Creating the most effective, least-cost deliverables to yield “validated learning”

The “Minimum Viable Product” (MVP) concept is central to Lean Startups and Lean UX. Though it is often confusing, it’s valuable. Designing just enough to deliver value and learn what to do next is also smart business and good design. As a discipline, we UXers don’t typically think too much about cost and benefits. We’re not typically held accountable to profits-and-losses. But MVP’s are a good discipline for us — they make us think about how to cost effectively make good decisions. They reduce product strategy to its fundamentals — what features move the business forward, fastest. That’s not typically the way we think.

These are the parts that I find useful and valuable no matter the size of the project. Whether it’s a startup or a large organization, there is always uncertainty and the opportunity for validated learning. Lean UX gives you a way to systematically deal with the uncertainty.

More important for UXers, it gets us closer to product strategy. Focusing on cost-effective ways to reach a market, creating a competitive differentiator, introducing a true innovation, or discovering that your company’s assumptions about its customers are wrong — these are strategic outcomes that will require deliverables beyond prototypes. Those deliverables (formal or informal) are where the strategic thinking gets done and communicated. Don’t give them up to someone else. Relegating ourselves to pure production is to further constrain the UX discipline as a subset of IT. That’s not where, I think, we want to be.