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


How to write better personal work goals

As managers, we require our employees to set goals, and then we measure them against those goals during annual performance reviews. While this is common and sounds reasonable, the goals often end up disconnected from real performance.

This is a waste. (Managers: it’s okay to nod your head in grim agreement.)

Why does goal-setting fail, and what can we do about it? Well, I connected a few dots recently, and have a plan. It requires us to rethink the shape of the goals themselves.

How workplace goals typically fail

This is a real 6-month goal from an employee from about two years ago.

Maintain weekly focus on defining billing business rules.

Not bad, right? Seems do-able. There’s a time-frame. The action is simple: to maintain focus on the topic. It basically means get work done on it every week.

But here’s the thing: That goal failed, but by no fault of the employee.

Instead, that project to work on business rules was scuttled by management (okay, I confess: I did it). So, according to the preset goals for that period, I would mark the employee as having failed that goal. Well, I couldn’t in fairness do that! So while I didn’t penalize the employee, the goal itself became worthless.

I trust that other managers out there agree that this is not an uncommon situation.

I’ve found that my employees’ goals fail most often in these two ways.

  1. The goal is based on a project, but the project changes or is even canceled.
  2. The goal requires another person’s action, but that other person doesn’t take the action.

Is it always a simple dependency problem? Not purely. There are other factors, such as the goal being too large to get done or too generic to measure. In that case I shrug and make my best estimation as to whether it was met.

Another problem is that goals sometimes aren’t that important. We dumb them down to something that we’re sure will happen anyway, but it ends up having little to do with the most important work.

Why would we do this? It’s a play-it-safe reaction to being beaten up by all the previously failed goals. Name it: dysfunction.

But should I gauge an employee’s performance based on unimportant goals? Of course not. That’s small-minded, desperate thinking, yet our typical goal-setting systems prod us into those sorts of goals.

So, let’s see this from the angle of sports goal-setting.

Since 1990 I have been a competitive pistol shooter. Goals are pretty important—and effective.

In that sport, I use two types of goals: achievement and process goals.

My achievement goals are based on scores, and are obvious. For example, at the next match, my goal is to shoot at least a 2430. When I shoot a 2440, I know that I’ve achieved that goal. Easy to track.

But what can I do to make that achievement happen?

That’s where process goals come into play. For this, I point to Lanny Bassham’s Mental Management program outlined in his book “With Winning in Mind.” The book is worth reading, especially if you compete in most any sport.

Couched in the methodology from Bassham, let me explain a process goal that I use when target shooting.

In preparation for firing a shot, I plan and visualize the shot, then I do it. Here are some details.

  1. Gun is on the bench, and I’ve already settled my stance and grip.
  2. I look down at the gun, glance at the rear of the gun and see that the bolt is forward.
  3. I focus my eyes on my gunbox, which is with me at the shooting bench. I’m probably seeing a cut-out X-ring, and a step-by-step shot plan I’ve taped to the inside of the box.
  4. I close my eyes, tilt my head up just slightly, and breathe in and then out, fairly deeply.
  5. As I’m breathing I visualize the gun raising, my eyes finding the sight picture, I see a good sight alignment as the gun is rising, as I start to exhale I settle the gun so the sight picture is aligned to the target at which point my breathing pauses. I confirm that my middle and ring-fingers are putting pressure straight back into the grip while my thumb is lined up parallel to the barrel towards the target. At the pause in breath, I continue maintaining solid sight alignment to the slow count of 1-2-3 as I’m applying smooth, straight-back pressure to the trigger. I don’t get to 3 because the gun has fired and I know it is a good shot.
  6. Then I open my eyes at the end of an exhalation and act out what I just visualized. (If I get to three, I put the gun down and start that shot over.)

So, my process goal is to do that for every shot. It’s an easy-to-do goal that I control, and it is up to me to do it each time. When I do, the results are unmistakable.

That’s the key. When I have the discipline to do that process goal for every shot, my overall performance goes way up. It’s a behavior that I can control that produces a result. This past summer I shot my best 50 yard slow-fire score ever, a 97 out of 100, doing that.

What if I can use that kind of process goal at work?

I was re-reading Bassham’s book as I was mulling over these ideas, and came across a section where he writes:

