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


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?

Thinking: Taxonomy of shooting ranges

I’ve been overwhelmed by feedback from a side project of mine, rangelistings.com, and am working on upgrading it so that site visitors can make some updates on their own without having to go through me.

It’s great how even seemingly little projects like this raise information architecture questions so promptly.

Wait…what the heck does “access” mean?

When I started this project a while ago, I didn’t question much of the data I was harvesting. I just wanted some data to test a theory about the utility of a geographic perspective on shooting ranges. It was just an experiment, done as a bit of a hobby over the course of some weekends. One piece of data for each shooting range was labeled “access” and the data was primarily either “public” or “private.”

Well, upon actually using this information, I find the public access or private access to be too ambiguous. Does “public” mean state-run, paid for by tax dollars? If a range is in a gun store, which is itself a private enterprise, is the range private or is it public because anyone can use it? And besides, what do we mean by “access” in the first place?

The useful data can be more clearly represented by asking “What sort of requirement is there for access to the shooting facilities?” When I state it that way to represent what I mean instead of simply “access,” then I realize more clearly how “private” and “public” are inadequate words.

Looking over the data and thinking about my own experiences at various types of ranges, this is what I’ve come up with.

  • Membership required (like at many Sportsmen’s or Conservation Clubs)
  • Pay a fee for range time (like at some gun stores or commercial shooting facilities)
  • Free (like at some state-run shooting ranges)
  • Unknown (because right now I only have private/public values)

The exact wording can be tweaked, but the notion is in there and is far more useful than the current private vs public value.

Gah! What a mess of a labeling system.

Meaning and words overlap. Case in point: when I list shooting facilities, many of them resemble shooting sports (like “trap” which can describe a range as well as a shotgun sport).

Which should I list? How do I tell the difference between a sport and facility? How do I prompt the user community to stay with the right taxonomy? (And what do I mean by “right taxonomy?”)

Which words describe the possible shooting/firing ranges themselves at any sportsmen’s club, gun store, or other shooting facility? Those are the words I need.

Why not list the shooting sports themselves as a primary organizational scheme? Here’s why. Because very often people just want to grab their gear and head to a range to shoot. That isn’t organized into a predefined shooting sport, like trap shooting or action pistol. No, that’s just heading to the range to shoot. That’s pretty normal.

However, many shooters also want to know if they can do a specific kind of sport, and a description of the range itself can help answer that question. For instance, I’m a bullseye pistol competitor, so if I see “Outdoor pistol, 15 feet” as a description for a shooting range, I know that won’t do for my sport. If I wanted to practice some defensive pistol shooting, it would be okay. However, if I see “Outdoor pistol, 50 yards,” than I’m going to be pretty confident that I can practice my sport at that range.

The point is, some decent descriptions of the physical ranges themselves should provide an appropriate amount of information to be useful for a wide variety of shooters’ interests.

So, it should be easy to come up with that list of terms, right?

As an initial audit, as of today, Oct 28, 2012, this is what I have in the rangelistings.com website.

  • Airgun
  • Archery
  • Indoor Pistol
  • Indoor Rifle
  • Muzzleloading
  • Outdoor Pistol
  • Outdoor Rifle
  • Pistol Silhouette
  • Rifle Silhouette
  • Skeet
  • Sporting Clays
  • Trap

And any specific range listed can add a note. The most common note indicates the distance and the second most common type of note indicates the number of firing positions. For instance, “Outdoor Rifle (500 yards, 10 firing points).” For someone looking for a place to shoot, that bit of information is quite informative.

But I’m not really settled on that, despite the fact that I have data on close to four thousand ranges already using that taxonomy.

My primary concern with that set of terms is that it may not be complete. For instance, I don’t see Cowboy Action as an option. Nor do I see Five Stand for shotgun. Both of those are, to my knowledge, specialized range designs.

But is that getting too specific?

I’m also concerned that some people may want to check off a bunch of those options with the thought of “Well we have an outdoor rifle range, and a person could set up some silhouette targets on it, so I guess I should check Rifle Silhouette too.” But that isn’t how I’d prefer people to think of it. My thought is that the range should already be set up for silhouette shooting, with metallic silhouettes already set up and/or available, and possibly with a target reset cord.

Perhaps there should be a general purpose outdoor pistol and a general purpose outdoor rifle. Then if a range has more specialized facilities, a person could choose to list those.

I’m a member of the Saginaw Field & Stream Club in Michigan, and we have a pretty cool Cowboy Action range, which is used only for that sport. We also have a standard 50 yard pistol range and a defensive pistol range. Given the current taxonomy, we could list it like “Outdoor Pistol (50 and 25 yard covered firing points, Cowboy Action course, and 15 foot defensive pistol range).” That’s informative and flexible. Perhaps there’s nothing wrong with that.

