Outside-in Software Development

Carl Kessler and John Sweitzer (two IBMers) have written a new book called Outside-in Software Development.

This book occupies an interesting spot in the UX-related book landscape. It's not really about design, exactly, nor is it prescribing a particular software process. It's written by an executive with experience on the management side of building software (Kessler) and an architect with experience on the technical side of building software (Sweitzer), and neither of them have ever been User Experience Professionals.

And the target audience isn't UXers. I think it would be most useful for people in charge of software projects, including marketing, product management, managers, architects, and developers. I think UXers will enjoy it as well, but mostly because you'll find yourself nodding and saying "Damn right!" throughout the book - which is nice when reading a book written by a non-UXers.

However, there are some ideas in the book that were new to me as well. One in particular that I liked is that the authors argue that when you build up your list of key stakeholders for a products (including end users and business sponsors), you should also include your internal stakeholders and their goals. This surfaces explicitly that sometimes internal stakeholders have goals that are in conflict with each other... and sometimes the end users. For example, developers are internal stakeholders and they usually have a clear goal of completing their code on time - which can lead to a conflict of interest. It's not a new thought that developers can have a conflict of interest, but it's a new thought (to me) that we should document that goal when defining a product's stakeholders. Get it out in the open. Talk about it. That's a really good idea.

Mainly I found the book to be practical. Which is the highest form of praise for a book like this... and rare. It has fairly easy to implement ideas on how to shift towards outside-in thinking, and doesn't expect people to make a wholesale change to their processes in one fell swoop. They also discuss common mistakes (often with personal examples) and how to avoid them - such as trusting that your customers know what their own requirements are. And best of all (from my perspective), the book applies to enterprise software, not just building little websites. It doesn't assume that everyone on a project team is co-located and can fit in a single conference room with a whiteboard.

Anyway, I recommend the book highly.

