Whatever happened to clear, consistent language? Why do we use words that have inconsistent meaning in contexts where they’ll be unfamiliar? Why, oh why?

Day in and day out I work with clients in an Agile development setting. I use words that have been trained into me, that I’ve been taught over and over again. But when I sit back and think about these words, they just don’t make sense. Let’s look at two of my favorite examples. First, some standard definitions:

Story - the plot or succession of incidents of a novel, poem, drama, etc.

Narrative - a story or account of events, experiences, or the like, whether true or fictitious.

Sounds pretty familiar, no?

Well in Agile these words take on a whole new meaning. A story is the encapsulation of some sort of requirement, based on a given user’s needs or wants. It generally takes the form of:

As a [user]
I’d like to [some action]
So that [resolution of need]

But wait, is that really a story?

A narrative is the document that describes this story in detail. Chock full of high level objectives, UI prototypes, test cases, and other minutae. If you asked a person on the street what a “narrative” is, there’s no way they would describe it this way.

So why do we insist on using these terms, with their off-the-mark definitions? I don’t know. They probably seemed all cutesy and different at the start, something that sounds fun and light when compared to heavier terms like REQUIREMENTS DEFINITION DOCUMENT. When it comes down to it, “Story” just sounds less beefy than “Requirement.”

Damn Agile, You Just Stole My Words

Aside from the simple misappropriation of terminology, I have a bigger issue with the use of these terms. In the Design world, “Story” and “Narrative” have real, relevant meanings that align with the standard definitions of these terms.

Both of these terms are used to describe, in detail, a user’s experience, either today or in some envisioned happy future. The Narrative is generally a more detailed version of the story, which includes a narrated scenario in the context of the tool’s use.

I might be splitting hairs, because I think the Agile use of these terms tries to get at the same thing…but they just don’t. An Agile Narrative generally doesn’t tell a real story in detail, it describes a requirement in detail. Likewise, an Agile Story describes a requirement, not a user’s journey.

In Conclusion

We have to be careful with the words we use. In the end, we’re all trying to build software that solve real human problems. Surrounding these problems is real human drama that can, if described well and designed for, be turned into happier situations. I believe the use of words with alternate definitions muddies the water, but certainly doesn’t get in the way on a day-to-day basis.

Whatever words we use, we have to be sure that our solutions fit into the contexts of our users. We must ensure that our software fits into our users’ everyday stories.

This evening Kynthia’s thoughts got me thinking. Among other things, she said:

“[W]e design heads get in this place where, just because we wouldn’t be caught dead releasing something into the wild, we think there is nothing to learn from it.”

My brain took her thoughts on a tangent and went this way:

So since I started my job at ThoughtWorks, my role has pretty much been defined by this exact issue. See, we use agile development methods, which often means that the stuff I’m designing might be built tomorrow, or at the latest in the next few weeks, which leads to some pretty interesting questions, such as:

• If I had to hand over my design in the next [time limit], what would be the most important part(s) to get across? So what should I spend my time on?
• How can my design(s) make the greatest impact in the short run?
• How can my design(s) be flexible enough that they’ll support more advanced interactions and further redesign (without simply adding features) in the long run?
• How much does my design cost, in terms of real dollars and development time? Is there anything I can do to make it less expensive without hurting the users (too much)?
• Will the brilliant, awesome, amazing design I’ve just created embrace change if it turns out users really don’t like something about it? Or will it fail miserably…which might be a good thing if it motivates the product owners to spend more money to fix it.

Indeed, I believe us “design heads” need to wrap our brains around the idea that the “ideal design solution” can be super-difficult, and sometimes impossible to implement, if for no other reason than the person with the money doesn’t feel like splurging for a great user experience. Given this situation, it’s important that we release our ideas into the world early and often, even if they aren’t perfect. Putting our ideas out into the world lets them get stomped on, beat up, and improved to the point where while they may not be ideal, they’ll at least be better.

Iteration, baby, that’s the name of the game. It turns out when we designers draw and write and specify and prototype and mock-up our designs in our oh-so-ritualistic way, we end up with an unintended by-product: intimidation. See, even if our brilliant, perfected ideas aren’t intimidating to the teams of programmers that have to build them, they’ll often be super-intimidating to those who have to pay for them. See, the more realistic/difficult/etc. our designs look on paper or other prototyped form, the higher the perceived cost. Let’s look at a formula to really help this sink in:

C(p) = -I(L)

Now, I haven’t taken a math class in years, so that formula probably means nothing at all. Ignore it for now. What I mean to say is that the higher the perceived cost, the lower the likelihood of implementation. This all seems pretty simple, and it is, but sometimes it’s hard for us designers to break away from the idea that we need to perfect everything about our concepts. In fact, when we do this, it can be to our disadvantage.

