On delegating work better

When delegating work, it isn’t enough to pick a good person and give them

Fellow leaders and managers, I want to share with you thoughts on a skill that we all know we should do better, but that often gets little attention: delegating work.

Summary: Delegation as coaching

Of course delegating work effectively requires the manager to provide instructions, set expectations, choose a suitable delegate, and check-in.

But what if as managers we then shifted our attention away from the delegated work itself and onto the delegate’s level of mastery of the work, levels of mastery like first mimicking, then understanding, and then innovating? We could then know better how to coach the delegate while he or she gains greater mastery over the delegated work.

When I think of delegating like this, it becomes more of a process with a delegate than a work assignment. This will require more time from us in the short term, but in the long run, having masterful delegates will be much more valuable and time saving.

What follows in this post

  1. Delegation 101
  2. The flaw: Abdicating instead of delegating responsibility
  3. Coaching delegates to master the work

Delegation 101

Much has already been written about the basics of delegation. Here is some background reading.

From those readings, which I encourage you to review, I’ve boiled down a basic delegation flow to this:

  1. Choose what responsibilities you’ll delegate to another person
  2. Choose a person who can do the work and who you  trust with the responsibilities and authority
  3. Assign the work using clear instructions and expectations, allowing the delegate the latitude to meet those expectations in his or her own way
  4. Inspect the work as needed
  5. Be thankful and give credit

It is worth remembering that the delegation process assumes that you already know how to do the work and understand the responsibility. If you just know that there is a problem to solve, but you haven’t really figured it out, delegation is premature. That’s an entirely different kind of work.

But that’s just basics, and while they are crucial, we can deepen our understanding even more.

The flaw: abdicating instead of delegating responsibility

In his book about entrepreneurship and creating a successful business, The E-Myth Revisited, Michael Gerber talks about the difference between abdication and delegation.

Gerber illustrates the point in a young manager’s life when he has too much to do and finally hires someone to help. He gives the accounting books to that assistant and suddenly feels free! The manager happily lets the assistant keep the books and shifts focus to other work. Only later does the manager realize the assistant has been doing the bookkeeping in ways that he never would have, and sees that the business is really beginning to suffer for it. That’s management by abdication.

Books like First, Break All the Rules, have emphasized the importance of setting clear expectations for outcomes, not micro-managing. Great advice, right? However, in my experience, there are some types of work for which the process of the work is itself valuable (those in the user experience field will agree, I think). If I only manage the outcome and not the process, I may really be missing out. Again, Gerber’s abdication.

So if we’re going to delegate effectively, not micro-manage, but instead manage by remote control, and still end up with the work done as well as we hope, we do need to know something about teaching the performance and assessing how well the delegate can do the work and what we should expect.

Coaching delegates to master the work

Let’s talk about a model for considering mastery, Shu Ha Ri. Some Agile development thinkers have adapted this concept to software development skills.

English-speaking martial artists have used the translated terms of following, detaching, and fluent, but since we really are moving away from the hand-to-hand nature of martial arts towards more general mastery of work, I prefer mimic, understand, and innovate.

  1. Shu = following = mimic
  2. Ha = detaching = understand
  3. Ri = fluent = innovate

I’ll be the first to call it out: this is a weak model for thinking about such a complex topic as mastery. But it has its uses.

When we delegate work as managers, we can use this model to assess how advanced the delegate’s mastery level is for the work.

For example, let’s use the task of creating a visual sitemap for a website.

To mimic the work is to copy the form of another sitemap and apply it to the website at hand. The layout is similar and the annotations on the map indicate the same analysis as the copied sitemap, even if that analysis isn’t really relevant in this new case. Mostly, it just looks about right and is probably helpful.

To understand the work of creating a sitemap is to include relevant annotations about the organization of content, to tune the layout so related content are near each other in the map and levels of hierarchy are implied by position on the page, and to know how to use it in discussions with members of the team.

