Boxes and Arrows: Comments by Terry Bleizeffer

Terry Bleizeffer — Thu, 31 May 2007 11:27:47 GMT

Agile development and UX is an intriguing subject. On the one hand, for those of us working on products that have two-year release cycles, the ability to make incremental improvements over relatively short intervals is very appealing. On the other hand, I’ve heard from UXers working in Agile teams that they can ONLY make incremental improvements… that it’s extremely difficult to get any changes accepted that require more than a single iteration to complete.

Regarding Google, it sounds like they were using a “brute force” style of UX on this project. As Max says, it’s hard to know whether that translates well to the rest of the world, where every UX decision from process to design is intimately tied to limited resources. I wonder how Google has justified their UX expense internally… or whether they haven’t needed to on the grounds that Google has more money than they can spend anyway. A nice problem to have. =)

Terry Bleizeffer — Thu, 31 May 2007 11:32:07 GMT

I reviewed this book on my blog as well:
http://uxsoapbox.blogspot.com/2007/05/book-reviewdesignin…

I agree with Clifton about the book – I ended my review with ”...overall I thought it was an excellent book, especially for people who are trying to go from beginner to intermediate in their design skills. It’s well-written and engaging, and that counts for a lot.”

Terry Bleizeffer — Wed, 29 Aug 2007 19:50:41 GMT

Any article that makes me laugh out loud is a-okay in my book, and “But like most Ph.D.s, I emerged from my final thesis defense, not empowered by a sense of mastery, but horrified at how little I knew” made me laugh out loud. As Homer Simpson would say, “It’s funny because it’s true.”

As someone who is new to IA (I visit here to extend my user experience background gently into the IA arena, which I think is a valuable skill), I’ve noticed the insular nature of the community – but not in a bad way. Any vibrant community is going to have a natural case of insularity, and as others have pointed out, this doesn’t mean newcomers aren’t welcome, it just means newcomers have a motivation to join the group. Completely distributed, non-insular communities are not attractive to join.

Terry Bleizeffer — Fri, 22 Jun 2007 15:55:15 GMT

Very good article, though I disagree with one part of it (more on that in a moment). Very good point about tying to business drivers, and the deep vs wide distinction is critical—at the end of the release, you need to have visible wins, and going wide hurts your chances of that. The point I disagree with is this, “Your team will save valuable time and resources by getting it right, or mostly right, the first time. And they’ll be faster doing it.” I don’t really disagree that this is true, but I disagree that it’s a useful argument. Most companies are worried about THIS quarter, not next year. And the time saving payoff for doing good design isn’t immediate—good design takes more time and effort than bad design. I think telling stakeholders that this will save a lot of time… in two years… can do more harm than good. The other thing that I think is important to emphasis during the evangelism phase is that by including customers in the design process you help to build buy in for the product even before you ship it, which can include customer references that you can market as early as the day you release. This can make a big difference, and it’s something that The Powers That Be can easily get their heads around.

Terry Bleizeffer — Fri, 22 Jun 2007 20:22:22 GMT

Giving this a little more thought, I suppose organizational maturity is the deciding factor on which way to go. I completely agree with you that what you want to avoid is UX being seen as a cost center. That’s an unpleasant place to be. We want to (accurately) be seen as a revenue generator and/or cost reducer. In fact, a few years ago I did a presentation about UX ROI where I made both those points – I used “non-defect” (i.e. usability) in-field problem reports to show how much money we spent on usability problems and I used market intelligence data to show that improving UX market drivers would increase revenue by specific amounts. It was very effective… for that particular team. But (like many people) I’ve also worked with teams that think that future service costs are either a) someone else’s problem, or b) something we can worry about after we get the code out the door. Future cost savings arguments went over like a lead balloon with those folks.

Thanks for the interesting article and discussion. Now if I can just figure out a way to remove those strikethroughs from my previous comment….. hmmmm, is that a functional defect or a usability problem? =)

Terry Bleizeffer — Mon, 09 Jul 2007 13:26:05 GMT

I think this is a great topic – in fact, I’ve written a couple blog posts on exactly this topic:
http://uxsoapbox.blogspot.com/2007/06/user-testing-rope-d…
http://uxsoapbox.blogspot.com/2007/06/who-cares-about-fin…

I definitely think it merits an article-length discussion.

Terry Bleizeffer — Fri, 20 Jul 2007 11:52:07 GMT

Very interesting article, Adam. I particularly liked the distinction you made between “user value” and “business value”. It’s easy for us to sometimes forget that there’s a difference between these two – afterall, if something has business value, it’s gotta have user value, right? And vice versa! Well, while there’s obviously a correlation, I do think it’s important to understand the differences. For example, creating a migration utility that makes it really easy for users to migrate off your product and onto a competitor’s product might have very high user value… and very low business value.