Oh, and don’t think we’re not intimidating ourselves either! When was the last time you decided not to take on some project just because you knew it would take too long to really “do it right?” Yeah, it happens to me all the time too. We designers know how to intimidate ourselves as well.

So rather than perfecting, why don’t we try biting off just a little bit at a time? Design in terms of small, implementable, simple solutions to the problem at hand. Then expand on the concepts, and build them all the while…just a little at a time. Sure, some of that implementation will have to be redone as you go, but if it truly improves the end design, do it.

Of course, when you’re designing and building an enterprise level application, there’s a lot more structure and process that has to be involved in design, but I think for Kynthia’s case, an Agile development process is somewhat ideal. It gives you the opportunity to take a stab at a problem, implement something simple, learn from what you built/pondered/etc., and iterate.

Anyway, sorry for taking your thoughts on a tangent, Kynthia, but thank you for getting my brain cranking this evening.

On most software projects, there is a far higher percentage of developers on a team than any other role. In general, this works to the team’s advantage. The developers, after all, are the ones who make what everybody else works for come alive.

In a retrospective, however, it is important that no one group of team members is favored over others. This is harder than it may seem, especially when the developers make up more than half of the team.

The way most retrospectives I’ve been a part of have worked is some variation of the following:

1. Individuals think of a few things that have gone well, and a few things that have gone less well over the past set time period
2. These thoughts are put on post-it notes, then placed on a wall
3. Individuals read all the thoughts and vote for the ones that they agree with (each person has a limited set of votes)
4. The retrospective facilitator tallies the votes and discusses the highest vote-getters with the team, and discusses ways to fix problems and continue successes

Now, as you can tell this is a quite democratic process. The problem is, when the ratio of developers to business analysts is 4:1, you start to see the topics discussed err towards the technical. If you’re lucky, you have a facilitator who realizes this and steers the conversation in a direction that helps the entire team, not just the developers.

Moral of the story: Make sure you’re paying attention to the distribution of people on your teams, and the topics that are covered in your retrospectives. Sure, the idea is to make software, but the process is only going to improve if the entire team is learning from their steps and missteps.

It’s true, there’s definitely a time and a place for getting one’s hands dirty. Sometimes there’s just no way around digging into the details and making things right. Sometimes, even as a designer, you’re going to have to play with the CSS to get the alignment right, because if not you, who will? Still, it’s important to remember that at the outset of a project, and even beyond that, limitless imagination is a requirement…because limiting yourself to a technology will hamper one’s ability to truly solve a problem.

It becomes so easy to get wrapped up in technology, but we need to remember that a client and user’s true need is to solve a problem, not have a piece of software. Before deciding to build software, we should consider the true problems, and discover what should be done to fix them. Sometimes it’s a policy that has grown stale. Other times it’s as easy as adding a whiteboard to your kitchen so that people don’t forget to communicate. And even other times it might be imperative to create a digital, internet connected, multi-touch capable whiteboard in the kitchen so that it can sync up with your local events database, rather than a new intranet.

My point is that we shouldn’t underestimate the power of imagination. When exploring design solutions. Your first idea will (in all likelihood) not be your best. Look beyond the obvious.

Oh, and be sure to staff a tactical, imaginative designer. 

The last few weeks I’ve been doing a lot of CSS writing. While this doesn’t necessarily fall under my job role, on many projects I end up doing it because I’m the “designer”…therefore I am put in charge of implementing style. Whatever. Turns out I kind of like it, so I let it pass, but we need more developers who understand CSS like the back of their hand. We can also use more designers who understand and write CSS as well. If you’re either, send me an email (jevnin at thoughtworks.com)…we’re hiring.

Anyway, what I really came here to say is that the world absolutely, positively needs a tool that is dedicated to CSS testing. I do enough switching between browsers, browser versions, and operating systems to make one sick. In my opinion, this is a giant gaping hole in the process. If our users can’t see our content as we intend, the web-based tools we build will not be useful, if at all usable.

Of course, the browser companies could do their part to follow the standards. Some, for the most part, already do. Others blatantly defy the rules. Nonetheless, since these fellows don’t play well together, we (the builders of the web sites and web apps) are in need of a good testing tool in this area. I’ve Googled for some solutions, but really they all either look crappy or they charge up the wazoo.

There’s obviously a huge need for this tool. Where’s the open source solution?

Banana = Vision

Love it or hate it, Bruce Nussbaum makes some great points in Are Designers the Enemy of Design? I think I buy most of it.

Is Design a specialist activity? If it’s done well, generally yes. Is that likely to change? For the most part, I don’t think so. Will ‘the everyman’ have the opportunity to design more and more in his lifetime than ever before? Absolutely, so we better start learning how to share Design Strategies.