To innovate in the work of sitemaps is to create a more appropriate visual vocabulary for the diagram and to show connections drawn from other representations of content, such as content inventories of the same information space to expose relevant facets or perhaps the amount of content in a section, or website analytics to show, for instance, popularity of pages on the sitemap. This kind of innovation work, well executed, should be even more valuable.

For any work that you manage, can you outline what those three levels might look like? With that information in hand, it becomes easier to ask how much mastery you want from a delegate, and of course to see how advanced the delegate is in their mastery.

This model can be a valuable coaching tool for any manager, and adds useful insight for anyone who needs to delegate well.

 

Will St Charles MI flood in Spring 2014?

I’ve lived in St Charles, MI since 2008. It’s a nice little town, I think. One of the features is the confluence of the North and South branches of the Bad River, pretty much right in the middle of town.

Satellite map of St Charles, MI. Note the two rivers that join up just East of M52.
Satellite map of St Charles, MI. Note the two rivers that join up just East of M52. With so much snow this Winter, and not many warm days to melt much of it, what will the river be like in the Spring?

So, it has been a pretty cold winter with what seems like a higher than typical snowfall. In the past, I’ve seen the Bad River push pretty well at its banks. Last Spring there were a few local roads that were closed because of water spilling up onto them. The storm drains can’t drain a whole lot when they are full.

Snowy street and snowbanks along driveways
A snowy street in St Charles, MI in early February 2014.

So, I don’t think this will be a record-breaking winter for snowfall amounts. My best prediction is that we’ll end up with around 40 inches this season, which is really no big deal. (And I’m no meteorologist, so don’t trust me at all on that prediction.)

But here’s what I’m wondering. If the temperatures stay cold, then not much of the snow will melt. Then, when it warms up, probably in March, a whole lot of snow will melt really quickly, and the Bad River will swell more than we’ve seen in recent years.

Will we have a more serious flooding of the Bad River? I wouldn’t be surprised.

Five Whys, Socratic Method, and Dependent Arising

Root cause analysis—jargon for managers in lean startups and Agile dev shops. In plain language, isn’t it “Well, I hear what you’re saying, but what’s really going on?”

I feel a rambling, messy first draft coming on.

Why in the world do we need jargon for such a common line of reasoning? This is every day stuff, isn’t it?

  • Parents ask each other in whispers at night: “But why is she acting out like this all of a sudden? Is it those kids at school again?”
  • A doctor sees the symptoms and begins to diagnose the cause.
  • Marriage counselors around the country today coached couples to understand their partners a little better.

Yes, and an Agile team somewhere held a 5 whys session to figure out how that persnickety bug made it through testing, so that they could address the root cause.

Oh, pardon my cynicism, I have trouble writing that line with a straight face; if the team didn’t actually discern the root cause (there’s always just one, right?), they will have at least changed something to avoid one of the causes. How else to get better, really?

I’m being too jaded. Of course root cause analysis, the 5 whys method is one tactic for such analysis, is important. I just cringe at the assumption of a single cause for problems. And those technical problems that are found with lean and agile work often end up (or is that start off as) being human problems, and those are rarely so singular.

In design work, I really don’t know that I’ve asked the question, “So, what is the root cause of this problem?” Though I have most often sought to understand and clarify the problem space, the context, the people involved, their desires and motivations, the corporate interests, et cetera—you know, the basic stuff a designer needs to know in order to actually do good work [PDF].

I simply cannot right out of the gate assume I know what I don’t yet know so well that I would presume it, if it is indeed an it, is a singular problem. The result of that kind of simplistic framing would tend towards imprecise assumptions and lack of multiple perspectives. A lack of understanding. And don’t those sound like further problems that could result in errors? Garbage-in, garbage-out.

So, if I can kick the feet out from under Agile’s dumbed down root cause analysis and just stick with something more like defining the problem, or semantics (as Vignelli has used it), I’ll relax on this point.

