Experience Design as an Assembly Language

I’m just in the middle of starting a new job leading a group of web developers. Like any good salesman, I’m asking myself the most important question.

What am I really selling?

Many people would say I’m selling code, software and services. I disagree. Why does software delivery have to be so techy and geeked out. In the end, aren’t we just selling experiences? Here are some thoughts on paradigms of assembling code and how selling experiences may change our language of software development.

Models of Assembly
Henry Ford is the father of the assembly line. His model focused on sequential building with interchangeable parts to create products swiftly and cheaply. Between 1908 and 1915, Ford was the first company to use factories employing assembly lines to mass produce automobiles.

In the 1930’s, Toyota took the assembly line a step further, setting the stage for “lean” manufacturing processes. As compared to Ford’s model, “lean” assembly focused less on reducing cost and more on building customer value and reducing waste inherent in the process.

We use a flavor of assembly line in nearly everything.

Our school systems employ interchangeable teachers and manufacture classes of students, standardized with knowledge and thinking. While there are some newer models in software assembly, the premise is still the same. Whether you follow waterfall, agile or lean development, the history of code manufacturing has evolved to offer more value for customers and reduce waste through systematic processes.

Assembly lines sound great, right? Interestingly, assembly of students and software both fall short in some similar areas. Let’s look at the story of Susie and her experience on the school assembly line.

• Conveyor Belt Syndrome
   Susie is forced to be assembled in the same way as her peers. We ignore Susie’s brilliance in math and continue to progress her based on class and age, instead of by skill. We tend to manufacture software the same way. We have a line of classes all ready to be developed in the same way, one right after another. We’ve been given the order of releases and track results based on consistency and release dates. Because of the conveyor belt, it is more difficult to adapt our assembly to those features excelling for the user.
• Lack of Parenting Syndrome
   Susie hasn’t had the attention she needs. She enters the school manufacturing plant ill-equipped to succeed on her own. Some kids just have crappy parents. Good teachers take responsibility and address the problems left by bad parents. Sometimes, we get development with good parents that have well-defined projects. Other times we don’t. In those instances, developers are often forced to take responsibility and prepare everything for assembly based on their own intuition and understanding.
• Pass the Test Syndrome
   Susie has a standardized “quality” test she has to pass each year. Don’t worry, we teach Susie everything she needs to know to pass the test and become “defect-free”. We forget that real quality is about the skills for the real world and ensuring her courses change as rapidly as the environment. We build skills to ensure software passes various tests. But we lose sight of the business vision of tomorrow and ensuring quality is a measure of continual alignment to the end user.

What is Experience Design?
How do we fill these gaps? Enter experience design. It’s the practice of designing things with a focus on the quality of the user experience, with less emphasis on functionality of the design. To Jared Spool, experience design comes right after activity design — or the focus on designing concrete things that accomplish an activity. Experience design instead asks the question, “What happens to the user in the gaps between all those concrete activities?”

As Spool says, sometimes “code works, but experiences fail.” We get handed a list of products, features and tasks based on the customer’s needs and stories. We immediately jump to our assembly lines and develop solutions for each and every activity. Three years later, we look back and only half of the solutions are still being used, users are complaining nothing works and the customer is saying, “If only we would have added feature Y instead of Z.” Ten years later, we end up with 100 systems and different features all glued together with little thought to how poor Susie is supposed to figure all this shit out.

We assemble code that worked, but ultimately it failed.

But our assembly lines were supposed to build customer value and reduce waste? Maybe not. We overlooked the user and the gaps between all those activities that made their experiences great. How does experience design help Susie and our software address Conveyor Belt, Lack of Parenting and Pass the Test Syndromes?

• If the team looks at all the user activities and an holistic experience across all those points based on creating the greatest value to the user, our conveyor belt aligns and focuses assembly on the parts in the right order.
• If the team truly understands the end user and develops a common understanding with the customer, there is greater and more consistent definition of the true problems and shared responsibility between teacher and parent.
• If the team focuses on new measures of “experience” quality, there is less focus on passing the test of the process and more alignment on long term quality for the end user and ultimately the business.

Assembling an Experience
In 2001, 17 software developers developed the Agile Manifesto as a new direction to assemble software. The intentions of the Agile Manifesto were not to prescribe a solution, but offer a philosophical vision.

Most assembly lines do very well at cranking out work. Agile is no different. But if you don’t focus assembly correctly, it will just work to crank out more crap. Here’s an adaptation of the 12 Principles behind the Agile Manifesto and how selling experiences may refocus our assembly language.

• Our highest priority is to satisfy the end user through early and continuous delivery of valuable software.
• Welcome changing requirements — in the form of integrated activities — even late in development. Experience design processes harness change for the customer’s competitive advantage and the end user’s needs.
• Deliver quality experiences frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people, usability experts and developers must work together daily throughout the project.
• Build projects around motivated individuals. Ensure they watch users interact with their products and trust them to create great design.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation, debate and decisions based on user insights.
• Quality software, systems and processes are the primary measure of progress.
• Agile processes promote sustainable business. The sponsors, developers, and users should be able to maintain value to end users indefinitely.
• Continuous attention to auditing end users, technical excellence and good design enhances agility.
• Simplicity–the art of maximizing the amount of work and unnecessary features not done–is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams with solid design principles that guide their decisions.
• At regular intervals, the team and business together reflect on how to become more effective to their end users, then tunes and adjusts its behavior accordingly.

Should we be selling code or experiences? Is there really a difference and what does it mean for agile and lean assembly practices?

Perhaps the biggest question is, “Where do we go from here?” Maybe we should stop and ask our users. I bet Susie will thank us all later.