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.

Call me a Design+OSS fanboy, but UbuntuStudio looks awesome. Finally an Open Source operating system aimed at us designerly folks. I know, I know, all that software has been around for a while, but it will be nice for it to be all wrapped up in a tightly wound package. I’ll let you know if I love it or hate it after I give it a try…

Skype

CoPilot

to a poor design. I stumbled across this newish area of the Apple site this morning. I won’t go into details, just because I’m lazy, but from this designer’s perspective this page is U-G-L-Y. So many gradients and colors and flashing boxes. Not to mention the fact that it has slowed my computer to a grinding halt. Painful. Wake up, Apple…don’t lose your fabulous eye for detail.

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. 

I’m celebrating by taking down the old stylesheets, and letting it all hang out. Happy CSS Naked Day everybody. Here’s to accessibility and an open web for everyone!

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.

Inspired by the most recent Creating Passionate Users article, I decided to try out a new search widget for my blog. It’s still a Google tool, but this new version takes you to a results page, rather than having a limited set of results spew out in gratuitous Ajaxy fashion. Hopefully this new version is easier to use…I sure find it simpler. Heck, I wonder if people are even using search on this site in the first place…

Woah, 2 changes to my blog in a single day…I’m obviously on fire.