Can I assume that this better understanding is what we’re all actually after?

I was in a meeting once, asking deeper questions, and a person I was talking with was frustrated and said something like, “I know all about five whys, I know what you’re doing!” The person was asking me to back off, because he wasn’t prepared to answer questions. While that does make the point to me that I was pushing too hard, I wasn’t expecting the five whys remark.

I was actually patterning the discussion more off of Socrates and his dialogues. I’ve heard the term Socratic Method being described as continuing to question, to ask why. Well, yeah, that sounds like a 5 whys, but I’ve read Plato enough that I understand that those dialogues are far more nuanced than a series of whys.

Wasn’t the philosophical discourse of Socrates and his learned colleagues some sort of root cause analysis too? Is a discourse into the nature of the soul and idealized Forms an analysis? Of course, and there is an aspect of Phaedo that suggests that these Forms are in fact causal forces. I’d call that root cause analysis.

So, this type of “what’s really going on here?” question isn’t just for work any more, it’s for philosophy and an understanding of the world itself (yeah, even though we all believe Socrates had it wrong).

And this question of the underlying problem is common too in religion, isn’t it? What’s wrong with the world? With us humans?! I call a five whys for the fallen world!

I joke, but Buddhists might associate this notion of root cause analysis with another bit of jargon: dependent arising.

As I’ve learned, when Gautama sat in profound ascetic meditation under the Bodhi-tree, nourished by an offering of rice milk, and under the gazes of the gods of many world-systems, he finally received enlightenment. In his awakening under that auspicious tree, he knew what are called the four noble truths (knowledge of suffering, cause of suffering, cessation of suffering, and the path that leads to that cessation).

And yes one of those truths, central to a major world religion, is the root cause of suffering! (Oh, if only an Agile 5 whys was so profound!) The cause of suffering is actually described as a nested layering of causes, which finally reach that singular kernel that causes suffering (duhkha). This is the notion of dependent arising, that suffering arises dependent upon all these other links in the chain. When I read the series of links, I still don’t think it comes down to a simple answer, but the answer itself isn’t the single cause, but the whole chain of dependent arising is part of it. You don’t disassemble it so much as sidestep the whole chain. And yes, that’s quite an oversimplification. Here’s a bit of that root cause analysis as dependent arising (there are 12 links/nidana).

Conditioned by (1) ignorance are (2) formations, conditioned by formations is (3) consciousness, conditioned by consciousness is (4) mind-and-body, conditioned by mind-and-body are (5) the six senses, conditioned by the six-senses is (6) sense-contact, conditioned by sense-contact is (7) feeling, conditioned by feeling is (8) craving, conditioned by craving is (9) grasping, conditioned by grasping is (10) becoming, conditioned by becoming is (11) birth, conditioned by birth is (12) old-age and death—grief, lamentation, pain, sorrow, and despair come into being. Thus is the arising of this whole mass of suffering.
(Gethin, The Foundations of Buddhism, 141-142)

This doesn’t strike me as mono-causal, even though it sounds like it at the end of the chain: death results in a whole mass of suffering. Well, how do you get rid of death, then? Will you get rid of birth?

Right, and so the whole tangled up ball of yarn gets pulled along. There are many causes, and there are many results. This strikes me not just as dependent arising, but interdependent arising. Duhkha, I shake my fist at you!

So, again, this root cause analysis thing is all over the place: work, family life, health, philosophy, religion. But doesn’t it tend to not be simply understood as singular causes? (Christianity seems easier to me, until I try to put a finger on where exactly original sin came in: fruit, gullible Adam, Eve, serpent, why was the tree there to begin with? It gets messy too.)

Let me end this rant, I mean blog post, by saying simply, using terms that suggest we think of single causes to complex problems is foolishness and it bugs me.

(Oh, and the 5 whys method looks a lot more like dependent arising to me than the Socratic method.)

UX STRAT conference, day 2