One nit I have is with your weights. 1x, 2x, and 3x seems awfully extreme. For most projects, cost will be the least flexible factor, so business value will get a 3x for all their ratings. While I would agree with the principle – low flexible on cost means higher focus on high business value requirements – I think a smaller multiplier would make more sense. Like I said, this is a nit.

On a more fundamental level, I wonder how this would impact one of the major issues that I deal with – the difficulty in getting small improvements into plan. The user value and business value of small improvements is always small, and while this is balanced by high technical ease, it still sounds like the user experience team would need to “cook the books” to artificially raise the user value ratings for the small improvements to make them rise to the top. The other potential issue is that a release should be about more than a grab bag of independent requirements – the release should have themes. If a requirement is critical to a release theme, then it should rise in importance. Maybe the way to fix both the “small problem” and “theme” issues is to add a grouping mechanism to the process so that requirements are not considered in isolation.

Regardless, I enjoyed the article, and think this process has a lot of merit.

Terry Bleizeffer — Mon, 16 Jul 2007 13:23:17 GMT

Thanks for the encouragement, Christina. Does this qualify as an editor contacting me? If so, I’ve written a first draft of this article and would be happy to email it to someone, somewhere. Not sure how this works.

Terry Bleizeffer — Thu, 19 Jul 2007 05:42:39 GMT

Seth – I really like that approach, because it helps to address the problem I mentioned above… how to get relatively small improvements into the product. In most prioritization methods, the big, sexy, expensive requirements end up at the top and then you work down the list until you run out of resources, completely skipping the easy stuff. Your method encourages people to think “I can either do this big, cool thing or these 12 small things”. The only problem I see is: how do you determine how many points are available? In my experience, even sizing a requirement is an expensive activity, so some prioritization needs to happen before sizings are done. This leads me to think that a combination of your method and Adam’s would be really useful. Start with Adam’s approach to identify the top requirements (including a gross ballpark sizing), then do a more detailed sizing of the list that makes the initial cut, then apply your technique to it.

This thread validates my belief that “release architect” is the most difficult and underappreciated job in software.

Terry Bleizeffer — Fri, 20 Jul 2007 00:22:48 GMT

Seth – Would this be a live interview with managers or just asking them to write down answers to those questions? I know a manager who would be a good participant (he started as a practitioner before going into management) and would be able to provide the large enterprise view (IBM), but I doubt he reads Boxes and Arrows, so I’d need to recruit him.

Also, in your list of questions I think it would be useful to ask about the business model they follow:
(http://www.uxmatters.com/MT/archives/000206.php)

Another question I have that might not be appropriate for this article is: if you have managed both UX types and non-UX types (a.k.a. “normal people”), what unique challenges did you encounter with the UX types? In other words, what makes managing UXers special?

Terry Bleizeffer — Sun, 23 Sep 2007 09:23:41 GMT

Here’s another game format that can be used, though it’s fairly specialized. If you work on a large project, you might run into these two problems. First, many of the developers might not have experience using their own product (if the developers are very specialized) which causes several problems, such as difficulty in transitioning developers between areas and career development. Second, discussing user experience problems can feel very esoteric to developers who don’t use the product. One technique to address this is to create a competition in which developers are asked to complete a series of basic customer scenarios using their own product (but usually outside their own area of specialty), and while doing the scenarios they need to discover UX issues and propose solutions to the problems. The developers (who might work in teams, depending on the product) win awards for proposing the best solutions. This technique provides positive incentives to use the product (rather than executive mandate), and ensures that UX will be their focus while they do it.

Of course, as Jess said in the article, just don’t call it a “game”! That’s the kiss of death for any game technique.

Terry Bleizeffer — Mon, 20 Aug 2007 15:37:30 GMT

Very good, practical advice. In particular, I’ve been trying to figure out how to change the default formatting for link text in PowerPoint for years without success. Drove me crazy. I usually resorted to creating a rectangular autoshape with no fill and no border, add the blue-underlined text, then make the box the hyperlink (as you say in the article). A pain in the, um, neck.

I also like using PowerPoint for prototyping. Another good technique is using a combination of PowerPoint and Visio. You can embed a Visio object into a PP chart (Insert -> Object -> Microsoft Visio Drawing), then choose a drawing type of Software -> Windows XP User Interface, which allows you to quickly create a mockup. Then for interactivity, I use “invisible” hyperlinks sitting on top of the Visio object. By invisible I mean a no-line, no-fill rectangle with a hyperlink to the appropriate slide. The downside is that if you update your mockup you have to remember to move the invisible hyperlink, but sometimes the advantage of being able to use the Visio drawing makes up for the hyperlink maintenance. And people don’t need Visio to view your PP charts.

Anyway, nice article. I use PP a lot and still learned some new tips. Thanks.

Terry Bleizeffer — Wed, 08 Aug 2007 20:58:59 GMT

Henrik: There are many times when I work with a developer who codes the prototypes. In my experience, we use that technique when a) the UX team is in “consult” mode by commenting on the design that the developer is creating, b) we’re too late in the cycle to do usability testing, or c) the amount of design is so small that we don’t care enough to spend time doing the prototyping ourselves. Those are reasonable, common situations, but it’s not the model we’re shooting for.

