A few years back I was excited to attend WalkaboutNYC, an event organized by the folks at Harvest (they make that awesome time tracking and invoicing app). Basically, you walk 'about' and insert yourself into the offices of a bunch of different startups, usually for 20-30 minutes at a time before moving along.
In speaking with Danny Wen and Naama Bloom about how the idea came about, they mentioned that the Harvest team was always interested in how their clients and colleagues worked - the spaces they created, the way they organized themselves, and such - so they invited themselves over to check it out. The experience was so valuable that they wanted to share it with other people, and that's how Walkabout was born.
Recently I've been wishing I could drop in "virtually" and hangout with some product development teams. My interest is not unlike Harvest's: how do others do it? How do they organize themselves? What's the flow? What do they value and find effective?
Learning New Tricks While I'm not a visual person, I've always been most comfortable leveraging design early in the process. I'm not even a big fan of wireframes, I just like to dive right in rough-sketching and seeing how it feels (thanks for my partner in crime, Felix Widjaja, for enabling it). I find it brings a certain amount of creative freedom, and that failure is part of the process of getting it right.
As our product team came together for Packet, however, I was immediately confronted with different ways of doing things. Aaron Welch (who founded and ran the Drupal dev firm Advomatic) and Ian Coffey (previously with Voxel and Engine Yard) brought some especially great things to the table. When I asked them for their magic tricks they started talking about past success with user stories, continuous deployment, and sprints/epics. All new to me!
Killing the Design Phase Despite the vast experience of our development team, it was pretty obvious that everyone had to figure out a new way (the "Packet Way") that combined the best aspects of each of our experiences, talents, and resources. With a huge body of work to accomplish - lots of code to lay down - design was punted into the corner and only recently made its way back. I'm really glad it did - mainly because it has been a very useful tool within the context of the flow setup and maintained by Ian, Aaron, Jake and Emiliano.
Tool? Did I just call design a tool? Yup! My argument is that there shouldn't be a "design" phase in product development - that a designer can really help by embodying the role of the user and bringing that attention to the entire development. It's no different than user stories or sprints - it's a way to focus, to make decisions, to judge results, etc. There is no reason everything has to just stop and wait for "the design" to be made pixel perfect, especially when you're in startup mode, primarily because it's the ideas and insights provided by the developers and product managers as they respond to the
In the last few weeks we've really combined forces - working with designs to flesh out concepts and push forward decisions that really impact development and our business.
I look forward to sharing the results of the process, and looking at when and how we undertake a more formal design process (hint: I think there is room for that as well!).
Happy coding + designing + coding + designing everyone!