I just wrapped up the day by having dinner with Simon of Bristol (okay, Simon Norris of Nomensa) and Bob Royce and Dan Klyn of The Understanding Group. A relaxed conversation with three brilliant gentlemen—an excellent end to the day.

So, the conference. First, I was glad to have met Josh Seiden in person so that I could apologize for my choice words about Lean UX in the preceding blog post. Josh is legit.

As for the topics, again, too many for me to itemize, so I’ll first do a top-of-mind review and then think about themes.

Top-of-mind reflections

First, Aarron Walter of MailChimp blew me away with the approach he shared about using Evernote with e-mail as basically an API to take a very real step at solving the data silos problem. Sure, this may not have been pure strategy, but as a tactic, wow. Thank you Aarron.

Doodles about Aarron of MailChimp's talk on using Evernote to connect silos of data
Sharing these notes in case they help someone else remember the talk better. Click on the photo to view it larger.

Heads-up to my team, we’re going to give this a whirl.

Second, Ronnie Battista had the whole room laughing repeatedly. Awesome presentation style, and great ideas on “The Ten Commandments of UX Strategy.” (Where is our Hippocratic Oath?)

Okay, there you go for top-of-mind.

What was missing?

So, back in the late 1990s I thought of information architecture as something akin to strategy, and we didn’t have the label “user experience.” (At least if we did, I was still too ignorant.) Then IA lost its way amidst all the insane growth of the web, related technologies, and professions. (Yep, I’m over-simplifying history.) I stopped thinking of myself as an information architect and eventually replaced my self-identity with user experience.

Then a few years ago a new generation of information architects began to speak, and among them is Dan Klyn. Dan and his cohort have knelt around the dying embers of information architecture and breathed life back into it, adding tinder, twigs, wood.

IA is starting to throw off heat and light again, and thank goodness for that.

And you know what? This new framing of information architecture looks even more like strategy to me. Now, it isn’t strategy any more than design is strategy—but they overlap in meaningful ways.

Let me put it this way, if I had a performance continuum describing information architecture with one end called strategy and the other tactics, I’d probably describe IA by putting a mark halfway to strategy. (Is that “strategy yet tactics?”) If I used the same continuum to describe UX, I would regretfully right now put the mark on the half towards tactics.

Performance continuum, isn't IA more strategic, UX more tactical?
This is just my gut talking, and isn’t based on any deeper study or rationale. When I’m doing more strategy-level work, I find myself frequently reaching for IA methods and frameworks, not more generalized UX facets of the work. Curious about others’ thoughts.

So, whether IA and UX are cooperative siblings or one contains the other (or they overlap, but not fully), UX strategy seems to me like it ought to sit down and listen hard to what today’s information architects are doing.

Or, hey, maybe we as a UX strategy tribe think that “good” is tactical, yet strategic, not the other way around. Seriously.

(End of that editorial.)

Themes from Day 2

We need data. We need to get it and use it. It is part of the language of business.

Stories and data together can be compelling.

We need to continually adapt UX strategy to corporate strategy in order to stay relevant to the business.

We need to be ambassadors, reaching out to our partners within our businesses. Seek to understand them, even serve them, and build those connections.

Learning is part of culture. We need to continually learn. Be bold in being okay with change (think of Dick Fosbury and how he changed how the high jump is done).

The DIKW pyramid, getting to Wisdom is hard!

UX strategy includes shaping our teams capabilities in ways that will best serve the business.

Customer Experience is often populated with marketing professionals. Are they a group to compete with or a group to align with? Should we just admit we’re all doing the same thing, only that we’ve been doing it longer? Or is there really a difference?

UX strategy does include organizational change (overlapping with changes to an organization’s culture). Think the Vistaprint center for excellence, the innovation program at Citrix, and the leadership changes at Sage over a few years.

Done

And, I’m spent. It’s been said, but can be said again: UX STRAT team, fantastic job. Thank you for all your time and effort. It was worth it.