However, if I go with that notion, doesn’t the same thinking apply to the shotgun sports? If so, then it seems like I might not have separate items for Skeet, Sporting Clays, and Trap like I do now. Instead, I would just say something like “Shotgun (trap, 5-stand, and sporting clays).”

The conundrum here is that there very well may be value in having itemized those types of ranges. The point is that I’d prefer to have a consistent granularity in terms, and it seems to me that right now I have a mixture.

Which level of specificity is the most useful in light of the purpose of this data set?

And now I put my thinking on pause, the taxonomy questions unresolved.

LinkedIn UX groups, data and questions

Doesn’t it seem like there are a lot of user experience groups on LinkedIn? I’ve joined a few of them in hopes of staying up-to-date on topics, but after joining a couple groups, I quickly realized there were many more possible groups, and they all started looking pretty similar to me.

Why would I join this group versus that one?

Some are tied to specific organizations, like the Information Architecture Institute, the Interaction Design Association, or the Usability Professionals Association. Or like the Boxes and Arrows group, related to a specific industry publication. If you are a member of such an organization, joining the matching LinkedIn group probably makes sense in some way.

Some are focused on narrower subjects, like the Agile Experience group or mobileUX. If you have a narrower interest and find a group that fits, perfect.

Some differentiate by being localized. The UPA Israel, for instance, or London User Experience Professionals. Cadius is a group for UX people who speak Spanish. I think that’s fantastic.

But then we have all those other groups that ooze together, subject-wise. I’ll bet each has its own creation story, but at this point, the differentiation is slim.

Don’t these top 5 UX LinkedIn groups sound similar?

  1. User Experience
  2. Interaction Design Association
  3. UX Professionals
  4. UX Professionals Network
  5. User Experience Group

The second item is the group for members of IxDA, but the rest are simply professional groups for UX people. I’ll bet if you mixed together all the content and members of those groups you would first see a lot of repetition in members and topics, and second, I’ll bet you couldn’t separate them back into their original groups without a key. What does that say about these groups?

Some data on these groups

For what it’s worth, I’ll post some data I harvested while trawling LinkedIn this afternoon. (Why did I do this? Am I mad? No, but I’ve been sick all weekend, and in my addled state, cataloging some LinkedIn groups was the most obvious thing to do.)

The following data is merely what I found this afternoon. It is not comprehensive.

Chart showing membership rates of about 40 user experience groups on LinkedIn.
Chart showing membership rates of about 40 user experience groups on LinkedIn as of March 11, 2012.

Want a little more information? You can download an Excel spreadsheet I used while gathering this information. The worksheet includes columns for ID, Title, Membership, Parent Group, Created date, Type (e.g., Professional Group), Owner, Coverage (e.g., Earth, Greater London, UK, etc.), Language (didn’t fill that in), and Organization (e.g., IxDA).

Here’s the Excel file: User Experience (UX) groups on LinkedIn, March 2012 (.xslx)

Too many groups!

In closing, I think it would be easier and less time consuming to stay up-to-date in the field if there weren’t so many overlapping groups. What if some of these groups merged? Would people get too upset about that?

(Now for more tea and expectorants.)

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.

How I use utm_source, utm_medium, utm_campaign from Google Analytics

My friend Adam called me this evening to ask how I’ve used the Google Analytics tracking codes utm_source, utm_medium, and utm_campaign. He’s working on an app to help marketers generate HTML e-mails, and is thinking about automating the inclusion of these tracking codes.

The utm_medium is pretty straightforward in that the medium would be values like email, web, twitter, rss, and so on.

But, what’s the difference between utm_source and utm_campaign?

Google’s documentation on these variables is helpful in general, but is not all that clear on the difference between these two variables.

So, here’s how I think of those variables. The utm_source is like a noun, and utm_campaign is like an adjective. The utm_source will be more consistent from one edition to another, while the utm_campaign will change.

Let’s look at an example. Let’s say I send an e-mail newsletter called Brilliant Widgets every season (Spring, Summer, Fall, and Winter), and I want to track how many links back to my website each edition generates. Here are the utm_* values I would use.

utm_* values for the Winter edition of Brilliant Widgets

utm_source Brilliant_Widgets
utm_campaign Winter_2011
utm_medium email

So, the href value of the link back to my website would look like this: http://blog.davingranroth.com/?utm_source=Brilliant_Widgets&utm_campaign=Winter_2011&utm_medium=email