A habit that separates the top five percent of competitors who win from the other 95 percent who just play is the practice of carefully setting goals. Most people never set them. No surprise there. However, every major corporation sets goals. Every government sets goals. Every builder who builds has a blueprint. Every banker has a written contract on how the borrower is going to pay back the loan. But among individuals, normally only the super successful ever bother to set personal goals and plan their work. (“With Winning in Mind,” Lanny Bassham, pp. 65-66.)

So I wondered to myself, “You’re doing alright professionally, do you set goals?” And it dawned on me that I do, all the time.

I just never think of them as goals. This was the Ah-ha! moment.

So, for illustration, here’s what I already do.

My 2013 Strategic Objectives

Near the end of the year, I review my own annual strategic objectives and identify those that I have for the coming year. I do this in order to maintain a clear head about work.

  • UX: Mature the UX team’s expertise
  • UX: Improve the sustainability of UX @ CE
  • Company: Ship (That one word to me means delivering valuable updates to our services for the benefit of our members. But in notes to myself, I just write “ship.”)
  • Company: Learn to manage the business better
  • Company: Prepare CE for future growth

I know these are not attainable on my own, but I expect of myself to influence our corporate progress towards those objectives more than one might imagine. They are generic enough to leave the tactics open, but clear enough to me that I can look at any period of time and tell if I’ve seen the rate of improvement that I’m okay with.

I’ve done this same thing for 2011 and 2012, and I’ve seen the benefits for the company, although from the outside it must be difficult to see the connections.

These annual objectives provide me some needed focus and an ability to feel like I’ve actually made a difference. Without that, I’d be pretty grouchy.

My Process Goals

When I read that section in Bassham, I suddenly realized that I already have process goals, but I’ve never thought of them as goals. I just know to do them in order to be effective at the level I expect of myself.

Photo of my notebook showing a prioritized daily list.
Using a daily 6-item list is one of my process goals. A simple, thin, pocket-sized notebook is extremely handy for this. I’ve found it better than using apps on my iPhone.

My most frequently used process goal is this:

  • Every day write in my small notebook the top 6 things that I will get done that day.
  • Prioritize them, 1–6.
  • Think of how and when I need to prepare for each item.
  • Keep that notebook on me and refer to it as a guide for my day.
  • Check the items off as I do them.

I use another process goal when I’m sitting in a meeting and I know the presenter will ask for feedback at the end. This too is easy: I use my notebook to jot down reminders of the feedback I want to provide. It’s basic, but effective. Here are two benefits.

  • I can say “I have three concerns.” When conversation ensues over point 1, others already know to bring it back around for point 2 and 3.
  • I don’t waste others’ time as I stumble over my words and try to remember what I was going to say. My memory is frail, and this technique overcomes that.

Are process goals SMART?

If you’ve ever talked with an HR person about goals, no doubt you’ve heard of the SMART acronym. SMART goals are:

  • specific
  • measurable
  • achievable
  • relevant
  • timely

My process goal of using the daily list may, in fact, be the most SMART goal I’ve ever had at work. It is specific, measurable (just flip through my notebook to see the success rate), achievable (it is easy…I just need to have the daily discipline to do it), it is definitely relevant, and by its very nature it is timely.

Whoa. Now that acronym actually makes sense.

And while it isn’t on the SMART checklist, these process goals are activities that I don’t have to rely on anyone else for. If I don’t do them, it’s nobody’s fault but mine.

What if goals can be expressed instead as habits?

So, like thousands of others, I’ve been through BJ Fogg’s 3 Tiny Habits program, and I actually use that lesson on how to form habits. The daily list is one thing I’ve used the 3 Tiny Habits program to help me do better. So, before I considered these to be process goals, I just considered them to be habits. These process goals are also habits.

If you haven’t yet, go through Fogg’s program. Process goals may make a whole lot more sense and you will have the knowledge to actually train yourself to do them. I’m going to predict that most good process goals, which are probably better as daily processes, could be implemented as though they are habits you are trying to form.

So, given this insight, how have I applied this?

I’ve talked with my staff about this approach, and we’ve updated some of their goals to follow this pattern.

Here’s what amazed me: In the very first week I saw improvements in performance and morale. For example, one of my staff wrote this process goal, “Every day, write down one thing I’m proud of.” I believe this simple goal improved this employee’s morale and it has spilled over to others, myself included.

But has the quality of work gone up? Difficult problems are solved by people who can easily think laterally as well as vertically, and a person’s emotional state has an effect on this. More stress means less lateral thinking. So, yes, I’m sure the quality of work has gone up.