UX STRAT conference, day 1

The first day of the UX STRAT firehose of talks is over. At the Barrelhouse, a nearby bar, there no doubt are still a few gathered after happy hour. I think Paul Bryan, the organizer, can count this first UX STRAT a success already.

I’m not a huge fan of crowds, so instead of happy hour with attendees, I spent the evening after the conference catching up on a little work, and then I walked down to a lovely restaurant called Empire State South to pass the time enjoying good food and reading a book I brought along. I had the Painted Hills Ribeye, a glass of pinot noir, and a cup of decaf for the walk back: All of it brilliantly done.

So, there were too many talks for me to hit each independently. Instead, let me describe some themes that I think are important.

What do we mean when we say “UX Strategy?”

UX strategy as talked about today could be at any of these levels: corporate strategy, service design strategy, product strategy, and something like the tactical, single-channel work that lean UX tends to do (sorry Lean UXers, just calling it like I see it).

We’re going to have to get clear on the meaning of this phrase.

Honestly, I wonder if there is no such thing as “UX strategy,” but there is instead bringing what UX knows to each of the various kinds of strategy. So, we already do strategy, but now we need to reshape it with user experience-driven insights.

Quantitative vs Qualitative (or is that Left Brain vs Right Brain?)

Amidst all the talk of what design can teach business, what business can teach design, politics, and silos, the basic notion is that we in UX have some awesome methodologies that map directly over to strategy level work.

The idea that Nathan Shedroff shared about doing a SWOT analysis not based on the opinions of the stakeholders, but instead based on research with customers is a spot-on example of this. That is, incidentally, brilliant, and makes me want to get a do-over on the past two weeks of work during which we did some strategic planning for next year.

Leah Buley from Intuit illustrated practically utopian example of a strategy project in which a corporate strategy team did what they are strong at and a UX strategy team did what they are strong at and together ended up making good organizational and strategic change happen at Intuit. So what were the UX people good at? Customer insights, ideation (yes I used that non-word), creating visuals to show what the future could be, and facilitating the bejeezus out of people. Hats off to you Leah, and congratulations on an epic win.

In general, this is obvious stuff, right? Maybe not, but it should be. I’ve heard today that design is strategy, in some ways.

Well, my experience says that design is also decision making. What do you need to make good decisions? Real understanding of context, perspective from customers and others, posing possible solutions, prototyping ideas so we can get our heads around them better and so we can see the pros and cons of them, getting teams on board, getting traction, getting action, delivering value, and it all takes facilitation skills.

Okay, so that stuff is thick in design work, right? That is also what good decision making activities should look like, and making decisions is a big part of what business leaders have to do. (Nobody talked about that today though.)

Lean UX

Lean UX has come up many times. I’m still trying to figure out why this comes up in a strategy conference, as Lean UX is a methodology that describes HOW to do the work, not what to do.

Now, of course Lean UX people will say something like, “No way! Our hypotheses and tests are how we know what to do!” Baloney, unless you are talking about UX strategy at the product design level. In that case, sure. Knock yourself out, Lean UXers.

Also, while you could evaluate a business model in Lean UX terms, that works way better with a non-existent product than one that already exists. The amount of work it would take me to get us to really take on a Lean Startup mentality with an already existing product just isn’t worth it.

Further, Lean needs small batch changes and easy hypotheses. I actually love that idea. However, I’m concerned from a service-level design with touchpoints that exist across many, many channels, and I don’t have the buy-in (or resources?) at the moment to orchestrate service-wide changes, even though real holistic improvements to the services will require that kind of work. So, we have situations where we could have a hypothesis about an improvement to one channel, but because the other channels that are also used in the overall experience wouldn’t change, the hypothesis will prove false, but not necessarily because it was a bad idea; it just didn’t account for adjacent touch points.

Basically, if all you’re working on are the trees, Lean UX is probably awesome. But we have a forest to deal with.

