“Self Design only works in those instances when you are the user and there’s a lot of users just like you.”
Closing quote from an interesting article by Jared Spool on the pros and cons of designing for yourself, using 37signals as a prime case. I find that most people believe—without any real evidence—that most people are “just like them.” There’s the rub, eh?
“The point of the 4-day work week is about doing less work. It’s not about 4 10-hour days for the magical 40-hour work week. It’s about 4 normalish 8-hour days for the new and improved 32-hour work week. The numbers are just used to illustrate a point. Results, not hours, are what matter, but working longer hours doesn’t translate to better results.”
Jason Fried nails it again. Emphasis: results are what matter.
David Heinemeier Hansson at 37signals was recently approached by a recruiter about a Ruby on Rails position, saying “it looks like you have an interest in this new and exciting framework.” Note to recruiter: David invented Rails. Dorks. David writes up that experience and others in the current job market, where recruiters are so anxious to get the word out they forget about basic research and personal communication.
By the way, while we aren’t likely to spam you, we are hiring.
Beautiful font here plus a cool concept: “The plan for simplifying and improving our alphabet, entitled “Alphabet 26 was first presented in Westvaco Inspirations 180 in 1950. It recommended the use of only one symbol for each of the 26 letters.” (via SVN)
“One of the things that I think is interesting is we’ll actually see organizations and companies appointing what they refer to as a CEO or Chief Experience Officer. And that Chief Experience Officer is supposed to have a view across all of those experiences… When we look at what’s going to be happening, it is absolutely huge.”
Here’s a conclusion to Jason Fried’s post yesterday: The difference between trying something and using something. Designers must design for trying and using. As designers we want both experiences to have positive results, so we have to design for both. However, if you ever have to choose between the two, lean towards “using”.
iPod is my favorite example of this. Try handing an iPod to someone who has never used one before and ask them to find and play “I am the Walrus” by the Beatles (assuming your iPod is properly equipped with the classics). Most will fumble around for quite a bit before they get the hang of the wheel and the center button. However, once they “get it”, it’s all goodness. The experience is optimized for “using” at the expense of the “trying” experience and that makes a huge difference.
P.S. Jason’s comment about the shallow nature of most reviews today is spot on. I find most tech product reviews in the range of mildly amusing to useless. There’s a huge opportunity for a new type of reviewer or review model to come forward with in-depth, “using” reviews. I’ll be the last person to step in line to buy a Zune. The size affects the “trying” before you even pick it up. However, I have to wonder if the tone of the Zune reviews would change if all the reviewers were forced to use the device as their primary music device for 30 days before they wrote anything. I know we’d get a clearer, fairer picture of how good or bad that product really is.
“You can’t bottle up inspiration. You can’t put it in a ziplock, toss it in the freezer, and fish it out later. It’s instantly perishable if you don’t eat it while it’s fresh.”
Our development team is getting great mileage from 37Signals’Backpack application to share to-do lists and knowledge about our project. Randy and I are currently working on an internal web application for the Physical Facilities department of the Church, an app so big that we have seven developers, four QA engineers, two DBA’s, and a few managers to keep tabs on it all (about twice the size Flickr’s team).
We use a mixture of Extreme Programming and Agile / Getting Real methodologies, with pair programming (and pair designing – more on that later) and two-week iterations. We are having a lot of success with this approach, most of which coming from prototyping and user testing the app before it hits development, and using the prototype as our spec. We have very little documentation – the prototype is it.
But recently I started using my Backpack account to manage my to-do’s (an upgrade from paper scraps). I then added a few short lists to keep focused on the major features of the next few iterations. Then it hit me – I shared the page with Randy, and we started adding things to each others’ lists, pushing things onto a “future enhancements” list if it fell below priority.
Then we shared the page with our business analyst Pablo, who signed up for an account and started keeping his own list of to-do’s, a list on which Randy and I could easily jot down business questions for Pablo to answer.
And just last week I shared the page with Lohan, our lead QA. He signed up for an account, and created his own lists of questions for Randy, Pablo and me, and we just edit the to-do’s with answers and questions of our own.
The lists are ever changing and easily added and deleted. No history is kept; none is needed. A list usually lasts about one iteration, and after those two weeks I wipe it and start fresh.
The best part is the app has little barrier to usage – Basecamp, for example, takes more of a commitment to project management. Backpack is the opposite; kindof an anti- project manager. It is a perfect light-weight collaboration tool for us. Agile in its own design, and helping our team be agile by letting us quickly jot and share thoughts and priorities.
There’s a great story over at 37signals about how their webapp, Basecamp, is being used by Lotus Outreach to do some truly wonderful things around the world with a small international volunteer staff. I love seeing the Internet used for such good.