Further, this kind of attitude can be trained over time and will help others want to work with this employee. Who wants to work with someone who doesn’t appreciate the chance to do quality work? I know I don’t.

How can you implement this change in setting goals?

Write process goals for yourself. If you are a manager, have your staff do this.

Process goals are:

  • Easy to do
  • Quick to do
  • Done frequently (e.g., daily)
  • About how you work or think of your work, not about the outcome
  • Done by you alone, so that you alone are responsible for doing them

I’ve listed a few examples in this post. Have others? Feel free to share them in the comments on this post.

I’ll close with another quote from Bassham: “The BEST years of the BEST players are rarely foreseen in advance. Why? I believe it is because the elite are not thinking about outcome. They are thinking about process.” (62)

Attitude-adjusting pointers for professionals

Over the years, others have shared a few attitude-adjusting pointers with me about work. They’ve stood the test of time for me in a number of different jobs. Here they are.

1. Remember, you don’t need this job. You need a job, but not this one.

In my first full-time, salaried position, my boss shared this nugget of wisdom with me. (He shared the next one too.) I had to chew on this one for a bit, repeating it to myself in different ways for it to sink in. But once it did, it changed how I looked at my job.

The biggest change is that it removed a fear. I didn’t fear losing the job, because, after all, I didn’t need this job. With that gone, my attitude shifted to where I was willingly giving my time to the job. It was my choice to work there, so in a way, it gave me back some power, emotionally. I wasn’t dependent on the job, and I wasn’t begging for the chance to do that job. Instead, I had the freedom to focus instead on what I needed to in order to get the job done.

It also has helped me to not worry about the inevitable politics of an office, and instead more clearly relate to the people I work with. It helps me better respect my colleagues as the human beings we all are.

There is a simple, yet powerful, proverb that stands hand-in-hand with this pointer: “Do you work heartily as for the Lord rather than for men.” Attitude-wise, taking this proverb seriously means that I crave honor from God, not from my boss, coworkers, clients, or employees. This has been profound for me, and I encourage all who read this to take this proverb to heart.

This first pointer is probably the biggest of these for me.

2. If you want to seem invaluable, find a problem and solve it. See a vacuum? Fill it.

This one is obviously simple, I think, but sometimes I wonder if it just hasn’t occurred to people. If you want to be valuable, do something valuable. Keep your eyes open for that thing that clearly needs doing that you have a shot at doing, and figure it out. If it happens to make sense with your job description, great. If not, just do it anyway.

3. A secret part of your job is to make your boss look good.

This is an interesting one because it still applies when you aren’t happy with your boss.

How do you do this one? You give your boss credit for good work, good decisions, whatever, to others. You don’t have to overdo it, but keep it in mind. Also, I’ve been in situations where I’ve been asked to help prepare a presentation or a proposal for my boss, and even though I may not be the one delivering the presentation, I can try to make sure that my boss will seem  organized, coherent, and smart.

This pointer is helpful because, by making this part of my job, it forces me to check myself when I have a bad attitude about the person I report to.

4. Bring an alternate idea along when you bring a critique. (And if you can’t, then think twice about offering your critique.)

The point of feedback, of critique, is to make something better. I get the feeling that people forget this, and think that the point of critique is to look smart, to make someone else look dumb, and to thrill in the dark joy of shredding someone else’s work.

So, if the point of critique is to make something better, doesn’t it make sense to point out a problem and immediately follow it with at least one idea to overcome that problem? Maybe it isn’t the idea that will be chosen, but by offering that idea, you make yourself a collaborator with the person who receives the critique. You offering an idea can spur more creative thinking on the problem. Plus, offering an idea is brave, because your idea can now receive critique. If all you ever do is critique but never add ideas, you’re probably a coward and are making things worse, not better.

Closing

I know there are all kinds of other thoughts on work that I have, and I’m sure many of my blog readers have their own life lessons to share.

Please comment with your reactions or additions!

UX and Project Mangement cross-over article from Interactions magazine

A Taxonomy of Models Used in the Design Process by Joanne Mendel in the Jan + Feb 2012 edition of Interactions magazine is pretty interesting.

At Covenant Eyes we’re continually in the churn of Agile development, and integrating user experience work can be challenging. We’re figuring it out, and have definitely made some breakthroughs, but this article has provided another perspective that is helping me think about timing of user experience work within the loose phases of work that a typical project runs through.

