New Language, New Design

This blog post was originally published by Nitor on May 23rd 2018 while I was working there as a service designer at Nitor. The post has since been removed from their website so I republished it here (although without the great animations by Tommi Koirikivi featured in the original).

It is an under-appreciated fact of the human condition that our thinking is constrained by our existing language. First of all, our routines and instincts guide us to use familiar concepts like "the design phase" or "project goals". Second, even if we are able to break our routines and reflect on the limits of our language, we will essentially have to invent new language to think in ways that our current way of talking doesn't allow.

In 2017, Gilbert Cockton, professor of Design Theory at Northumbria University published a paper titled "New Process, New Vocabulary: Axiofact = A_tefact + Memoranda" to do exactly that: create a new vocabulary that allows us to talk about Interaction Design without the baggage of expectations that have nothing to do with how people actually design.

TRAPPED BY OUR OWN MODELS

Cockton criticises the way most people see design as a linear processes with homogenous work stages, such as understanding phase, concepting phase, implementation phase. Cockton calls these Rational Idealized Linear Engineering Design (RILED) models. Essentially, Cockton argues that we have become trapped by the "ready-made design" of RILED that promises certainty, absolutes and uniformity. He contrasts this with "design-in-the-making", the way actual human beings create things.

An example of RILED thinking criticised by Cockton: Design Thinking process by Interaction Design Foundation

At Nitor, we are very conscious of the downsides of waterfall projects where phase-gates between research, design and implementation stop teams from learning as they develop a service. However, Cockton puts the same blame also on more enlightened user-centered design processes that imply that certain stages of design have to begin and end before others begin. Even worse, these processes constrain design into a series of steps for creating an optimal solution for an initial problem, leaving few opportunities to expand beyond the initial problem statement. Even if we build iterations and non-linear movement between the phases into our models we still talk about design as sequences and phases: we are, in Cockton's terms, held hostage by our “RILED language”.

FROM PHASES TO DESIGN ARENAS

To move beyond the dominant way of talking about design in terms of linear processes constrained by an initial problem or brief, Cockton draws from the field of “Creative Design” to argue that user-centered design outcomes arise from choices in four design arenas:

• Beneficiaries: Understand and specify the context of use

• Purposes: Specify the user requirements (ends)

• Artefacts: Produce design solutions (means) to meet user requirements

• Evaluations: Evaluate the designs against the requirements (p.752)

However, these design arenas should not be thought of as a sequence of phases like in traditional UCD processes but as separate spaces of work which can lead to each other and take place in parallel. For example, creating artefacts may change our understanding of the beneficiaries or the purpose. The outputs of design should be able to generate insight and outcomes larger than any initial design brief of design challenge.

In practice, design work flows from one design arena into another by integrating work across arenas either sequentially or concurrently. Sequential integration takes place when moving form one design arena to another, such as making adjustments to evaluation criteria based on improved understanding of the purpose. Concurrent integration means working on multiple design arenas and simultaneously integrating the results using resources such as personas, scenarios and use cases. Integration requires effort and is always dependent on the expertise of the designers themselves: "integration can be concurrent or sequential, but it is never automatic” (p.755).

WORDS FOR WHAT WE CREATE

Not satisfied with just breaking the linearity and centeredness of RILED processes, Cockton also proposes a set of new words for talking about what is worked on in design.

1. Instead of beneficiaries who benefit from our work, we should be talking about the design arena of anyficiaries: all the people we affect either positively, negatively or neutrally. This switch in perspective enables is to look at our work not just in terms of people we have set out to help, but also the impact our work has on the world. (p.752)

2. The goal of design is to produce an artefact: the final released product, service or other object. Work in the other design arenas is valuable only inasmuch as it helps improve the final artefact. Cockton's concept for these other spaces is memoranda, latin for "things to be borne in mind". The purpose of memoranda is to be integrated into other design arenas and ultimately help create the final artefact. (p.752-753)

3. The artefact is the final result of design, but on the way to the artefact we also create a series of pre-final versions that are not the final artefact. These versions are antefacts which are created and developed until the final artefact is ready. To address the design arena in which antefacts are worked on until the final artefact is reached, Cockton proposes the term a_tefact (pronounced ahtefact). (p.753)