Wow, I didn’t intend to rant. I really didn’t have that much wine…and maybe I’m totally off-base about Lean. That’s possible, because the example of Paypal using Lean UX surely must account for multi-channel design, even though I don’t recall it being mentioned.

The power of story, the power of shared work

“Culture eats strategy for breakfast” was a line passed on by Tim Loo today. Yep.

To change culture, do you change thinking? No, you change behaviors, which then lead to new thinking. Think BJ Fogg’s notion of designing behavior. How? Workshops. Teaching design facilitation and thinking skills to product managers. Getting whole teams to observe usability tests not just for insight, but to build empathy and perspective for customers. We know this stuff already, right? This is about doing it.

The seat at the table

Shedroff used the phrase a couple times that UX thinks it deserves a seat at the table (think boardroom/strategy/decision-making table). Well, I get the notion, but I don’t like the idea that we deserve it. First off, we do need to be there because the insights and the methods we bring are strangely lacking there, but we also need to earn that seat.

Good design work cannot help but back its way into strategic thinking. It’s inherent in having to understand the context and pragmatic value of the design itself. If there is a strategy ladder, of course user experience will be in a position to see it and desire to climb it. And it isn’t a self-serving desire, it is in service to the business and to the end-users. There will be moments in design when we look at the whole situation and realize that the problem is with the business model or the corporate strategy, not with the design of the offering.

What, oh dear conscientious UXers, are we to do then? This is, I think, behind so much of the “seat at the table” idea.

Looking forward to day 2!

So we have tomorrow’s proceedings, then I’ll spend a final night in Atlanta and fly back to Michigan on Thursday morning.

UX STRAT conference, workshops

Lake in Piedmont Park
I went for a walk when I got into Atlanta, really looking for a cup of coffee and I also found a park. There was a foot race, people biking, and families strolling amidst the trees. Lovely.

I’m at the UX STRAT conference in Atlanta, Georgia, having just finished a couple of half-day workshops. Here are a few observations.

  • From what I overheard, attendees mostly have job titles including “manager,” “director,” “lead,” and “senior.” Oh, and owners of agencies/consulting firms.
  • In spite of that (cough), like most UX people, they are interesting to talk with and open about sharing their own knowledge.
  • Numerous people handed me business cards, expecting me to reciprocate. I had to explain that I didn’t like the ones I had so I threw them away, but the newly designed cards haven’t arrived yet. (I am not odd about this, dang it!)
  • More attendees than I expected are from overseas. So far I’ve heard Netherlands, UK, Finland, and Mexico.
  • Nice lunch and service. For instance, just as the woman sitting to my left realized she sat down without a fork for her dessert plate, a server was at her side with a new napkin and a fork. It was as though he was watching out for her. That’s better service than I expect at a conference luncheon.
  • Lovely options for meals around here.

Morning Workshop: Beyond Business Basics with Nathan Shedroff

Well, I have more copious notes, but I’ll hit a few ideas here. First, Nathan did a wonderful job with this information-packed session. I honestly felt at the end of this session that I had enough value to make the whole conference fee ($949) worth it. That’s saying something.

I think part of why it was so valuable to me is that I am actually able to apply a whole lot of what he shared, given the position I’m in. Also, much of it I’ve already done or experienced, but his perspective helped me think about my experiences as an executive, a researcher, and a designer.

So, Nathan roughly had a couple major areas of the presentation:What design can teach business and what business can teach design. Along the way he shared a number of tools for getting design research insights baked into strategic planning. As he explained the tools and frameworks, some were work I’ve already done, and others made me want to slap my forehead and wish for some do-overs over the past few weeks. That’s good.

So, in regard to what design can teach business, some of the key items he listed were being okay with ambiguity, reframing, and prototyping, and the idea that some of the greatest things about experience are hard to describe and measure, but that doesn’t mean they aren’t valuable.