It isn’t a stretch to layer the phases of Discovery, Reframe, Envision, and Create over a project’s lifecycle, and so tying different models for design work in each phase provides an opportunity to reflect on how we’re doing with matching up appropriate design work.

I’m asking my team and our project managers to read through it, and perhaps we’ll get a chance to discuss it together and consider if we can use some of the ideas to do better work.

Does Kanban hurt Agile teams by decreasing iterative development?

Workers welding on an automobile assembly line.
Kanban/Lean manufacturing makes sense for factories. I'm not sure how well it translates to web and software development.

Kanban is a balm now being used by some Agile development teams to soothe the pain caused by timeboxed development cycles. Jeff Patton’s statement, “Short timeboxes herniate,” sums up that pain (from his excellent post “Kanban development oversimplified”). As a Product Owner with a team that started out using Scrum and has gradually drifted to something else, I identified with all those critiques of timeboxed development.

Management expected the team to deliver user stories every week because our iterations were week-long. So when the team realized at mid-week that they wouldn’t be able to deliver a story by Friday, the team would pick up a small bug to fix just to show something by week’s end. That’s a problem. As a Product Owner I saw this mid-week “save” for the sprint review as pure distraction from more important work. So we dropped the weekly delivery requirement.

When I read Jeff’s article, I realized that the way we were working looked more like Kanban than it did Scrum—except we were still using Scrum words and concepts to discuss and analyze our work. Words like “iteration”, “sprint”, “daily scrum” no longer fit.

As a team, we had let go of the expectations of a sprint, and we were still delivering great value, just on a more natural timetable. I believe our efficiency stepped up when we ceased adhering to the rules of Scrum.

However, because we still spoke in Scrum phrases, our company had not followed-suit. Frankly, without a name and model for what we were doing, we weren’t sure ourselves.

Months have passed since then, and some Kanban ideas have seeped in to our work. But we haven’t embraced any change, really.

Why change? Despite the problems I’ve alluded to, the team is really doing great work. They are delivering value to the company and its customers. So one argument is to simply continue on our course. The other is that we’re already practically doing Kanban, so why not start using words and tools that match?

In my brief review of Kanban, I see that it comes from the Lean Manufacturing philosophy. How it is being used in the Agile world is really taking Kanban as a metaphor. It is adapting a model from the manufacturing world and applying it to the software development world. I’m naturally wary, and so want to critique this adaptation for the sake of clear-headedness.

First, let me admit that of all the Agile flavors, Kanban seems the most practical to me. I’m a fan. That said, software development is not an assembly line. We don’t deal with pre-designed units like car doors. Instead, we have a variety of problems and need to be able to design a system to appropriately handle whatever those problems happen to be.

Whereas Kanban works well for an assembly line that puts the cars together, software development looks a lot more like the design shop that engineers and prototypes new car concepts or revisits problems with existing cars to make them more efficient and safer for the next model year. Sure, we produce applications, but a whole lot of the work is really design work.

Design work tends to be iterative and recursive, but I don’t see words from Kanban that support iterative work. In general, a card moves from left to right across the board. Sometimes, the card ought to be killed and restarted with the  ideas we’ve learned during it’s first round. However, from what I see of the Kanban model, this just doesn’t happen. (Not that is happens in Scrum either.)

Why is that? Maybe it’s because coding is expensive and we suffer from the sunk-cost bias. That seems like flawed thinking.

Maybe, as I wrap up this half-thought-out post, I’m simply frustrated by the lack of deep design work in our projects.

More later. I’ve been thinking of the design process with insights from some recent research and articles seen via SIGCHI, and it may result in some design management postings.

Anyone else have ideas to share here?

Addendum to “Getting More From Analysis” by Lewandoswki and Dilworth

UX Magazine published Getting More From Analysis by Jared Lewandowski and John Dilworth on Dec 16, 2010. The authors provide a  summary of analysis as part of three design activities:

  1. Analysis
  2. Synthesis
  3. Evaluation

Diagramming these activities

They also provide some models for conceiving of these three activities, from linear to finally advising on a traditional equally-weighted 3-circle Venn diagram.

I like the thinking, and the clear reclassifying of design as including all of these activities, as opposed to only synthesis. However, their Venn diagram leaves direction out of the picture. I like this approach better.