4. For Cockton, design means working in multiple design arenas and integrating their memoranda to make sure that the a_tefact delivers value. The result is an axiofact, value that has been made through convincing connections with apt memoranda. From this final piece comes the subtitle of Cockton's paper: Axiofact = A_tefact + Memoranda. (p.755-756)

BRINGING IT TOGETHER

The end result of Cockton's paper is an "un-RILED post-centric design process" that is balanced, integrated and generous, i.e. BIG design (p.756). In BIG design, work consists of episodes where work takes place in multiple design arenas with memoranda and a_tefacts being developed and integrated both sequentially and concurrently. An episode might be a project or some other stretch of time that makes sense locally and individual episodes may focus more on some design areas, but they are not phases in which work only concerns some aspect of design.

The four design arenas expressed in a “Design Arena Canvas”

The advantage of Cockton's BIG design, as presented in the paper, is that it helps us talk about the richness of design work while simultaneously providing us with a clearer set of words to describe what we are trying to achieve at any given project. The downside of letting go of our existing RILED models is that BIG design doesn't tell us how to do design: since there are no steps or process to follow, there is no set fo instructions we can follow.

However, there are a few good lessons in the BIG acronym that we can strive for: maintain a good balance between design arenas, put effort into integrating memoranda to create valuable a_tefacts, and embrace generative design that is able to go beyond any single problem statement or design brief. We see potential in this new way of thinking.

JUST THE BEGINNING

The language we use matters. In the coming months we will continue to explore how this new language describes the way we design digital services in Nitor teams, and how to extend this way of thinking from just design into end-to-end delivery of digital services. We hope you'll join us for the ride.

Finally, we would like to thank you to Panu Korhonen from Nordkapp for opening the conversation on Cockton's research. We look forward to an exciting conversation!

Servitization makes the world dumber, but we can fix it

At the core of servitization is the idea that the customer doesn’t want a drill, they want a hole. While seductively obvious, a danger lies within.

Say you apply this idea to create a new turn-key kitchen installation service. No longer will the customer have to wonder which materials are water-resistant and how long you should let the sealant dry, we’ll pick the materials that fit your kitchen and come install it in your home!

What was previously just a product business model (producing/importing kitchen appliances and materials) has been turned into a service business model (providing new kitchens to homes that need them) and if offered at a competitive price, the service will surely deliver great value for everyone! Market capitalism!

Let’s take closer look. Services are always part of someone else’s journey of fulfilling a need. Let’s say that this visualization represents the customer journey before and after the “servitization” of kitchen acquisition, with the responsibilities of the customer in blue and the service provider in orange:

Before:

After:

What happened was that we increased the orange parts and decreased the blue parts. Better service, right? Well, more service would be correct.

And now that we have more of this service, we need a service designer. They will design how the customer interacts with the service, how we deliver the service, what happens in each phase and how the material and people are choreographed over the course of a service experience. Rock solid!

However, if you think of service design as the analogy of product design, you give the service designer the job to design every part of the service. And because service is delivered anew every time, you want the service to be delivered as designed, and that’s where things risk going dumb.

With a detailed design, you need detailed implementation: routines are documented into processes, roles and responsibilities are drafted to make sure the service delivery organization works in a predictable way, and little by little the service becomes a metaphorical machine that can only do one thing. We end up with more boring jobs and a slow decline in employee skillfulness.

But it’s not just the service provider organization that suffers, customer experience might worsen as well. As the service provider becomes more rigid, the whole journey loses adaptability because we made it more orange. The service doesn’t adapt to different customer needs or changes in customer preferences in the way that the product did, because the customer could have done the parts they were responsible for in any way they want.

Unlike what you might expect, I’m not advocating for a total Do It Yourself revolution. Instead, the tipping point in this narrative was the moment service design was thought of as the design of services, as if a service is something you design well and be done with it.

In their article “Designing for Service: Creating an Experience Advantage”, Shelley Evenson and Hugh Dubberly point out that a service is design because people, products, places and systems interact every time to create i.e. design that particular service experience. The authors then propose that what is done beforehand is designing for services, a sort of meta-design there the conditions and limitations are put in place. The result is an assembly of people and places by whom the service is designed as it happens.