(Full disclosure - in case anyone hasn't read my profile, I work at IBM too. I don't know Carl or John, but I've had one or two meetings with them over the years. I wasn't involved at all in the book - I didn't know anything about it until after it was published.)

By the way, Carl also has a blog dedicated to Outside-in Thinking.

Complex is better than simplistic

Courtesy of Joe Lamantia, I found Dan Ward's "The Simplicity Cycle". It's a quick read, it's free, and it's insightful... all good things. It basically centers around the graph to the right, which represents a product lifecycle.

The idea is that you start in the lower left hand corner, which is "simplistic" in the sense that it's simple because it doesn't do much. As new features get added, complexity increases but so does "goodness" because the user can do more stuff.

But then at some point you reach the middle of the graph and things get interesting. It's basically the complexity "tipping point", because now when you add more stuff (a.k.a. complexity), goodness starts to go down because users are unable to consume the additional complexity. The only way to increase goodness at this point is to decrease complexity.

That's the gist. I recommend reading the whole thing to get the details.

I like this for a couple reasons. First is that it suggests that complexity is not inherently bad. I couldn't agree more with this. Designers who think "simplicity" is the goal of design live in a different world than I do. I also like that Ward uses the term "unnecessary complexity", which is a favorite phrase of mine. Just because complexity isn't inherently bad doesn't mean that there isn't plenty of unnecessary complexity in most software.

I also like that it helps answer the question, "Hey, my product is complex AND successful, so why should I worry about design?" There's a limit to how many features you can add to a product before they become self-defeating. When your customers start to request features that are already in your product, it's a safe bet that adding even more features is going to be trouble.

So I think the graph represents a very useful concept, and makes it easy to understand.

Of course, like most concepts, if we starting poking on it we can find limitations. For example:

• Most products have problems with unnecessary complexity, and that is NOT what the complexity axis is measuring - but I would fear someone walking away from the graph thinking that complexity in general is not something to worry about until you get to the middle of the graph.
• Ward points out that reaching the bottom right of the graph is not the end of the story. The curve just starts back up again. But in reality, what happens is that different parts of a product are probably following their own paths - some in simplify mode and some in add feature mode, so a single line doesn't really represent a whole product.
• The place where complexity becomes too much is different for different users (and sometimes radically different). So the graph is really representing the perspective of one user group.
  

But these are just nits, because I think Ward's goal was to use the graph to present the concept, not to create a formal process or an accurate depiction of every variation under the sun. And it does a good job at that... the concept is useful and the book introduces it quickly and easily.

Book review: "Small is the New Big" by Seth Godin

The first question is, why would anyone by a book that is actually a compilation of blog posts? Blog posts that are still available for free online for anyone who wants to read them. To answer that, a little background is in order.

Seth Godin is one of the new marketing gurus of the internet age, and runs an extremely popular blog (aptly titled Seth's Blog), as well as being the author is several books that extol the virtues of permission marketing and innovation. But pigeon-holing Godin as a marketer doesn't really tell the whole story. Godin is part marketer, part guru, part motivational speaker, part pundit, part critic... basically he has a strong belief in his own opinions, loves to share them, and enough people find enough of them to be insightful that an entire Seth Godin cottage industry has sprung up around them.

Since a colleague of mine pointed me to his blog awhile back, I read pretty much everything he posts. What I find most interesting is that I only find value in maybe half of what he says. Another 25% is what I would consider to be "motivational speaker crap". And the other 25% I simply disagree with. But holy cow, there's just so much of it, that even a 50% hit rate produces a lot of quality content. His book is the same way (not surprisingly, since it is from his blog originally). So why did I buy "Small is the New Big"? Basically, it was my way of supporting Seth's blog. It provided me a simple way of reading his archived blog entries in handy book form (for example, I could take it along to the pool during my kid's swim class), but mostly I just felt Godin had earned it.

Fortunately for Godin, I bought it online, because if I had picked the book up and turned it over and read, "you're smarter than they think" in big text at the top of the back cover I probably would not have been able to face the cashier at Barnes and Noble. Outside of Stuart Smalley, that's the kind of motivational speaker crap for which I have a very small tolerance. But here's the thing: I think Godin expects exactly this kind of reaction. In his introduction to the book, he says:

I guarantee you'll find some [blog entries] that don't work for you. But I'm certain that you're smart enough to recognize the stuff you've always wanted to do buried deep inside one of these riffs. And I'm betting that once you're inspired you'll actually make something happen.

Why is Godin convinced that I'm smart enough (and doggone it, people like me)? Apparently because I was smart enough to buy his book. But more importantly, Godin knows that his hit rate isn't 100%. He's fine with that. He's fine with being all over the map. But I'm also guessing that the parts that I like are not the same parts that another person would like. It's about taste, not about being right and wrong. He also hits on another point, and to his credit he's self-aware enough to recognize it - many of his posts say what people already know, but there's value in being reminded of it. Reading the book, I repeatedly had the reaction, "Yeah, that's true, I knew that... I wonder how I can apply that?"

The best thing about Godin is he makes you think. He has a knack for speaking in just enough generality that most of what he says feels applicable to your job, while not being so general that it's not useful. Even he act of disagreeing with him (like my disagreement with most of his riff on website design) is useful because disagreement requires thought. And he's engaging enough that even disagreement feels friendly and personable. I get the feel that I could have lunch with him and we could argue the entire time... and yet we'd both leave the meal having enjoyed ourselves with no hard feelings.

I recommend the book. You won't like all of it, but I bet by the time you finish it you'll feel it was time well spent.

Book Review: "The Myths of Innovation" by Scott Berkun

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).

I wonder how much time and research Berkun did on this book before he came up with the idea of orienting the book around myths? Was that the idea all along? Or did it emerge over time? Because it turns out to be a perfect way of presenting the material. First, everyone loves to feel like they know something that other people don't - the truth behind the myths. This "peeking behind the curtain" approach is a great way to keep the material interesting. Second, innovation is such a complex area that it would be very difficult to write a book about what innovation is -- it's a lot easier to talk about what it isn't. But by providing the boundaries via the myths, it inevitably provides great insight into how innovation really happens. And third, myth debunking seems to fit Berkun's auctorial voice. His casual, conversational tone is not only funny and engaging, but it naturally allows the type of speculation and interpretation that is necessary for the topic. In other words, a textbook-style examination of innovation would be a very poor choice.

While I enjoyed the entire book, I particularly enjoyed in the section on the myth of "the best idea wins". In it, Berkun describes the many factors that are involved in whether an innovation succeeds, and how being the "best" is only one of many factors. When it comes to design innovation in established software, the impact of "dominant design" is always a challenge - what is the cost of moving to something better when you have a large customer base who already knows how to use the product? One example in the book is the QWERTY keyboard that we all know and loathe. But to lesser degree this is always the case - I can't convince my wife to move from Paint to Photoshop for editing pictures because she knows how to use Paint. Whenever I try to tell her about how many great features there are in Photoshop, all she hears is "blah... blah... blah... [it will take lots of time to learn]... blah... blah... blah."

I recommend this book highly to anyone who has a job where innovation matters... which is just about everyone.

Book review:"designing the obvious" by Robert Hoekman, Jr.

I recently finished Robert Hoekman's new book, "designing the obvious: a common sense approach to web application design". I enjoyed the book and thought that Hoekman had some good insights into what it means to produce quality design, though I also had some disagreements and found some of his advice to be of limited value in the domain of enterprise software.

One of the things that liked best was the section on "understanding users". This has long been a pet peeve of mine -- while obviously good designers needs to understand their users, I've often felt that running usability tests on design were of limited value. And I think the issue is that we often ask the wrong questions. Hoekman has a great summary of this problem:

For example, if I were designing and building an application used to track sales trends for the Sales department in my own company, my first instinct... would be to hunt down Molly from Sales and ask her what she would like the application to do. Tell me, Molly, how should the Sales Trends Odometer display the data you need?

I would never ask my father the same type of question. My father knows next to nothing about how Web sites are built, what complicated technologies lie lurking beneath the pretty graphics, or the finer points of information architecture. He wouldn't even be able to pick a web application out of a lineup, because he doesn't understand what I mean by the word application...

What my father does know is that the model rockets he builds for fun on weekends require parts that he has to hunt down on a regular basis... If I told my dad he could buy these parts online, he'd be interested. If I asked him how the application should filter the online catalog and allow him to make purchases, he'd look at me like I was nuts.

Molly from Sales would likely do the same thing.

Molly has no idea what your software might be able to do, and she almost certainly doesn't have the technical chops to explain it.

I think this is a great point. We need to understand our users and we need to understand how they use the product (or use our proposed new designs), but we should not be asking them to design our product. We're the professional software designers - we shouldn't abdicate our responsibilities onto the user. It's nice to see Hoekman saying that in print.

I also liked what Hoekman had to say about turning beginners into intermediates. Basically, the biggest proportion of most products' user base is the "perpetual intermediate". Someone who has learned just enough to get by, and has no plans to ever learn more. One of our goals is to help beginners reach this stage. WAS does quite a bit in this space, perhaps most notably in our "Command Assist" functionality in the console, which allows people to transition easily from using the console to using scripting.

The only major problem I had with the book, and it's not all that major, is that it was written with an assumption that bad design happens out of ignorance for many of the principles he is espousing. That people are not doing things the right way because they don't know the difference between the right way and the wrong way. Clearly, this is sometimes true, but I think it's the exception to the rule (at least it is the exception when there are professional usability people involved in the project... and the audience for the book seems to be professional usability people). The simple fact is that there is a cost associated with improving the design of a feature or a product. Designing things well takes more time and people. It usually means that the system is taking on more of the complexity from the user, which requires more coding and testing. Everyone wants good design, but when push comes to shove, I think many of our customers would admit that if better design means fewer features and longer time to market... well, it's not a no-brainer that better design should win the day. It's a balance. Sometimes better design is the right answer, and sometimes time-to-market pressures are too important to lengthen the release cycle to include an expensive, iterative design phase. Being able to tell the difference between those cases is the trick, and not an easy one. But the point is that the "obvious" design techniques that Hoekman discusses are already common design techniques in most shops... when there's time to do them.

But 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.