When Worlds Collide: Conversation with Maria Giudice of Hot Studio

sxsw09

Maria and I have already started our SXSW Core Conversation When Worlds Collide: Human Centered Design Meets Agile Development two weeks before the event in Austin. The Core Conversation format is a speaker or two in conversation with the audience. Below we respond to a few select questions.

About the Presenters

Maria Guidice is CEO and founder of Hot Studio, a human-centered design studio in San Francisco.
Alon Salant is a principal and founder of Carbon Five an agile software development firm also in San Francisco.

Our companies have worked together over the years on a number of successful projects. We find our collaboration continually challenged by the differing perspectives of designer, developer and client. We love working together and are always looking for ways to do it better.

We Want to Hear From You

Join us for this conversation in Austin Sunday, March 15, 3:30-4:30pm. If you can’t make it, we have created a Google Moderator series to solicit questions from you. Please vote for questions you like and/or add questions and topics that you think we should discuss. Alternately, ask questions as comments to this post. We want to hear from you.

Let’s Get Started

Why is the issue of waterfall vs. agile so emotional for design and engineering teams?

Alon: We all work hard to do the best work we can for our customers. Software developers have struggled for years with the mismatch between heavy-weight planning processes, the ideal world they are based on, and the messy work of getting software built in the real world. Agile software processes provide an approach that deals very well with the real world while retaining strong professional rigor.

Committed agilists bristle at approaches that do too much planning for too far in the future. The further out you plan the more inherent uncertainty there is and the greater the chance that you are wasting energy on speculation.

For designers I think you can flip this argument around. If you start building something without knowing what you are building there’s a good chance you build the wrong thing and have wasted all the time and effort you put in to it.

Obviously there’s a middle ground somewhere. It turns out to be surprisingly hard to find.

Maria: I think the reason that this issue is so emotional goes to the very core of the fundamental difference in the way designers and engineers think about design.

The waterfall process affords designers the time and space to learn about the problem and craft a solution based on insight from understanding human needs, wants and desires. They then can craft a plan of action based upon big-picture thinking and strategic insight. From there they can be specific about details and functionality based on how the system works contextually.

The agile process oftentimes does not afford designers the time to think and requires them to design details out of context. This way of working puts them at great unease and anxiety that they are designing things based on hunches rather than validated user research.

Engineers, however, feel very comfortable working at a detail level that can be changed (theoretically) later on and can build towards a functional product sooner rather than later. Engineers may not understand the need or value to spend the time upfront—”why not jump in early if you have the freedom to change your mind?”

Think of the two processes like carving in marble vs. building in clay. It can be very difficult to switch design mediums they have worked on their entire professional life.

What is your greatest satisfaction when working with designers?

Alon: Designers have the gift of being able to represent ideas and solutions visually, in a form that all stakeholders in a project can understand and respond to. A designer can engage business owners and developers in a conversation about product requirements, priorities and potential solutions then turn that into a visual representation of one or more solutions. The visuals create a level playing field and focus the attention of all participants in a project. I love the role of designer as facilitator.

What is your greatest satisfaction when working with engineers?

Maria: We look to work with engineers that consider themselves equal contributors to the design process. Hot Studio is lucky to work with the folks at Carbon Five for this very reason. Too often designers view engineers as builders of “their product” and they miss the value of thinking about a design problem from an entirely different mindset. Great engineers understand the value of human-centered design and are active participants and contributors throughout the design process. Great engineers bring to the table that unique perspective that does not focus on limitation, but one of unique possibility.

What is your biggest point of frustration when working with designers?

Alon: Many designers, particularly user experience designers, feel they need to understand a problem in both depth and breadth before they can create meaningful solutions. Even when a project schedule and budget allow for up front research too often it is not enough for the designer and they feel they are working with incomplete information.

Projects can rarely afford exhaustive up front research and I get frustrated when designers use this as an excuse instead of coming up with an alternative approach.

I would like to find a design approach that could use some research up front to set a strategic direction and then break up a large problem into smaller problems to be tackled incrementally. Ongoing research could continue to be a part of the design process, conducted incrementally as the next problem to solve comes in to focus.

What is your biggest point of frustration when working with engineers?

Maria: I have worked with many engineering teams over the years, and like designers, they can come in many different flavors. I get frustrated when engineers focus on limitations, not possibility. When design thinking becomes limited to meet a tight budget or the need to jam as many “features” into a product based upon a set timeline, you run the risk of prohibiting “out of the box thinking” that can have an adverse effect on maximum customer experience. What some engineers may think the experience is “good enough”, designers may conclude that “no it isn’t”. This is a big point of frustration for designers regardless of the problem they are trying to solve or the process they are working within.

What will people come away with after attending our core conversation at SXSW on March 15th?

Alon: Our conversation will give people insight into issues in the collaboration of designers and developers and ideas about how to work together better. It is an opportunity for attendees to learn more about human centered design and agile software development and to challenge our ideas on those subjects.

Maria: I think people will come away with thinking that one size does not fit all. Follow a process, whether it’s waterfall, agile or a hybrid between the two, based on the type of project, the team dynamics, and the client’s need.

Can we all get along?

Alon: Sure. But it may be harder than we think. For this collaboration to be truly successful designers and developers need to better understand each others’ priorities and fears. It’s too easy to sit back in your own world view and say, “They don’t get it. If they did they’d do things my way.”