I also create prototypes by writing code myself, especially if the end code will just be HTML and JavaScript. If I expect a lot of iterations in the design and/or I expect that there is so part of the design that requires “real” interactivity for useful testing, the investment of time necessary for coding it myself can save time and effort in the long run. For me, these are often the most enjoyable design projects, but there are plenty of cases where it’s just overkill.

Using PowerPoint (or PDFs, though I haven’t tried that before) to do quick prototypes is a great tool in the toolbox for situations when you have limited time, need a lot of eyeballs on the design, only require some simple interactivity, and don’t expect endless iterations. In my job, expecting a developer to create my prototypes is wildly unrealistic.

Terry Bleizeffer — Thu, 16 Aug 2007 12:52:20 GMT

Nice review. I loved this book as well. In the review I wrote on my blog, I started with, “Have you ever been to a party and met someone with a great job and a great sense of humor and ended up spending the entire party drinking beer and swapping interesting stories? That’s what Scott Berkun’s new book, “The Myths of Innovation”, felt like to me. There are lots of books on my shelf that I know I ought to read, and many of them I struggle through and afterwards feel like it was a valuable investment of my time, however painful. This wasn’t one of them – this is one of those rare books that feels like reading for pleasure, and yet you learn something along the way. And I might add that the colophon alone is worth the price of the book (a sentence that perhaps has never been written).”

So basically I second James’ recommendation. Time well spent.

Terry Bleizeffer — Mon, 03 Sep 2007 16:40:58 GMT

Regarding, abstraction and CLIs, we use a technique in our administration GUI that allows users to view the CLI equivalent of the action they are performing, which allows them to move from the more abstract GUI model to the less abstract CLI model. This is important because we know from research that our users tend to start first with the GUI to learn the concepts then transition to the CLI for power and control. Rather than fight this, we try to enable it.

Regarding abstraction in general, the problem I see is more practical than theoretical… good abstractions are really frickin’ hard to design. And bad abstractions are often worse than no abstraction. How many times have you been using a product with an abstraction intending to help you, then the abstraction breaks down in one place and BAM you have to consume all of the underlying complexity to make progress? Development tools do this all the time – you get a nice WYSIWYG builder that works 90% of the time, but to accomplish the other 10% means learning everything that the WYSIWYG builder was attempting to hide. On the other hand, I’ve had techies tell me that we should expect all of our users to know our product’s installation file structure, and if they don’t they have no business using our product. So abstractions are hard, but the alternative is too horrible to consider. =)

@laurie – I particularly liked that section as well, for the same reason. I think it’s rarely the case that time on task is a useful metric, and focusing on time on task can lead to bad design. People would rather spend 30 mins on a task where they always know where they are and what they’re going to do next and exactly when they’re done, then spend 15 mins blindly trying random techniques that may or may not be working.

@David – I enjoyed the article, but I disagree with one small part of it. In the very last sentence you say, “In the end, interaction design is the choreography and orchestration of these form-based design disciplines to create that holistic narrative between human(s) and the products and systems around us.”

There’s a lot of nuance in the world of “design”, and I think it’s worthwhile to break “design” up into pieces to understand them individually as a learning technique. Where does information architecture end and user experience begin? Where does visual design end and interaction design begin? These questions might not have clear answers, but trying to tease the pieces apart makes it easier to understand how each contributes to the whole. But interaction design, IMO, does NOT sit at the top and choreograph the “holistic narrative”. It’s just one of many pieces contributing to it. To put it another way, if I knew a product’s ID and the design parts that were being choreographed, does it follow that I must know the “holistic narrative”? I think not.

This is probably semantic quibbling, but I bring it up because I think there’s a tendency for people to try to break “design” into pieces to better understand them… then forget that a) it’s the overlap between the pieces that are most interesting, and b) none of the pieces define the whole. I’m not saying that you’ve forgotten this, I suspect the sentence was just worded so that it made a broader point than you intended to make.