He took some pot shots at the MVP (minimum viable product) suggesting that consumers don’t live in a world populated by MVP services, so releasing one isn’t going to help you be competitive. A generality of course, but I agree. The problem with MVP is that it is actually so rarely truly viable. And when you release an MVP, you then have the work of convincing the people you work with to go back and change (that’s really hard and often fails, in case you haven’t yet experienced that).

Shedroff didn’t really provide any answers to that problem, although the next speaker did. But that’s for later.

In regard to what can business teach design, here are some notes.

  • Numbers are important, not scary. You can prototype a business proposition using an Excel spreadsheet. Numbers are a design tool.
  • Data informs creativity, but doesn’t drive it. It isn’t the whole story, and it can’t tell you what to do.
  • He mentioned three levels of strategy: Corporate Strategy, Market Strategy, Product Strategy.

A quote from Charles Eames: “Design is a plan for action.” Doesn’t that sound like strategy too? Is design also strategy?

He provided an interesting example of corporate strategy from, who else, Apple. Apple had already produced the iPod and was making bank. Then they make an observation: people like to have only three things in their pockets: keys, wallet, and other. The market already had numerous options for “other,” including iPods and mobile phones, and other business indicators were showing that phones were going to win. This then predicted that the iPod was going to drop in popularity. So what did Apple do? They partnered with Motorola and produced the co-branded RockR mobile phone which had iTunes on it. Epic fail. So lacking a better solution Apple decided they had to get into the phone business, and now we (and they) have the iPhone.

Shedroff did a great job of showing that most corporate strategy is done without perspective gleaned from design research, and, you know what, I have to say that I have failed at this area, and I honestly have no good excuse for it. (This is one of those slap my forehead moments.) It isn’t to say that design research has been completely absent, because of course it hasn’t. I’m a UX person after all. But it really hasn’t shaped strategy like it ought to.

Nathan provided a model for how to do this using frameworks that are pretty familiar to business people. At the core of it is the notion of getting to the psychographics of the market considering environmental issues of:

  • customers needs and desires
  • political/legal
  • technology
  • economic
  • industry-specific

In the user experience methods for design research, we already have the know-how to find actual real answers to these issues.

Another interesting point, total value is composed of five values:

  1. Functional
  2. Financial
  3. Emotional
  4. Identity
  5. Meaningful

The first two are largely quantitative and the other three are largely qualitative. Since business models typically include the notion of “value proposition,” and UX ought to already have a decent handle on items 1, 3, 4, and 5, we sure ought to provide some insight to the business model.

Incidentally, some of these ideas reminded me of “Emotional Design” by Donald Norman as he describes layers of visceral, behavioral, and reflective design.

Nathan spoke of a set of 15 meanings (e.g., trust, security, accomplishment) and demonstrated a neat interview technique (I think he called it “laddering”) to uncover a sense of what someone’s more important meanings are. As he did this, I realized that I have instinctively done this with people before in interviews, although not as quickly as he did, and without having a list of meanings to compare against.

Nathan suggested that a technique for this would be to uncover the most important aspects of meaning for customers, company, team, and competition as a way to audit the business and inform strategy.

Redesigning Business Culture and Thinking Around the Customer with Tim Loo

Now that I’ve written more than I anticipated about Nathan’s session, I’ll try to write less about Tim’s. (Sorry Tim! Or maybe that’s good…)

Tim is a wonderful presenter, engaging and promoting good discussions while making his points. He changed his plan for the workshop in light of how the interactions with the group were going, and I think he probably made the right call.

So, his definition for UX Strategy? This: Long term vision, roadmap, and KPIs to align every customer touch-point with your brand position and business strategy.

Now, that sounds incredibly boring, right? Well, it wasn’t. He demonstrated numerous examples of how to communicate design strategy and align stakeholders to them.