Design as Venn diagram of Analysis, Synthesis, Evaluation, with clockwise arrows.

This model simply adds the arrows to what Lewandowski and Dilworth provided. It’s simple, but serves to organize the concepts.

Working together isn’t always simple

In addition, the authors recommend involving analysts in synthesis activities, and designers and developers in analysis activities. This, I agree, is good advice, but they didn’t provide any techniques to help you actually pull this off.

Analysis, synthesis, and evaluation each require different types of thinking, and a person specialized in, say, analysis may end up stepping on the toes of the people specialized in synthesis. The result may be a stunted synthesis activity, shut down because an analyst broke down the problem again before a designer or developer had a real chance to synthesize the ideas into various solutions.

To avoid these types of problems, creating intentional design (be they analysis, synthesis, or evaluation) sessions is important.

Setting up design facilitation sessions

I’ve been listening lately to some lectures by Professor Michael Roberto, and in them he’s advised what he calls the 4-Cs of encouraging real ideas in a debate. Roberto is focused on strategic decision making, but I think we can learn from this advice and apply similar thinking to how to set up design facilitation sessions.

  1. Composition – of group, who should be invited
  2. Context – Atmosphere, shared norms, ground rules, location
  3. Communication – How will we discuss and exchange views? E.g., subgroups, devil’s advocates.
  4. Control the process – Will I as leader be in the room? Do I ask for a packaged solution or do I ask to see a debate.

You might think this is over-thinking it all. Just put the people in the same room and have them discuss the design, and good things should happen right? Maybe. But why gamble? Even 10 minutes of planning a design session based on these 4-Cs could turn a waste of time into a breakthrough design session.

How to seek and destroy organizational silos

sketch an evil silo
Fear the Evil Silo!

After I was put in charge of a newly created user experience department, a young professional gravely warned me about silos.

He had argued against the new department because it would just create another silo in the company.

The passion of the warning gave the impression that this silo threat was real, imminent, and inescapable in anything but a flat organization.

Beware all ye who manage departments! Dread the ghoul of business quagmire: silo! 😉

The warning was overzealous. The fear of silos is a bad reason to force an organization’s structure into any particular shape. No, instead shape the organization to promote sustainable excellence in performance for the whole business.

That said, for all you suffering from silophobia, let me tell you how to spot silos and what to do when you find them.

How do you spot a silo? Watch for the symptoms.

I found this description after a quick web search for organizational silos. (It’s a nice short read on silos, so go on and read the whole article.)

“The symptoms of the silo effect are easy to recognize: lack of cooperation, internal competition and breakdown in communication. The result is that one division gets pitted against another – head office against operations, one department against another.”
Marcel Côté, A matter of trust and respect, CA Magazine, March 2002.

As Marcel says, the symptoms are:

  • lack of cooperation
  • internal competition
  • breakdown in communication

Doesn’t that sound like squabbling children? Interdepartmental gossip may be another symptom.

Okay, let’s say you spot a breakdown in communication between departments. Do you have a silo? Don’t jump to conclusions. Maybe you just have poor communicators. Relax. You may not have a silo on your hands.

Now, if you do see all these symptoms, you have a problem, no matter what you call it.

The question is, what can you do about it?

How to solve a silo problem

Let’s say you manage an IT department and you have just spotted a silo in that other department, Communications.

Look out! You’re standing in your own silo peering out. Good job, you have just spotted two silos. Now what?

Now you do a gut check. Ask yourself if you have felt competition against Communications. Have you been looking out for own department at Communication’s expense? Think about your budget and your own maneuvering. When you think about your department’s plans, do you consistently consider how to keep the people over in Communications in the loop?

The key to tearing down silos is to go out of your way to help other departments.

(Fortunately for me, this is natural to user experience. We help other departments, like product development, marketing, and sales, do their work better.)

So, your next step is to go over to Communications and find out how you can help them the most. And then do it. Yeah, even spend a little of your own budget on the solution. And don’t begrudge it. Earn gratitude.

What will happen is that you will start strengthening relationships between the people in your department and the other department. With that will come respect, collaboration, and better communication.

Oh, and if you consistently help that other department, eventually they’ll get the idea and return the favor.

The idea is simple. Business silos exist when departments look out for their own interests instead of the whole business’s best interests. The solution is to get back in touch with the main objective of the company and help each other out in pursuit of that goal. Bingo.