Also, can Apple move past two major strikes (closed source everything and unsustainable products) and really survive the long haul? I just don’t know anymore.

Anyway, have a read for yourself…

Update: Sorry about the dead links…I think they should be fixed now.

If you’re not looking at this entry on my site, it’s not gonna look quite right. For the best view, look here.
Just wanted to let y’all know that I’ve fixed my blockquotes so that they’re hanging. You’ll notice that I not only hang my blockquotes, but list items as well. Check it out:

This is what it looks like when I have a blockquote. Notice how the quote mark does not get in the way, and there this block of text has perfect left-alignment with the rest of the text on the page.

And what about lists?

1. Here
2. is
3. an
4. ordered
5. list

and

• Here
• is
• an
• unordered
• list

Why do I do this hanging business?

Notice how all the text on the page aligns perfectly on the left? That makes it easier for you to read the text on this page, and after all, this blog isn’t just about me…it’s about you too! Typography is fun!

If you’ve heard me talk about work lately, you have probably heard me talk about an Open Source project I’ve been working on with a handful of other folks at ThoughtWorks. Previous to now, it’s been “privately public,” existing on servers where people could get to it, but not so public that we were letting people know that we were working on it. Well, yesterday CruiseControl.rb finally went public, and I’m proud to say that I’m an Open Source contributor. I’ve dreamed of saying that for a while…

For those that aren’t familiar, CruiseControl.rb is a tool that software developers will use to monitor whether the software they are creating is “Building.” And it helps them to fix problems when they come up. That’s probably the simplest explanation you’ll get about what CruiseControl.rb does. Notice that I said simplest, not most complete. The original CruiseControl is a ThoughtWorks-led Open Source project, and was the first Continuous Integration tool…as far as I know.

Anyway, let’s talk about what went into the design of CruiseControl.rb. For today, I’m going to talk about the concept of iteration, and how it was applied in a unique, but purely designerly way on this project. I’ve blogged on this concept before…but this will serve as proof that we’re eating our own dog food here at ThoughtWorks.

My view of design is that you have to try out similar concepts over and over again before you’ll get to your final idea. The first example I want to point out was when we were working out what the CruiseControl.rb logo should look like. I talked over some ideas with the team, sketched out a bunch of options, and then created some high-fidelity prototypes in Photoshop. Here’s what I came up with:

Now, the first thing you might notice is that in the end we used none of these ideas. Our final result, shown below was a conglomeration of a bunch of the concepts used in these designs. In the end, we threw out all of these designs in favor of a combination. This means that as a designer, I have to be ready to trash ideas at the drop of a hat. I’m happy to do it though, in favor of a better design.

Now, it would be easy enough to apply this iterative design idea simply to the graphic design of system elements, but we used this concept throughout development. The dashboard is a great example of this. There were endless options when it came to possible ways for the information to be laid out. In the beginning, we started with this:

Pretty straightforward solution. A table with all the basics laid out inline. An iteration later, we played with some of the graphic treatments, and had this:

A couple new concepts there. The status is in a color that helps to quickly perceive the state, even without reading. The build buttons disappear in favor of a progress indicator if a build is already in progress.

But at this point we were just feeling a bit underwhelmed with the way that each project’s information was laid out. All text was equal with respect to visual hierarchy. There was nothing to signal what was the most important information at a given moment. And we just knew there had to be a better way to lay this stuff out. So we gave it another shot:

There were a number of variations of this design. In this version, you see a thought bubble bearing information about things people said about the most recent build. Other versions had no thought bubble, but portrayed the a failing project’s name in large text displayed as negative space in the red gradient. The idea behind this was that if a team set up a monitor across the room from where they were developing, they would be able to see which project was failing at a glance.

In the end, we bounced around between a number of ideas and ended up where we are today:

I’d say it all worked out pretty well. To all the users of CruiseControl.rb: I sincerely hope you enjoy it. Your experience while using the tool was heavily taken into account. Part of ThoughtWorks’ mission is to create excellent software, and in this case the software is Open Source…a concept many of us at ThoughtWorks very strongly believe in. With CruiseControl.rb we have tried to marry an excellent User Experience with an Open Source license, and I hope that you agree that this project is a success.

Rock on.

“It’s not an iteration if you only do it once!” - Fred Sampson, in the UPA Voice

Developers & designers: Please, please don’t just implement your first idea. Think about it for a few minutes. Sketch it on paper a few times a few different ways. Nine times out of ten you’ll find that your subsequent ideas are better than the first. That, my friends, is what iteration is all about.

Just when you’re looking for some inspiration, a quote from someone famous is bound to help:

The most important consulting rule that I follow is: “Never solve the problem as stated.” Why? because it is invariably the wrong problem, usually being the symptom rather than the cause. Find the root cause and solve that, and then the original problem usually disappears.

- Don Norman

Good call.