Products are produced by using a process – the way people organize themselves to get things done. Whether it is a formal process with a name or just the habits of working that get built up in a culture, nothing is produced without some kind of “way” of doing things. Companies are always looking for the process that will help them be more efficient, get a better result, and create innovation. So new processes are constantly introduced to serve the needs of particular situations.
But what happens when processes developed independently achieve wide adoption and come into contact with each other? Do they provide synergy, or do they get in each others’ way? The answer may very well be “both.” User-centered design and Agile development provide a case in point.
Evolving a Process: Contextual Design
Processes are when people within companies try to get their work done they think about and discuss how to work; they try out different approaches, borrowing techniques from other places and inventing their own. If they’re successful, they may formalize the process and sometimes even give the process a catchy name and write books about their “way” of designing systems. But any new process originates within a particular work context, history and culture and tends to reflect that culture. This is exactly how Contextual Design (CD) itself started at Digital Equipment Corporation in the US.
CD was developed to support innovation in design through a deep understanding of users. Like most processes, it combines and repurposes techniques that came before. Contextual Inquiry, the field research technique, was an adaptation of ethnographic and grounded theory methods Karen used in her doctoral dissertation. The affinity diagram came from the Total Quality movement. And paper prototypes were an adaptation of the Participatory Design approach developed in Denmark. [fusion_builder_container hundred_percent=”yes” overflow=”visible”][fusion_builder_row][fusion_builder_column type=”1_1″ background_position=”left top” background_color=”” border_size=”” border_color=”” border_style=”solid” spacing=”yes” background_image=”” background_repeat=”no-repeat” padding=”” margin_top=”0px” margin_bottom=”0px” class=”” id=”” animation_type=”” animation_speed=”0.3″ animation_direction=”left” hide_on_mobile=”no” center_content=”no” min_height=”none”][ref] All these elements came together into a process that worked for Digital’s developer-centered, non-hierarchical culture.
This early version of CD was fine within Digital, but when we left and started InContext in 1992 we learned what worked for Digital didn’t always work for other companies, different products, or different corporate or country cultures. And so CD evolved to address new circumstances – and as we expand it to new industries and new types of problems, it keeps changing. For any method to stay relevant, it must evolve from the original business culture it grew up in.
CD was just one aspect of an industry-wide push towards user-centered design. Platforms were changing throughout the ’90s and ’00s: WYSIWYG, direct manipulation, the internet and web, mobile phone interfaces and touch screens. These new platforms posed new challenges in developing usable designs and made it critical to work with users who were not developers. Careful interaction design and visual design became more important as end-users became less technical. “User Experience” (UX) has now become the umbrella term for a user-centered focus in development: field research driving requirements, interaction design iterated with users, usability testing, visual design, etc. All these new techniques require a new role – the UX professional. They are now part of organizations – each creating their own “way” to get the requirements, the function, the structure, the interaction, and the look right.
The challenge of software development
In parallel to user-centered design, another process challenge faced product-making companies: delivering the product on time. Delivering the right thing on time is an age-old challenge – it is the holy grail of controlling a product development environment. And coding is just another “way” of working – people working together guided by a shared understanding of what is to be made and the steps to get it done.
At the time Contextual Design was born the waterfall method of software development was the rage – define what you want as explicit requirements, design the implementation to build what the requirements say, write the code, and test to see you built the right thing. It’s simple, logical, and very well suited for the supplier/client relationship beloved by the government.
Unfortunately, too often it didn’t work. It turns out to be very difficult to exactly specify every detail of a complex software system, to ensure that your specification does what you expect – and to ensure it’s useful in the real, messy world of work. To develop more reliable specifications and ensure they were correctly implemented, the software development community produced more and more complex methods of modeling requirements, the data itself, system behavior, and implementation architecture.
The other big problem with waterfall was time. The whole system was specified at once. It might take 2 (or 5, or 7) years to go from initial conceptualization to final delivery using the waterfall approach. This frustrated marketing, management, and everyone else. If you were wrong, it was a very big deal to fix and a very long wait to the next release – and you were always wrong, to some degree. You could get a good score on the maturity of your software process and still not excite the market or move product in a timely way.
This was the context in which Contextual Design method was developed. Multiple modeling techniques were an expected part of development practice. So it was natural for us to include models in CD – the work models to reveal how people work and the User Environment Design (UED) to show the structure of the system as experienced by the user. Such models were a natural extension of the way coders already worked. And Contextual Design – like other user-centered design methods – promised to improve the accuracy of requirements, offering some confidence that your 2-7 years of development would produce something that was essentially correct. So long, that is, as your requirements haven’t changed.
In parallel to all this, IT (Information Technology) departments were building and delivering code to internal business users. And if it was hard for product makers to get clean requirements from customers outside their organization, it was even worse to get requirements from the business. Why? Because the people making the tools for you are just down the hall – it’s just too easy to run over and say, “add this,” “make me that.” IT is always prone to becoming just a technical secretary – at the beck and call of senior users.
Small local changes makes looking at things from an architectural point of view is very hard. Each department developed their own little version of ordering, or project management, or scheduling, and their own glue code to make it all work. This is the bane of IT departments – a million special-purpose systems, unintegrated, each with its own interface. This is the world in which single–sign-on is an exciting development – because it is so difficult to achieve given existing systems.
To prevent falling into the “technical secretary” trap, IT folks looked for a process that would give them some control over the systems they were developing. They looked to various waterfall methods – the Rational Unified Process (RUP) being the latest – to impose order on the requirements coming from the business. But the result was that the internal team was perceived as highly unresponsive. It should be easy to get software from an internal organization – but instead, heavy, formal processes with many required steps and elaborate intermediate deliverables created a long, slow, cumbersome development methodology.
Worse, it seemed that no matter how formally the IT group communicated and how carefully they made the business say what they wanted, it just wasn’t ever right. The business was hardly ever happy once they saw what their requirements turned into. Business and IT tried many things to handle this problem – putting work experts into the IT organization to help translate requirements to engineers; heavy change order processes so the business had to go through pain if they wanted to change requirements; Joint Application Design (JAD) to get better requirements from business stakeholders; formal contracts between IT and business – and still the requirements weren’t right, and still the business wasn’t really happy, and still development took way too long.
Evolving a process: Agile Development
It is this IT culture that birthed Extreme Programming (XP), one of the first Agile methods, and this culture informs much of Agile methods today. Forget getting the requirements right, says Agile – just write simple stories describing what the user should get from the system. Make them simple – put them on an index card so no one is tempted to make them too elaborate. Keep them short, so we can code up a bunch of them in just a 2-4 weeks. Then check with the business partner. Show them what we’ve done. If they like it, good – if not, little harm done. We only invested a few weeks of work; we can go back and fix it. The process is fast, it produces value quickly, and we don’t need all the big heavy Business Requirement Documents and many, many meetings to figure out the entire strategy and architecture. Just do a little at a time.
Of course, Agile methods are more sophisticated than this quick summary suggests. They include coding practices which make the quick iteration and rework possible, as well as people and process management to keep everything on track. But the core insight of Agile is to use fast iterations to produce measurable customer value, getting a course correction from the customer at the end of each iteration.
It’s no accident that this approach grew up at the same time as rapid prototyping was becoming popular as a requirements gathering technique. Rapid prototyping is another method of putting a system design in front of stakeholders to get early feedback. Everyone in IT was struggling to figure out how to get the business to articulate what they really needed in their applications. Agile’s rapid iterations of code is just one further step from rapid prototyping – wrapped into a larger coding and project management process.
When worlds collide: Agile meets User Centered Design
So we have the parallel evolution of two processes: user-centered design and prototyping for the front end, and Agile development for coding. Both processes address getting requirements right, but they come at it from different points of view, leveraging different tools, skills, and organizational roles, and different cultures. UX focuses on the design of the user-facing function, layout, and overall user experience; Agile assumes you have an idea of what to build and focuses on how to run a team to develop and check it out quickly. You’d think they go together well – and they can – but in practice it hasn’t proved to be so easy.
Bringing the two approaches together is made more difficult because Agile itself is evolving. XP assumed easy access to users because of its IT heritage; Scrum started in manufacturing companies where software requirements were internal and assumes the Product Owner can answer all questions. These assumptions don’t hold true in modern software product companies – so introducing Agile means it has had to change. What do you do when your customers don’t work in the same building? How do you decide what to build when you don’t have the business telling you what they need? How do you embed Agile development in a product development process that has to include marketing strategies, making a business case, developing a product support structure, and supporting sales?
Moreover, businesses (including executives, development managers, product managers, the support organization, and coders themselves) are used to a waterfall method – plan, design, code, ship. They are usually not ready for the mind-shift Agile requires. Adopting Agile often means, “develop in short iterations” without changing any other part of their business practice.
And yet, as the Agile community itself has come to realize over the past few years, Agile development must expand its scope if it’s to support product development organizations well. Traditional Agile development starts with “Write user stories” – but what goes into those stories? Who gets to say, when you don’t have an internal business customer sitting next to you? Defining a “Customer” or “Product Owner” role just begs the question – how do they know what the real customer wants? How do they know what the real users do on a day by day, minute by minute basis?
Traditional Agile methods don’t have a workable answer to this question – but user-centered design does. Just like the development processes so many years ago needed to get into the field to understand user requirements, Agile also needs a reliable requirements process. Just like the previous development process needed to work with and iterate with users directly – not customer representatives – Agile needs to work with the real end-users. Then Agile as a development process can pick up where user-centered design leaves off. Where Agile is weak – in getting sound, reliable information from and about users – UCD and user experience professionals are strong. These approaches don’t just go together well. They need each other.
That is why we at InContext have been so heavily involved in the Agile community since almost the beginning. Our paper, written with (then) Lisa Baker of LANdesk in 2004, was the first to describe interleaving UX and Agile work in the way that has since become standard. We wrote Rapid Contextual Design in 2005 to provide techniques useful in an Agile context. And Hugh’s publication User-Centered Agile Methods describes in depth the relationship between UX and Agile, and provides strategies for integrating the two.
We’ve also defined services to help our clients bridge the gap – to implement Agile in a strong, effective, and user-centered way. If you’re struggling with this transition, we’d love to hear your story. It doesn’t have to be a train wreck when Agile meets user-centered design. Agile doesn’t displace or replace UCD. But it does mean that we have to think about how people and the processes can work together well.
When methods collide it challenges us to find the third alternative – it challenges us to think of new ways to help the people building products work together better. We believe that Agile is the best way to build products with a controlled process and in realistic time frames. And, of course, we believe that getting to your users in the context of their real life is the best way to understand what they are doing, what they might need, and how to transform their world. It’s been fascinating and challenging to be at the forefront of bringing these best practices together.
References
Participatory Design
Ehn, P. Work-Oriented Design of Computer Artifacts. L. Erlbaum Associates Inc., Hillsdale, NJ, 1990.
D. Schuler and A. Namioka (Eds.), Participatory Design: Perspectives on Systems Design, N.J.: Lawrence Erlbaum Associates, 1993.
Contextual Design
Beyer, H. and Holtzblatt, K., Contextual Design: Defining Customer-Centered Systems, Morgan Kaufmann Publishers Inc., San Francisco (1997).
Holtzblatt, K., Wendell, J., Wood, S., Rapid Contextual Design: A How-to Guide to Key Techniques for User-Centered Design, Morgan Kaufmann Publishers, San Francisco, CA, 2005.
Agile Development and User-Centered Design
Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Jeffries, R., Kern, J., Marick, B., Martin, R. C., Mellor, S. Schwaber, K., Sutherland, J., and Thomas, D. The Agile Manifesto, 2001. http://agilemanifesto.org
Beck, K. eXtreme Programming Explained: Embrace Change, second edition. Addison-Wesley, 2004.
Beyer, H. User-Centered Agile Methods. Morgan & Claypool Publishers, 2010.[/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]