In short, grow up and play nicely together.

P.S.—Or take this ITIL expert’s advice and admit that silos are a good thing and systematically work to strengthen them.

My 2.5 days in San Francisco: MX 2010

Red stone church near green trees, surrounded by skyscrapers.
View from top of Yerbe Buena Gardens, San Francisco, March 2010.

Saturday PM: Sunshine!

I actually began to sweat under my blazer from the warm sun shining brightly through the window.

I had arrived in San Francisco a little early on Saturday, dropped my suitcase off at the Intercontinental Hotel, and walked around the corner to a sandwich shop for a bite to eat and to get online. As I draped my coat over the back of the chair, I decided I really like San Francisco. It’s the sun, I admit it. Oh, and I had already noted that the two billboards I noticed on the taxi from the airport were pure tech: one for an enterprise search system and another for PGP. Billboards talking to me? Amazing.

After settling in at the hotel, I had dinner with my old colleague Chris Burley and his girfriend at a nice Italian restaurant. Chris is awesome. I love talking with him because he has such passion for what he does, which currently is to help lead efforts like urban farming in the Bay area.

Sunday AM: 3 good things

The next morning I woke early due to the time zone difference, and I had three excellent experiences:

  1. In the aching fog of caffeine deprivation, had the best cup of coffee of my life, thanks to the Blue Bottle Café. (I admit, I ordered a second cup to go.)
  2. Paused in the Yerbe Buena Gardens where some elderly practiced tai chi and parents snapped photos as their little children hid behind a waterfall. I stood on a bridge and watched the morning sun ripple on the glass of San Francisco skyscrapers.
  3. Crashed a church service at a music venue called Mezzanine put on by a group that calls itself IKON. I was the oldest person there, amidst a crowd of art school students. We sang, we listened to a teaching from the Word, we had communion. It was good.

Sunday PM: MX day 1

Sunday afternoon saw the start of the 2010 MX Conference.

MX2010 is largely focused on managing user experience and less on the tactical end of UX practice, and there were some thought-provoking presentations from people who have been managing user experience for a number of years, in a number of different types of companies. Off the top of my head, presenters represented firms in financial industries (Vanguard), publishing (Harvard Business Review), retail sporting goods, and online media (Youtube).

The series of talks was fantastic, and was kicked off with a keynote by Jared Spool in which he shared insights like that Gallup’s Customer Engagement (CE11) metric has high correlation to the quality of user experience. Spool’s keynote actually turned out to predict some themes that carried throughout the many presentations. Among them were the importance of establishing a vision for user experience and that experience ultimately must be addressed well across multiple channels (web, mobile, physical space, etc.).

Spool talked about three core attributes necessary for great user experience: Vision, Feedback, and Culture. He posed three questions that UX managers should ask.

  1. VISION: Can everyone on the team describe the experience of using your design 5 years from now?
  2. FEEDBACK: In the last six weeks have you spent more than two hours watching someone use your design or a competitor’s design?
  3. CULTURE: In the last six weeks have you rewarded a team member for creating a major design failure?

After the conference reception, I wound down the evening by taking a walk around a few blocks and ending at a nearby bar. I ate a burger and watched the Academy Awards for a while. Back at the hotel I watched the end of a Clint Eastwood Western flick and fell asleep.

Monday AM+PM: MX day 2

I woke at 4 in the morning. I checked analytics, email, and my usual RSS feeds. I stretched, washed, dressed, and still had time to kill. I read a few chapters in The Shack, a book Adam gave me last week.

I chatted throughout the day with Haakon, a usability specialist attending from the design company Tarantell in Norway, and as he sipped his coffee, I decided to not mention my mere three hour time difference.

The rest of the day was another series of excellent presentations. Themes: customer (more than user) experience, vision that guides the business, new models for working in the network, UX leadership stories from Youtube, customer experience in renovation of thinking at Harvard Business Review Online, understanding the holistic customer, data-driven design decisions (and when not to rely on data for design decisions), experience design as business strategy, and operating as a chief experience officer in your company.

It was great to hear first-hand the stories from these user experience leaders. Now, for what to do with it all when returning to the office.

Tomorrow and then

Tomorrow morning I fly back to Michigan, and need to get my head back into product owner and user experience work. But I also need to hold onto the ideas from this conference, and shift into actively leading user (or is that customer) experience work at Covenant Eyes.