Maria: Absolutely. It really comes down to respect, empathy, and good communication from the client, to the designers, to the engineers. To quote the critically acclaimed “High School Musical 2″ film—”We are all in this together!”

Together, as design collaborators, we can produce great things together and hopefully, have a positive impact in people’s lives.

This entry was posted in Process and tagged , . Bookmark the permalink.
  • Alex Cruikshank

    As a developer, this tension between agile development and human centered design strikes me as a cross-cutting concerns problem. Developers have learned to dive deep into implementation because nothing focuses requirements and surfaces problems like working code. Design is an inherently broad activity, since the most important aspects of a design apply to an entire application and seldom draw insight from individual features. Finding a common methodology is like fitting a box of square pegs and a board full of round holes. There simply isn’t a configuration where everything is going to fit.

    If you step back from common methodology, however, there is plenty of opportunity for implementation-minded developers to cooperate with strategic-minded designers. There has to be an initial phase where designer work independently of the developers to map out the broad concepts. Ideally this phase is short, completed (subject to revision) before developers begin, and results in a style-guide. Since development is agile, there is no reason why this phase can’t continue throughout the project (it usually does), but as the application grows, the cost of design changes multiply. In the second phase, the designers put on their agile caps and work to enforce the design, revise it according to feedback, and solve more specific UI challenges that fit within the units of work used by the developers.

    To a certain extent, the balance between the time designers spend huddled up working on the big picture and the time designers spend working side-by-side with developers is a trade-off between quality and cost. Unfortunately, some of that cost is born entirely by developers, so it is always going to be hard to agree upon where the balance should be struck.

  • http://patternpark.com Luke Bayes

    I think this talk will be great, and I hope there will be a transcript or recording somewhere for those of us that can’t make the conference!

    It could be helpful to hear more about how (or if and when) Hot Studios separates Aesthetic Design from Interaction Design.

    I have seen organizations separate these roles so much that the aesthetic design isn’t even mentioned until the end of the project and others where it essentially informed everything from the very first meeting.

    When a strong visual design is implemented too early, there are obviously scheduling issues, engineering efforts can be hampered by the tyranny of the pixel-perfect expectation, and visual designers can be frustrated by the inevitable compromises.

    On the other hand, delivering bland, stubbed wireframes until later in a project can lead business owners to be anxious about what they’re really going to get, how far along they really are in a project and generally feeling emotionally disconnected from their own product.

    For me, this separation can be difficult to balance, has far-reaching impact on how a project can feel for everyone involved, and in hind-sight at least, it rarely feels ‘just right’.

    In closing, I guess the question would be:

    How does Hot Studios separate Aesthetic from Interaction design, and how does this decision impact your technology and business partners?

  • Jeremy

    It seems to me that one can view design and development as one continuous proecess. The process begins with many potential ideas, some of which get fleshed out as a handful of possible designs. Of those designs, most fall away and a select few become more refined and detailed models. Eventually, the few models are wittled down to one solution that is then transformed into a functioning final product.

    I think that one of the big challenges is to figure out when it makes sense to begin development in this continuum. I think agile developers could be involved fairly early on, even at a point where there are still several competing designs. I would love to see a project where the developers quickly mock up several solutions and then through an iterative process, drop the lesser designs and fully implement the best one.

    When is the best time to transistion from pure design to implementation? And what are the criteria we should use to identify this milestone?

  • http://www.uidesignguide.com uidesigner

    The core problem I see with agile and have felt for many years now as a UI designer is the desire for programmers / developers to complete things quick. They start to get into this zombie like state sprint and iteration after iteration to go faster.

    The quality starts to suffer and then all that matters is functional completion of stories. This cycle is counter-productive to aforementioned AGILE iterative process because teams tend to want to go faster so they can complete more stories. A problem really begins to develop if your product owner is not on board and doesn’t give the development team or the UI Staff the power to refine, revise, and refactor a design.

    In many cases the UI developer is left scratching his head because the application and interactions are not coming together. It’s more than just communication, it’s about the mentality of constant completion. Drive towards the sprint goal at the quickest velocity possible, but only complete things to a “done” state (programmatically).

    The only way AGILE starts to work is when the UI designer throws himself out of the conventional agile loop and starts to construct his own methodolgy and work patterns to accomodate the sprint, iteration, etc…

    I cover this on my site.
    http://www.uidesignguide.com/2009/02/25/agile-ui-design-series-ui-design-in-an-agile-project-cycle-part-1/

    I find peace and harmony begin and the development and design worlds align themselves when you as the UI person become able to change rapidly. As I simply state in my article. You have to be quicker than the quickest programmer. Only then will you be able to bring in proto-typing, usability testing, and design reformation. If the iteration, sprint, is moving on 2 week cycle. You need to stay 2-3 weeks ahead. In my future article I will be talking about this. A UI designer in an agile enviornment becomes a Time Traveller, blurring the lines between sprints, iterations, and refning the decisions of the design in an inside outside process.

    This can only happen though with support. If the prouct owner or the business owner doesn’t believe in proding the UI staff this time. You are doomed to a mediocre product that is built fast, but suffers from inconsitent features, interactions, and bugs.