Now, assuming I use those parameters on the links back to my website and that my website activity is being tracked with Google Analytics, I’ll be able use Google Analytics to identify website visits that came from that e-mail newsletter. Then for the next edition, I would keep utm_source and utm_medium the same, but update to utm_campaign=Spring_2012.

With this thinking, you could define a set of values for all the e-mails you send out, and create a system that would help you know what those values should be when you introduce new online publications.

I’m sure that other people and companies have come up with their own approaches to using these utm_* values.

I’m curious, does anyone else have different ideas or examples to share?

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?

Small-caps, web text, and CSS

There’s a trick to getting small-caps to work on the web, and it’s counter-intuitive.

Let’s say you had an abbreviation, like CSS, that you wanted to put into small-caps, say with a little extra tracking. You might think you could use the CSS property font-variant: small-caps, and you’d be good to go. Not so.

Here’s why. Because for small-caps to work, you need to start with lowercase letters.

However, when you’re simply typing your thoughts out before you’ve decided on small-caps for abbreviations, acronyms, etc., you probably typed those abbreviations in uppercase.

So, when you tried small-caps, it simply didn’t work. For example, see this web page from 2005 that Joe Clark wrote to test small-caps. Note how the small-caps versions are more like regular capital letters. Not cool. It makes the hack look good, which is bad.

So, here’s what you can do (and what I think browsers ought to be doing automatically anyway):

  1. First apply text-transform: lowercase
  2. Then apply font-variant: small-caps

That ought to do it.

Here’s a more specific example of the CSS.

abbr, acronym {
text-transform: lowercase;
font-variant: small-caps;
letter-spacing: 1px;
}

The problem with the line break (BR) tag

We’ve got the <br /> tag all wrong. It’s time to make it right.

We all know the <br /> tag is used to insert a line break in HTML. But what we’ve been missing is that we were too often after something else. Let me explain.

Common reasons to use line breaks

Why would a web writer interrupt a passage of text with a forced line break? Here are a few possibilities.

  • Trying to avoid an orphan
  • Inserting a line break before a 2-word proper noun, like “American Airlines,” so the noun isn’t split
  • Formatting content like a mailing address

The problem with line breaks (<br /> tags)

Forcing a line to break in a document that will be printed is a no-brainer. But web writing has different constraints that we shouldn’t ignore.

Copy on the web has the luxury and burden of being portable. That text can show up anywhere:

  • in an e-mail message
  • on some other web page
  • in an RSS reader
  • copied and pasted into a Tweet
  • in a web browser on a mobile phone

This means that the line length you wrote your text for is simply not reliable. You need to consider how that text will show up in other places too, at unknown line lengths.

A line break may look fine on your screen, but it might look really awkward when that text appears somewhere else beyond your control.

Instead of splitting text, stick text together

Orphans

Avoid orphans especially where the text is most likely to appear, but relax. You can’t prevent them altogether.

Instead of inserting a line break, opt to rephrase the text to change the length and prevent the orphan. But realize that when that text appears elsewhere, it might just have an orphan.

You also have the option of a special white-space character called a non-breaking space. In HTML, it looks like this: &nbsp;. When you put a non-breaking space between two words, those two words will always be on the same line of text.

2+ word proper nouns

If you want to be sure that “American Airlines” remains on the same line in body text, employ a sprinkle of CSS magic. In the markup, a corporate name should be contained within a span element, like this:

<span class="brand_name">American Airlines</span>

And then to make sure that those two words stay on the same line, add a line like this to your CSS file.

.brand_name {white-space: nowrap;}

That will prevent the brand name text from being split at the end of a line. Instead, both words will flip to the next line if there is not enough room for them on the current line of text.

Formatting content like mailing addresses

In this case, I’m actually okay with using <br /> tags. But, left to my own devices, I might use some different markup and some CSS instead.

Let’s say we have an address like this fictional one.

Samuel Clemens
1835 Huckleberry Row
Hannibal, MO 63401

You could just put that text in an address element and use line breaks.

Or you could mark it up in the hcard microformat, and then think about styling it based on that markup. So, it might instead be coded like this.

<address class="vcard">
<span class="fn">Samuel Clemens</span>
<span class="street-address">1835 Huckleberry Row</span>
<span class="locality">Hannibal</span>,
<abbr title="Missouri" class="region">MO</abbr>
<span class="postal-code">63401</span>
</address>

And then a little bit of CSS like this would take care of the line breaks.

.vcard .fn,
.vcard .street-address{
display: block;
}

The point: we overuse line breaks because they don’t require any extra thought

Instead, let’s consider why we actually want a line break the next time we go to use one. There’s probably a better option once you realize that you don’t actually want to break a line of text, you really just want some of the text to stick together.