Ask “What if” Questions

What if we could travel 5 miles in less than 5 minutes?

What if we could watch movies in our own homes?

What if we could buy things for a whole day without using any paper money?

What if we could communicate with friends on the other side of the world without leaving the house?

I hope you noticed that, in fact, we can do all these things today. However, a mere 100 years ago, these questions would have been dismissed as pipe dreams by most people. But dreamers dream, designers design, technologists build, and before you know it, really difficult problems find solutions.

This is why I try to take the long view when thinking about design problems. Today’s technology is ephemeral, it will be gone before you know it. But when you find solutions to the big problems, those interactions can last for centuries. So the next time you start a project, instead of asking, “What would the UI look like to solve this problem?” (or even worse, “What will the architecture of the software look like?”) ask “What if we could ________?” And fill in the blank with a really challenging problem.

After all, if you’re like me, you didn’t get into technology to solve tiny little problems. You got into technology to make lives better & jobs easier. You got into technology because there are challenging problems to be solved. What if you solved them?

LinkedIn looks so fresh & clean clean

One of my little delights in life comes when I see a website or tool that I use has been refreshed. This morning, I was surprised to notice that LinkedIn has a new look. Check it out:

New LinkedIn

There’s a nice entry up on the LinkedIn Blog that talks about the three major changes:

  1. System Navigation
  2. Profile Snapshot
  3. Customizable Widgets Panel

Of course, I don’t think the redesign can really be summarized by these 3 independent features. The fact is that the site has a completely new feel, and I doubt if you asked an everyday user what changed since yesterday they certainly would not list those three items. Instead, they would likely remark about the sweeping changes overall…then they would perhaps notice the feature changes.

Fighting the Backlash

Redesigns like this can be extremely challenging to implement for a company like LinkedIn. Not so much in the sense that they’re difficult to build technically, but for the backlash that is sure to follow. Already one user has commented on the blog asking for the ability to access the old version:

I was shocked by the new interface cause I was addicted to former layout for 4 years as I was shocked by the new layout of Office 2007 … I’m still using Word 2003.

So … Is it possible to have for some time to come (3 or 4 months) the choice to switch on and off the new interface.”

Carmelo Cutuli

I never really understood the mentality that one would want to switch back and forth between old and new versions of a tool in order to learn the new one. So often in the physical world we leave our old junk behind, like when we trade in an old car for the updated model. But I guess that’s the difference between physical and digital: if you really wanted the old version back you’d be able to get it. Alternatively, there’s no way to get the old version of LinkedIn back. It’s completely gone (until LinkedIn decides to give access to it).

I’ve often thought about whether it would be possible to truly incrementally release design changes like the ones LinkedIn did. If they released small changes each week, would it have the same desired effect? I doubt it. Sometimes you just need to release a new design upon the world…it is jarring to some, but others will be impressed.

Count me in among the impressed. Well done, LinkedIn.

View Josh’s LinkedIn Profile

"Pretty" Software Applications

One of the most difficult expectations for me to overcome with respect to my coworkers is the idea that I’m here to simply make the software look pretty. It’s difficult for so many to understand. I do understand principles of typography, layout, color, and design in general…and yes, I do have the ability to decorate an app to make it seem “prettier” to the untrained eye.

The thing is, I’m not necessarily here to apply typographical, layout, color, etc. changes to a system. Before that can happen, the tool has to have a logical flow. Input fields that are displayed have to make sense. Everything that has been placed on the screen up to this point must be there for a reason. I take it as my first job to understand exactly why you’ve placed that input box above that drop-down menu, for example. Sometimes this part of my job is easy. Other times it is not.

My point is that I will not (and cannot) make your system look nice unless the basic interaction part is already taken care of. In fact, having a cordial interaction with the user is core to the system looking nice. Sorry to burst your bubble, but the colors themselves don’t matter if the user can’t figure out what he’s supposed to do.

The UI needs tending, and it can’t just be fixed at one point in the process…beginning, middle, or end. It needs attention throughout the design and implementation phases. Each development iteration can also be an interface design iteration. Slowly but surely I’m learning that it’s not a good idea to just try to save an interface in one fell swoop. Everybody involved in the software development process should take this lesson to heart as well.

For now, I’ll keep busy on projects chugging away at finding interactions that make little sense from a user’s perspective and helping to ameliorate these issues. It’s my hope for each project that one day I’ll get to the point where I can help the user have an experience that is not only easy, but fulfilling and emotionally pleasing as well.

On the Misleading Lexicon of Agile Development

Reading GirlWhatever 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.

Agile Design, a response to my friend’s quandary

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

Agile anti-pattern: Developer-focused retrospectives

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 Gotta Start with Imagination

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 Design of CruiseControl.rb

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.

On Iteration

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