Recently I’ve been trying to figure out how interaction design can be blended with Agile development techniques. William Pietri and I have been working closely with Border Stylo, a web-based startup located in Beverly Hills. Through a series of short workshops, we’ve been helping them find the appropriate blend of Agile and interaction design techniques for their team, and evolve those methods as their needs change.
Cameron Koczon and Eduardo Prats were at Cooper October 27-29, 2008 for a series of collaborative design sessions. I took the opportunity to chat with Cameron about his experiences working with a design consultancy as his small startup interleaves product definition, development and interaction design in a nimble fashion, without losing ownership if the vision and end results. Lane: Please introduce us to your company, Border Stylo.
Cameron: Border Stylo is about five months old. Our founding team is a group of very good friends from way back. Myself, Diego and Oscar went to high school together, Eduardo is Diego’s little brother, and Evan and I were college roommates. We raised a little money to build a proof of concept of a Firefox extension. Based on our proof of concept, we raised some series A funding and that took us to where we are now, constructing our Alpha release.
Lane: What is the composition of your team? How many people and what are their skill sets?
Cameron: We all wear a lot of hats. Diego, our CEO does investor relations and makes sure we stay the course in terms of our vision. We’re going to do a lot of data mining and analysis and his educational background will help us with that.
Oscar, our COO, is in charge of developing and implementing our marketing strategy. Because many of our investors are international, we plan on conducting an international release of our product. He also does a lot of the work that has to get done at a startup but is not very glamorous. He makes sure the rent and bills are paid. He handles legal, accounting and is involved in hiring. I actually don’t know how he keeps track of it all.
Eduardo and I do visual design, UI design, product definition and some of the implementation associated with that. That’s not sustainable, so we have to bring on some more people to do that.
We have a development team of three people. One, our CTO Ian, is a badass Rails developer and does a great job of keeping our team on track. Another, Evan, does all our front-end/plug in development. The third guy, Thomas is focused on the back end, making our product scalable. Again, we are in the process of expanding the team to a more sustainable size, but for now that is the full dev team. Lane: How did you hear about Cooper, and why did you choose to engage us?
Cameron: I was exposed to Cooper through the Stanford Design School. I was convinced that Cooper’s methods are important for web-based startups. I can’t image designing any sort of product without thinking about the user and the interactions associated with that. Sometimes that doesn’t jump out as being particularly important, it doesn’t scream at you like a cool graphic, but that is really the make or break for a product. I was already very excited about Cooper, so when we got our funding, and it was time to hire an interaction design team, I said “why wouldn’t we just outsource that?”
In my mind, there’s a lot of risk associated with bringing on an interaction designer, particularly if you believe in the Cooper methodology and want a team of two interaction designers. That creates all sorts of additional issues, like does the team you hire work well together? There is too much other stuff going on to have to worry about it. Even if these two interaction designers are excellent on their own, are they going to work well together as a team? All you really want is a phenomenal interaction design.
Lane: I’ve heard some people at startups say they wouldn’t outsource interaction design to another firm because they feel the design is so closely tied to the core concept of the product. How would you respond to that?
Cameron: I understand the concept of keeping the core elements of your product in house, but I don’t know if this rule is as applicable to interaction design as it is to development. The way in which we have been working with Cooper actually goes a long way towards bringing powerful interaction design skills in house. We aren’t just sending our ideas out into the ether and waiting for a neatly wrapped UI to show up on our doorstep. We are an active part of the process. This enables us to learn from the Cooper team and apply relevant techniques to future design problems. After CooperU and this intensive, Eduardo and I are well equipped to address upcoming design problems.
If your founding team already has a phenomenal interaction team, go ahead and keep it in house. If not, teaming up with experts for your crucial design challenges will have benefits that echo throughout your company. The process of developing a compelling interaction design does more than just help you figure out your product interactions, it helps you further define business goals and business definition within the context of your users.
Lane: You’ve completed two days of a three-day intensive working with a Cooper team. What is it like working with a Cooper team?
Because they so clearly have design principles engrained in their minds, and because they are fantastic designers, they are able to just bang through our problems really quickly at the high level.
Lane: How has your working relationship with Cooper evolved? How has the engagement we created meeting your needs?
We were, possibly naively, considering hiring you outright to just do our design. We planned to ask you to treat us the same as any other client. You suggested that we could do that, but because startups change so much as they grow, a large up-front design engagement might not be appropriate. We don’t know who our users will be or what our product will be like a year from now. We can do some research, and create personas, but we don’t know if that’s where we will end up. So, why throw all your energy and money into something that’s going to eventually change? Because of this, you suggested a micro version of your process that is more iterative.
I don’t think a larger company would take the results of a long design project and say “this is good, but we’re going to iterate on it, and in three months it’s going to be totally different.” Instead, they’d say “OK, thank you, we’re going to spend the next two or three years getting this thing ready to go.” It’s different for us. We want to start with something small, and once we have users, we want to do more research, and then revise the design as the product grows. We’re not going to scrap the design entirely, but we’re going to go back and question the assumptions we made, based on the results of the research. By doing a quick version of the process, we’re ready to do this multiple times. As our organization gets better and better at it, I think that’s going to be a really powerful competitive advantage.
You suggested this new way of working together, and then following that, it became clear that Agile methodologies and the Cooper methodology work really well together and reinforce each other. If you’re applying Agile, you’re going to apply it to your UI and interaction design.
The next big milestone for the relationship was when you and William (who is an Agile specialist) came down to L.A to introduce us to Agile techniques, and review some key interaction design methods. Now the whole organization is on board and we have a corporate culture around this methodology. Everyone likes Agile, and the results have been fantastic.
At this point we’ve well defined our problem as an organization. This week, we came up to SF for a three day session with Chris and Stefan. We took what we thought was a good persona and in a matter of minutes, Chris and Stefan made it an awesome five persona group which makes perfect sense. I have no problem talking about the personas, it’s like they’re real people. It happened so quickly because they were well chosen.
Once we had our personas, we built scenarios out for all our big problems. We know what we’re trying to refine in this iteration, and now we’re actually working through the interaction design. It’s an interesting mix of learning by watching them go through the process and actually getting work done. It’s a little different than a class because there are deliverables. We’re creating the actual interaction design together. After this, I can go back to the development team and say “this is what we want to make.” Instead of talking about the problem in the abstract, we can say “here’s what has been in our heads, down on paper. Let’s talk about how we get this done.”
Lane: In the story you’re telling, there are a couple of other elements you forgot to mention that I think are important to your success. Initially when we spoke, you suggested you bring in Cooper for a classic design project. At the time it was clear to me that you guys needed an apprenticeship. You needed to bring in a lot of techniques and wisdom into your organization. At the same time, you needed assistance to jump start you and take you to the next level. The first thing I recommended was that you identify people in your organization who would be responsible for user experience and interaction design.
Cameron: Right…we attended CooperU.
Lane: You and Eduardo at that point had been wearing a lot of hats, but you jelled as the interaction design team. His skill set around graphic design and visual design and your skill set around front-end UI development and CSS were nicely complementary. The two of you attended CooperU which gave you a really good grounding in the Cooper methodology, the tools that we use, and the language that we use. As our client, it’s possible to work with you at an accelerated rate because we’re all speaking the same language, and we’re all working in the same methodology.
I learned about your desire to use Agile development methods when you acquired Ian who was an advocate of Ruby and had done Agile projects previously. At that point, it was clear to me that you needed to be introduced to William, an Agile coach also interested in blending Agile and user experience techniques. So, you guys went to CooperU, and then you and I had some ongoing discussions about starting to do work on your own. We spent a little time planning a small round of user research that you did independently. Then, on a later trip, William and I came down and we spoke to your whole organization.
An important premise of Agile is that design isn’t owned by any one person, just like the product isn’t owned by any one person; it’s owned jointly by everyone in the organization. When William and I came to L.A, it was a really good way to bring everyone on board. We presented some options for interaction design and Agile techniques and the company chose what techniques you wanted to use.
After that, you started using the planning game, and story cards, and stand-ups. Now that everybody is aligned as a group and using Agile methodologies, you and Eduardo can split off to do a more focused round of design thinking. The guys back home are bug fixing on the last iteration, which is a good time for you guys to spend some time thinking about the interaction design and behavior. On this visit, you’re doing a three day intensive where we’re quickly evolving your persona set, developing scenarios and then running through your design at a high level, so that when you and Eduardo return back to your team, you are then starting to execute on what we’ve been working on here in San Francisco and taking it to the next level.
Cameron: I expect at the end of this intensive, we’re going to get some crucial documents that will easily guide us for a month or two, giving us plenty of work and opening up a lot of questions. Working with Chris and Stefan, we created scenarios for the most important interactions users will have with our product. As we worked, we sketched the interactions in OneNote and Illustrator. We now have pictures and handwritten instructions about what these interactions will look like. This is a different way of working than just talking it through and going home. I have a PowerPoint presentation that shows who my personas are, what their scenarios are, and which scenarios we addressed in this intensive. I can disseminate that throughout my organization and everyone can start getting onboard and start to say “Would this work for Sydney?” “Would this work for Luke?” That’s great for the whole organization.
Between design and development, the thing that’s going to be really valuable is that we can show the developers the pictures. Each interaction is laid out with 10-15 roughly-sketched screens. Interactions are shown, but without the final visual design. We don’t need extensive notes about what these interactions are because Eduardo and I were in the room. We save you guys’ time in the sense that you don’t have to write it up in a way that explains it. You put it on us as a startup to go back to our organization and explain what it means.
Lane: Some people say using a design agency is expensive. How would you quantify the value you got for the money you spent?
Cameron: We raised a good round, but we try to be very cautious with our money, and we don’t do a lot of excessive spending. I would say if you look at it as “it’s this much a day” it feels like a lot. When you look at the big picture of what you get in return for your money, it is downright cheap. We were able to sit in a room with experts and actively address the various design problems associated with our site. We jumped at this chance because we feel that the interactions of our site are phenomenally important. Basically there is no more work for us to do on the most important interactions on our site. That’s enough to keep our developers busy for a long time. That frees us up to do further interaction work. When we came here, I had some idea in my head about how good it was going to be, and all of my expectations were left in the dust. I would never have guessed how quickly Cooper could go through the primary interactions of our site and give us something truly exciting. The saddest part is that now i’ve seen all these interaction design ideas but I have to wait for them to come alive on our site. We have a strong Alpha now, but I have this great vision of what it will be like at the end of the next iteration. It’s killer trying to contain that excitement.
Lane: So, if you had to put a ratio on it, if you guys tried to work through all this by yourselves, how long would it take?
Cameron: I just don’t think we would have solved the problem at the same level. Our product would be worse. It’s not a ratio of some sort; we just wouldn’t have gotten here. We would have achieved a solution; there are any number of “solutions.” We never would have achieved a solution that’s as good as what Chris and Stefan put together, and certainly not as quickly. There’s no question. And if we were going to hire people of their caliber, it would have taken a great deal of time and cost a great deal of money. I don’t necessarily think that a full time, expert UI team is necessary at the beginning of a startup particularly when conserving money and being resourceful are so critical to success.
I want to show progress to our investors as we try to raise new rounds, and I want to indicate to them that I’m not using their money poorly. I didn’t go out and buy a Ferrari and we didn’t get ten assistants. I want to come back to them and say “This is the interaction design.” Frankly, they like the fact that we went to a professional firm. They know something about the skill set of our team and agree with the decision to bring on a professional firm to help create a top-notch UI. It also gives more credibility to our UI. Something like that can be pretty subjective, but when you have an authority figure, it gives you a stronger position.
Lane: When do you think it’s appropriate for a startup to hire an external interaction design firm?
Cameron: As soon as possible, but there are a few things I think a startup should do before going to an outside firm for anything. First, I would say the team should be very sure of what it is that they are trying to create, what their vision is for the product / service, and what the business goals associated with that vision are. Unless the team is on sure footing with respect to these concepts, the UI design work will not pack the same punch.
Next, I would suggest thinking seriously about who the user of the product is. Understanding your prospective user (or doing actual research if you already have users) will go a long way towards creating meaningful personas and thus meaningful interactions.
With respect to Cooper, it was very helpful for Eduardo and I to have read About Face and then taken the Interaction Design Practicum. Being on the same page in terms of methodology and terminology enabled us to really get the most out of our time here.
The more interesting question might be when to completely move all interaction design in house. I think we will have a nice transitional period where we do increasing amounts of the work and ping Cooper for high level advice. At some point that might go away, but I am not even convinced of that yet. There is an extent to which it is like having a UI expert on your Board of Directors.
Lane: What do you think are the benefits of being an Agile organization?
Cameron: I assume that the name comes from how it makes you feel as an organization, which is that you’re nimble, flexible. You respond to problems quickly, and you move through numerous iterations. For a startup, Agile solves a lot of problems. First, it helps prevent against founder myopia. Just like everything else in a startup, product visions need to evolve. Still, it is very easy for founders to take a long-view that doesn’t enable them to see short term opportunities. Working in multiple iterations provides very natural breaking points for the team to take stock of the business, the current environment, where they are now, how things have changed, and where they want to go.
The specific Agile methodologies we have employed are daily stand-ups, which are a 10 minute discussion at the beginning of every day where we talk about what we did yesterday and what we’re going to do today. Stand-ups are attended by designer and developer teams. Every Friday we do a recap of the week where we talk about how things went and drink a few beers, and it’s kind of fun.
There are some other Agile techniques in the pipeline for the development group, e.g. pair programming and test-driven development. The thing that was particularly valuable for us was the way we defined our next six-week iteration. We got everyone from the organization in the room and had a town hall meeting to get the “big themes” we need to address in this iteration. We wanted everyone to feel like they had a voice. This is a startup, everyone gets excited, and everyone gets to say something.
Eduardo and I do a lot of the product definition. We pared those big themes down into the core ones and created a list we used to do the planning game. In the planning game, we put the individual bits of functionality that we wanted in the next iteration on individual index cards. Then, we sat down with development and said “we developed these from the big themes and this is what we feel is important. Let’s talk turkey about how to prioritize and see how long it will take to do them.” It went fantastically. Everyone is more excited about the iteration because they were all part of that. That makes a big difference.
Then we used the task board. We put up the cards in order of priority, and we use that as a part of the weekly recap to see how we’re moving through the cards. Some of those things like putting up a task board are one-off, but the difference has been substantial. Communication was an issue for us before. Everybody was really hectic, running around. We were all wearing a lot of hats; you’ve got a lot of stuff to do, and you don’t always have time to also think of what other people were doing. So this forced everybody to stop and say “whoa!” let’s take it easy, let’s think this through.
Everyone is in a much better mood. Communication is shared in a much better way. We even had mini-stand-ups while we were up here. We called in to do some catch ups and let them know what’s going on. No-body feels out of the loop, everybody is on the same page, and it seems to me that we’re going to hit the iteration and I think it’s going to feel really good.
Lane: How do user your experience activities and Agile development activities fit together?
Cameron: In the same way that developers have a series of tasks that have time associated with them, we’re going to have that same sort of task board. When I think about Agile plus UI I think about the fact that currently we don’t know who our users are. Right now we are in development mode, so we have no users, soon we’re going to have early adopters, and then (if everything goes well) we’re going to have a large user base using the product. These groups have different needs, and I want to be constantly thinking about these needs. As we develop the product to address the new users, I want the UI development to keep pace. That is for me the most exciting element of agile UI development. It is this idea that our UI will constantly be evolving to meet the evolving needs of our user base.
Lane: How does that the design work we did this week fit into the development story cards? We identified certain personas as being important for the near term release and developed some stories about the key interactions those personas will have with your product. We then developed sketches which defined the framework of the product (i.e. the moving parts and how they interact).
Cameron: Amazingly. It’s foundational. You need a common foundation, a common ground to talk from. In the same way that it was nice to have everyone agree on some big themes for the product, it’s really nice for everyone to agree about whom are we designing for, and what are their needs? Whole cards can be thrown out; when we can ask “Does Luke need this?” Depending on which persona it is for, it can also affect the priority. That’s an amazing common ground from which to speak. I think it enables you as a developer and designer to rally for the user and make your point about where the product needs to go. These need to be iterative too. I want to evolve the personas and scenarios as we learn more about our users and their behaviors.
Lane: You brought the themes from your town hall meeting to this intensive. What was the relationship between the ideas that everyone had, and the user stories cards you created, and the scenarios and design created while you are here at Cooper? What was the continuity here, how do they relate to each other?
Cameron: The themes came up a number of times in the meetings as we considered who the personas were, and as we thought about what they might do. Here’s an example of a theme. We wanted to move as much functionality from the UI of our site to the UI of the plug-in. Our feeling is that too many social networking sites, such as Facebook, want you to remain in the walled garden of their site. We want to encourage users to leave our site, fully explore the Internet, and share that experience with their friends. As such, we need our functionality to be decentralized and detached from the site. We don’t want to interrupt your browsing experience, we want to enrich it. Given that theme, a number of times in the design meetings, we would say “if we do that, we are forcing them to come back, and that goes against this concept of decentralization.” As we already thought that through and made up our minds about its importance, it became a legitimate design consideration.
Lane: Let me know if I’ve got this right. What I think you’re telling me is that the whole company is participating in decisions about “what is our product” “what should it do” and “what matters.” You and Eduardo are then taking that input, boiling it down, and coming back to the group to say “this is what we heard.” That synthesis of what the product is, and what it should do, is feeding the story process and it’s also feeding the design process. They are related to each other, and you and Eduardo that are the link. You have a clear vision of the product in your heads, and you direct the feature set and behavior definition.
Cameron: Not entirely. The vision has spread fairly organically throughout the company and I wouldn’t say that we have some unique access to it. This is what enables us to have large meetings in which anyone who wants to can speak up about the product. I think what Eduardo and I do that is very important is to take that vision and distill it down into relevant functionality and then we prioritize that functionality so that the team is always working on the most important issues.
What do you think? Join the conversation in Comments