Some notes I took on this cover tactics like:

  • video of a customer story, written, storyboarded, and produced based on insights from design research
  • holistic experience maps (service design blueprint or perhaps customer journey map)
  • research insights report
  • workshopping to process results and get stakeholders working together

I asked myself, do we have experience design principles for our offerings, and concluded that we do not, but ought to. In here and in the future customer stories (next paragraph) are a bit of the key to defining what “good” means for a product, as opposed to the MVP notion. (This concept of “good” made me think of performance continuums as explained by Dan Klyn from The Understanding Group.)

Tim also shared examples of future customer stories as a way of selling the design principles and as a way of helping to create and drive a product roadmap. This is basically just a storyboard of key experience points and outcomes.

Generally, a lot of his talk was around the notion of using stories and collaboration to get stakeholders to share customer perspectives, which will then shape their thinking when it comes to strategy.

Thank you Tim for a wonderful, rich talk!

Looking forward to the rest of the conference

Really, this is shaping up to be a conference that will be well worth the time. And Atlanta is great. I’m looking forward to connecting with Dan Klyn sometime in the next couple of days, which is funny since we’re both from Michigan and somehow it takes a conference in Atlanta for that to happen. Clearly I need to adjust my priorities!

Twitter Feed of #uxstrat


Assange, Snowden, and Stallman as, um, heros?


#freedom ?!! YES WE CAN :) #Stallman #Snowden #Assange  on Twitpic

(Photo of Richard Stallman and Julian Assange holding a propaganda photo of Edward Snowden)

Bruce Sterling wrote up a long-winded editorial “The Ecuadorian Library” that covers a lot of ground and ends up posing Richard Stallman, Julian Assange, and Edward Snowden as moral heroes against the State Department and NSA as antithetical to democracy.

Here’s a particularly lovely excerpt from the article.

People, you couldn’t trust any of these three guys to go down to the corner grocery for a pack of cigarettes. Stallman would bring you tiny peat-pots of baby tobacco plants, then tell you to grow your own. Assange would buy the cigarettes, but smoke them all himself while coding up something unworkable. And Ed would set fire to himself, to prove to an innocent mankind that tobacco is a monstrous and cancerous evil that must be exposed at all costs.

And yet the three of them together, they look just amazing.

While I’m yet unsure of my position on and generally suspicious of all these parties, I’m sure The Ecuadorian Library by Sterling is worth reading.

UX described by Socrates

Lately I’ve been reading from Philosophies of Art & Beauty: Selected Readings in Aesthetics from Plato to Heidegger, edited by Albert Hofstadter and Richard Kuhns, and read a passage that sure sounded a lot like a premise of user experience work.

This is from Plato’s The Republic. Socrates is dialoguing with Glaucon about art.

Of the painter we say that he will paint reins, and he will paint a bit?

Yes.

And the worker in leather and brass will make them?

Certainly.

But does the painter know the right form of the bit and reins? Nay, hardly even the workers in brass and leather who make them; only the horseman who knows how to use them—he knows their right form.

Most true.

And may we not say the same of all things?

What?

That there are three arts which are concerned with all things: one which uses, another which makes, and a third which imitates them?

Yes.

And the excellence or beauty or truth of every structure, animate or inanimate, and of every action of man, is relative to the use for which nature or the artist has intended them.

True.

Then the user of them must have the greatest experience of them, and he must indicate to the maker the good or bad qualities which develop themselves in use; for example, the flute-player will tell the flute-maker which of his flutes is satisfactory to the performer; he will tell him how he ought to make them, and the other will attend to his instructions?

Of course.

The one knows and therefore speaks with authority about the goodness and badness of flutes, while the other, confiding in him, will do what he is told by him?

True.

The instrument is the same, but about the excellence or badness of it the maker will only attain to a correct belief; and this he will gain from him who knows, by talking to him and being compelled to hear what he has to say, whereas the user will have knowledge?

True.

Sounds like UX, doesn’t it? Maybe something from Don Norman about system image and mental models?