For me, designing for services opens a completely new perspective into taking people and organizations into the service design process. Perhaps more importantly, it helps me separate the role of the user experience (UX) designer from service designer in digital services, since a UX designer is looking at a service from the perspective of a customer’s needs and outcomes while a service designer reaches into how the service providing organization is designed.

Do you think we should talk more about designing for services? Or is the role of the service designer just a hype thing and we should stick with user-centered design? Probably stuff on services and co-design coming in future! 

People over principles

The last month of my life has been a nosedive into the Scaled Agile Framework, i.e. SAFe, as a new member of the Nitor Delta team. I admit, I was initially suspicious of a systems-thinking heavy framework that gets sold to executives and managers alongside slogans like "only managers can change the system" and "leadership is imparting excellence into the organization".

But the best way to approach SAFe is through the SAFe principles: a list of nine principles which act as a kind of step-by-step logical induction of the Lean-Agile philosophy that underpins SAFe. Through them, I was convinced that correctly applied SAFe is not a tool of control but liberation, and I'm happy to share with you how I came to that conclusion. Below are the nine SAFe principles rewritten to emphasize their ability to distribute authority and agency in your organization. 

1. Use a shared measurement of success

In order to be sustainable and beneficial, everything a business does should be guided by the creation of value in the most effective way. This simple idea should be present in everything an organization strives for: which user pains do we address, when do we launch, how do we organize customer support? An economic view that runs through a system empowers actors to make their case across functions and roles at all levels of an organization and to take initiative in consider the economic impact of their decisions. 

2. Encourage people to look beyond their immediate surroundings

"You need to look beyond the immediate when considering consequences." Such a simple idea that is the root of all thinking in organizations: it's not about your interaction, it's about the team. It's not about your department, it's about the company. it's not about the company, it's about the ecosystem. Systems thinking does not tell you which level you should consider at any decision, just that you're probably looking at it too closely.

3. Allow your people to react to changing conditions

The SAFe principle of "assuming variability" means that you don't want to stop everything and start over when your inputs vary or if the  requirements change over time. In knowledge work, you often don't want to create the exact same thing as before, so you shouldn't aspire to the same predictability of process as a chemical plant. To fully take advantage over this, people should be encouraged not to nail things down before they have to under perceived pressure to "get things done".

4. Insist on completing small things to foster learning

The most commonly  recognized aspect of Agile is completing large undertakings through small tasks. There are  a number of advantages to this approach but to foster learning and a sense of agency, completing small things allows your people to get early feedback on their whole process from end to finish - not just the early planning phases. When iterations go through all phases of delivery, you are not only able to iterate to improve the product, but also allow people to iterate on their process and practices.

5. Set milestones on value delivered

Don't set milestones based on your preconception about how the phases a solution will be developed in. Instead, insist that every iteration be made as a viable solution and measure progress in terms of value delivered - whatever definition of value fits your solution. The team will find the best way to make headway and stakeholders can be involved over the course of development.

6. Visualize everything

Visualizing helps your team focus, handle stress and understand how they work. Increasing flow by setting WIP limits, reducing batch sizes and managing queue lengths is important and useful, but up-to-date visualizations help your team understand what they are doing. Most importantly, the key driver of stress is often not working too hard, it's working with too little visibility.

7. Structure work to build routine and collaboration

SAFe is literally "Agile, but scaled". This is most apparent in teams working in parallel to one another but also in how work is anticipated over "scaled-up" (i.e. long) stretches of time. Having all teams working on cadence creates routines that buffer uncertainty: "'When do we overview work across team?' 'Next IP sprint, in 4 weeks.'" Having all teams and even teams of teams work on the same cadence creates opportunities for cross-team collaboration and problem-solving.

8. Unlock the intrinsic motivation of knowledge workers

This I didn't have rephrase at all, which makes me even more confident that SAFe has empowerment and respect for people built deep into its core. Instead of monetary incentives to exert control over your team, understand that the teams are already motivated. You only need to overcome the obstacles to their sense of autonomy, mastery and purpose. In best case, you can communicate a clear intention that your teams can pursue under minimal constraints. Good things come to those who allow.

9. Make less decisions

Once you have established and communicated a shared method of evaluating decisions (principle 1) in a system with maximum visibility (principle 2) and awareness (principle 6) where your people can adjust for changing conditions (principle 3), you are the last person who should be making any decisions for these people. And you won't.