Read my latest article: Was away on vacation (posted Sun, 11 May 2008 22:33:00 GMT)

Tip: Save your users 15+ seconds of their day 8

Posted by Robby Russell Thu, 31 Jan 2008 18:42:00 GMT

Since understanding the context is so important when designing interfaces, I wanted to point out one of those things that caused me to shake my head at.

When logging into our Basecamp account this afternoon (via openid)... I was presented the following helpful notice.

know your user
Uploaded with plasq’s Skitch!

What’s amusing in this scenario… is that I’m sure that Basecamp knows that I’m logged in via openid and it is, in fact, displaying the OpenBar across the top of the page. Yet, it’s making this helpful recommendation that I’m obviously already aware of.

What harm is there? Well, in this scenario, I caught it and thought, “wow, this isn’t helpful or informative.” Over time, it’s these short-lived experiences that affect our overall perceptions of the product.

When we’re designing and developing applications, we must be very consistent with how we communicate with our audience. We don’t need to provide them information that isn’t relevant to them.

I’m not picking on Basecamp here, I’m sure that they have great intentions with this, but as a developer, I know that it doesn’t take a whole lot of extra work to avoid small problems like this, which could lead your people to feel like you’re not being respectful of their time.

Saving customers 15-30 seconds is something that we can quantify.

  • 100 customers = 25-50 minutes
  • 1,000 customers = ~4-8 hours
  • 10,000 customers = 40-80 hours
  • etc…

Just a little reminder that it’s easy for us to overlook things like that can make a difference.

Teams Need Healthy Collaboration 2

Posted by Robby Russell Wed, 18 Oct 2006 15:05:00 GMT

A few weeks ago, I was explaining some of the concepts behind Dialogue-Driven Development to Michael Buffington and when I said that we were working to create patterns of Dialogue... his immediate thoughts were on code. I don’t remember the exactly how he worded it.. but he basically thought we were working on a parsing tool for grabbing requirements out of emails, messages, etc. I quickly explained that d3 had nothing to do with actual code and was merely a practice that we as developers and consultants are using to think about our interaction with clients, users, and amongst ourselves.

Just last night, I was chatting with a friend of mine about d3… (names changed to protect the guilty)

context: Harry works in a development team1 of about ten people and Paul is one of his “team”mates.


  Harry: i guess it prevents discussion domination
   me: yeah, that happens as it is sometimes
  Harry: and ensures equal contribution
  Harry: paul does that 
    and he's not very polite about it either
    and will often raise his voice and speak over you
    which is crazy
    kindergarten stuff
  me: hah
  Harry: need a talking stick!

This happens all too often amongst ourselves. While we’re striving to improve our client interaction… we often overlook our own internal struggles to achieve healthy collaboration. It takes discipline by every individual in a collaborative environment to really think together.

So, how does d3 address this? Well, it’s our goal that through mindful dialogue, we can cultivate healthier collaboration in all of our professional (and personal) relationships.

I would also like to point out a few common misconceptions about d3.

Dialogue-Driven Development is about being in the conversation as it is happening… and really listening.

The next time that you’re getting ready to interact with your teammates, ask yourself:

  • Am I contributing something meaningful?
  • Am I listening to others well?
  • Is everybody contributing an equal share of information?

If you’re quiet, try to speak up more. If you talk too much, be mindful of how much you may dominate a conversation. If you’re not participating at all.. why are you there?

1 You’ll be happy to know that Harry also gave his two-weeks notice yesterday.