Tag: design

Adapting intelligent tools for creativity

I read Alper’s book on conversational user interfaces over the weekend and was struck by this paragraph:

“The holy grail of a conversational system would be one that’s aware of itself — one that knows its own model and internal structure and allows you to change all of that by talking to it. Imagine being able to tell Siri to tone it down a bit with the jokes and that it would then actually do that.”

His point stuck with me because I think this is of particular importance to creative tools. These need to be flexible so that a variety of people can use them in different circumstances. This adaptability is what lends a tool depth.

The depth I am thinking of in creative tools is similar to the one in games, which appears to be derived from a kind of semi-orderedness. In short, you’re looking for a sweet spot between too simple and too complex.

And of course, you need good defaults.

Back to adaptation. This can happen in at least two ways on the interface level: modal or modeless. A simple example of the former would be to go into a preferences window to change the behaviour of your drawing package. Similarly, modeless adaptation happens when you rearrange some panels to better suit the task at hand.

Returning to Siri, the equivalence of modeless adaptation would be to tell her to tone it down when her sense of humor irks you.

For the modal solution, imagine a humor slider in a settings screen somewhere. This would be a terrible solution because it offers a poor mapping of a control to a personality trait. Can you pinpoint on a scale of 1 to 10 your preferred amount of humor in your hypothetical personal assistant? And anyway, doesn’t it depend on a lot of situational things such as your mood, the particular task you’re trying to complete and so on? In short, this requires something more situated and adaptive.

So just being able to tell Siri to tone it down would be the equivalent of rearranging your Photoshop palets. And in a next interaction Siri might carefully try some humor again to gauge your response. And if you encourage her, she might be more humorous again.

Enough about funny Siri for now because it’s a bit of a silly example.

Funny Siri, although she’s a bit of a Silly example, does illustrate another problem I am trying to wrap my head around. How does an intelligent tool for creativity communicate its internal state? Because it is probabilistic, it can’t be easily mapped to a graphic information display. And so our old way of manipulating state, and more specifically adapting a tool to our needs becomes very different too.

It seems to be best for an intelligent system to be open to suggestions from users about how to behave. Adapting an intelligent creative tool is less like rearranging your workspace and more like coordinating with a coworker.

My ideal is for this to be done in the same mode (and so using the same controls) as when doing the work itself. I expect this to allow for more fluid interactions, going back and forth between doing the work at hand, and meta-communication about how the system supports the work. I think if we look at how people collaborate this happens a lot, communication and meta-communication going on continuously in the same channels.

We don’t need a self-aware artificial intelligence to do this. We need to apply what computer scientists call supervised learning. The basic idea is to provide a system with example inputs and desired outputs, and let it infer the necessary rules from them. If the results are unsatisfactory, you simply continue training it until it performs well enough.

A super fun example of this approach is the Wekinator, a piece of machine learning software for creating musical instruments. Below is a video in which Wekinator’s creator Rebecca Fiebrink performs several demos.

https://www.youtube.com/watch?v=yc5CL5EoPqg[/embed]

Here we have an intelligent system learning from examples. A person manipulating data in stead of code to get to a particular desired behaviour. But what Wekinator lacks and what I expect will be required for this type of thing to really catch on is for the training to happen in the same mode or medium as the performance. The technology seems to be getting there, but there are many interaction design problems remaining to be solved.

Generating UI design variations

AI design tool for UI design alternatives

I am still thinking about AI and design. How is the design process of AI products different? How is the user experience of AI products different? Can design tools be improved with AI?

When it comes to improving design tools with AI my starting point is game design and development. What follows is a quick sketch of one idea, just to get it out of my system.

‘Mixed-initiative’ tools for procedural generation (such as Tanagra) allow designers to create high-level structures which a machine uses to produce full-fledged game content (such as levels). It happens in a real-time. There is a continuous back-and-forth between designer and machine.

Software user interfaces, on mobile in particular, are increasingly frequently assembled from ready-made components according to more or less well-described rules taken from design languages such as Material Design. These design languages are currently primarily described for human consumption. But it should be a small step to make a design language machine-readable.

So I see an opportunity here where a designer might assemble a UI like they do now, and a machine can do several things. For example it can test for adherence to design language rules, suggest corrections or even auto-correct as the designer works.

More interestingly, a machine might take one UI mockup, and provide the designer with several more possible variations. To do this it could use different layouts, or alternative components that serve a same or similar purpose to the ones used.

In high pressure work environments where time is scarce, corners are often cut in the divergence phase of design. Machines could augment designers so that generating many design alternatives becomes less laborious both mentally and physically. Ideally, machines would surprise and even inspire us. And the final say would still be ours.

Engagement design worksheets

Engagement design workshop at General Assembly Singapore

In June/July of this year I helped Michael Fillié teach two classes about engagement design at General Assembly Singapore. The first was theoretical and the second practical. For the practical class we created a couple of worksheets which participants used in groups to gradually build a design concept for a new product or product improvement aimed at long-term engagement. Below are the worksheets along with some notes on how to use them. I’m hoping they may be useful in your own practice.

A practical note: Each of these worksheets is designed to be printed on A1 paper. (Click on the images to get the PDFs.) We worked on them using post-it notes so that it is easy to add, change or remove things as you go.

Problem statement and persona

01-problem-statement-and-persona

We started with understanding the problem and the user. This worksheet is an adaptation of the persona sheet by Strategyzer. To use it you begin at the top, fleshing out the problem in the form of stating the engagement challenge, and the business goals. Then, you select a user segment which is relevant to the problem.

The middle section of the sheet is used to describe them in the form of a persona. Start with putting a face on them. Give the persona a name and add some demographic details relevant for the user’s behaviour. Then, move on to exploring what their environment looks and sounds like and what they are thinking and feeling. Finally, try to describe what issues the user is having that are addressed by the product and what the user stands to gain from using the product.

The third section of this sheet is used to wrap up the first exercise by doing a quick gap analysis of what the business would like to see in terms of user behaviour and what the user is currently doing. This will help pin down the engagement design concept fleshed out in the next exercises.

Engagement loop

02-engagement-loop

Exercise two builds on the understanding of the problem and the user and offers a structured way of thinking through a possible solution. For this we use the engagement loop model developed by Sebastian Deterding. There are different places we can start here but one that often works well is to start imagining the Big Hairy Audacious Goal the user is looking to achieve. This is the challenge. It is a thing (usually a skill) the user can improve at. Note this challenge down in the middle. Then, working around the challenge, describe a measurable goal the user can achieve on their way to mastering the challenge. Describe the action the user can take with the product towards that goal, and the feedback the product will give them to let them know their action has succeeded and how much closer it has gotten them to the goal. Finally and crucially, try to describe what kind of motivation the user is driven by and make sure the goals, actions and feedback make sense in that light. If not, adjust things until it all clicks.

Storyboard

03-storyboard

The final exercise is devoted to visualising and telling a story about the engagement loop we developed in the abstract in the previous block. It is a typical storyboard, but we have constrained it to a set of story beats you must hit to build a satisfying narrative. We go from introducing the user and their challenge, to how the product communicates the goal and action to what a user does with it and how they get feedback on that to (fast-forward) how they feel when they ultimately master the challenge. It makes the design concept relatable to outsiders and can serve as a jumping off point for further design and development.

Use, adapt and share

Together, these three exercises and worksheets are a great way to think through an engagement design problem. We used them for teaching but I can also imagine teams using them to explore a solution to a problem they might be having with an existing product, or as a way to kickstart the development of a new product.

We’ve built on other people’s work for these so it only makes sense to share them again for others to use and build on. If you do use them I would love to hear about your experiences.

Doing UX inside of Scrum

Some notes on how I am currently “doing user experience” inside of Scrum. This approach has evolved from my projects at Hubbub as well as more recently my work with ARTO and on a project at Edenspiekermann. So I have found it works with both startups and agency style projects.

The starting point is to understand that Scrum is intended to be a container. It is a process framework. It should be able to hold any other activity you think you need as a team. So if we feel we need to add UX somehow, we should try to make it part of Scrum and not something that is tacked onto Scrum. Why not tack something on? Because it signals design is somehow distinct from development. And the whole point of doing agile is to have cross-functional teams. If you set up a separate process for design you are highly likely not to benefit from the full collective intelligence of the combined design and development team. So no, design needs to be inside of the Scrum container.

Staggered sprints are not the answer either because you are still splitting the team into design and development, hampering cross-collaboration and transparency. You’re basically inviting Taylorism back into your process—the very thing you were trying to getting away from.

When you are uncomfortable with putting designers and developers all in the same team and the same process the answer is not to make your process more elaborate, parcel things up, and decrease “messy” interactions. The answer is increasing conversation, not eliminating it.

It turns out things aren’t remotely as complicated as they appear to be. The key is understanding Scrum’s events. The big event holding all other events is the sprint. The sprint outputs a releasable increment of “done” product. The development team does everything required to achieve the sprint goal collaboratively determined during sprint planning. Naturally this includes any design needed for the product. I think of this as the ‘production’ type of design. It typically consists mostly of UI design. There may already be some preliminary UI design available at the start of the sprint but it does not have to be finished.

What about the kind of design that is required for figuring out what to build in the first place? It might not be obvious at first, but Scrum actually has an ongoing process which readily accommodates it: backlog refinement. These are all activities required to get a product backlog item in shape for sprint planning. This is emphatically not a solo show for the product manager to conduct. It is something the whole team collaborates on. Developers and designers. In my experience designers are great at facilitating backlog refinement sessions. At the whiteboard, figuring stuff out with the whole team ‘Lean UX’ style.

I will admit product backlog refinement is Scrum’s weak point. Where it offers a lot of structure for the sprints, it offers hardly any for the backlog refinement (or grooming as some call it). But that’s okay, we can evolve our own.

I like to use Kanban to manage the process of backlog refinement. Items come into the pipeline as something we want to elaborate because we have decided we want to build it (in some form or other, can be just an experiment) in the next sprint or two. It then goes through various stages of elaboration. At the very least capturing requirements in the form of user stories or job stories, doing sketches, a lo-fi prototype, mockups and a hi-fi prototype and finally breaking the item down into work to be done and attaching an estimate to it. At this point it is ready to be part of a sprint. Crucially, during this lifecycle of an item as it is being refined, we can and should do user research if we feel we need more data, or user testing if we feel it is too risky to commit to a feature outright.

For this kind of figuring stuff out, this ‘planning’ type of design, it makes no sense to have it be part of a sprint-like structure because the work required to get it to a ‘ready’ state is much more unpredictable. The point of having a looser grooming flow is that it exists to eliminate uncertainty for when we commit to an item in a sprint.

So between the sprint and backlog refinement, Scrum readily accommodates design. ‘Production’ type design happens inside of the sprint and designers are considered part of the development team. ‘Planning’ type of design happens as part of backlog refinement.

So no need to tack on a separate process. It keeps the process simple and understandable, thus increasing transparency for the whole team. It prevents design from becoming a black box to others. And when we make design part of the container process framework that is Scrum, we reap the rewards of the team’s collective intelligence and we increase our agility.

Prototyping is a team sport

Lately I have been binging on books, presentations and articles related to ‘Lean UX’. I don’t like the term, but then I don’t like the tech industry’s love for inventing a new label for every damn thing. I do like the things emphasises: shared understanding, deep collaboration, continuous user feedback. These are principles that have always implicitly guided the choices I made when leading teams at Hubbub and now also as a member of several teams in the role of product designer.

In all these lean UX readings a thing that keeps coming up again and again is prototyping. Prototypes are the go-to way of doing ‘experiments’, in lean-speak. Other things can be done as well—surveys, interviews, whatever—but more often than not, assumptions are tested with prototypes.

Which is great! And also unsurprising as prototyping has really been embraced by the tech world. And tools for rapid prototyping are getting a lot of attention and interest as a result. However, this comes with a couple of risks. For one, sometimes it is fine to stick to paper. But the lure of shiny prototyping tools is strong. You’d rather not show a crappy drawing to a user. What if they hate it? However, high fidelity prototyping is always more costly than paper. So although well-intentioned, prototyping tools can encourage wastefulness, the bane of lean.

There is a bigger danger which runs against the lean ethos, though. Some tools afford deep collaboration more than others. Let’s be real: none afford deeper collaboration than paper and whiteboards. There is one person behind the controls when prototyping with a tool. So in my view, one should only ever progress to that step once a team effort has been made to hash out the rough outlines of what is to be prototyped. Basically: always paper prototype the digital prototype. Together.

I have had a lot of fun lately playing with browser prototypes and with prototyping in Framer. But as I was getting back into all of this I did notice this risk: All of a sudden there is a person on the team who does the prototypes. Unless this solo prototyping is preceded by shared prototyping, this is a problem. Because the rest of the team is left out of the thinking-through-making which makes the prototyping process so valuable in addition to the testable artefacts it outputs.

It is I think a key oversight of the ‘should designers code’ debaters and to an extent one made by all prototyping tool manufacturers: Individuals don’t prototype, teams do. Prototyping is a team sport. And so the success of a tool depends not only on how well it supports individual prototyping activities but also how well it embeds itself in collaborative workflows.

In addition to the tools themselves getting better at supporting collaborative workflows, I would also love to see more tutorials, both official and from the community, about how to use a prototyping tool within the larger context of a team doing some form of agile. Most tutorials now focus on “how do I make this thing with this tool”. Useful, up to a point. But a large part of prototyping is to arrive at “the thing” together.

One of the lean UX things I devoured was this presentation by Bill Scott in which he talks about aligning a prototyping and a development tech stack, so that the gap between design and engineering is bridged not just with processes but also with tooling. His example applies to web development and app development using web technologies. I wonder what a similar approach looks like for native mobile app development. But this is the sort of thing I am talking about: Smart thinking about how to actually do this lean thing in the real world. I believe organising ourselves so that we can prototype as a team is absolutely key. I will pick my tools and processes accordingly in future.

All of the above is as usual mostly a reminder to self: As a designer your role is not to go off and work solo on brilliant prototypes. Your role is to facilitate such efforts by the whole team. Sure, there will be solo deep designerly crafting happening. But it will not add up to anything if it is not embedded in a collaborative design and development framework.

Prototyping in the browser

When you are designing a web site or web app I think you should prototype in the browser. Why? You might as well ask why prototype at all. Answer: To enable continuous testing and refinement of your design. Since you are designing for the web it makes sense to do this testing and refinement with an artefact composed of the web’s material.

There are many ways to do prototyping. A common way is to make wireframes and then make them ‘clickable’. But when I am designing a web site or a web app and I get to the point where it is time to do wireframes I often prefer to go straight to the browser.

Before this step I have sketched out all the screens on paper of course. I have done multiple sketches of each page. I’ve had them critiqued by team members and I have reworked them.

Drawing pictures of web pages

But then I open my drawing program—Sketch, in my case—and my heart sinks. Not because Sketch sucks. Sketch is great. But it somehow feels wrong to draw pictures of web pages on my screen. I find it cumbersome. My drawing program does not behave like a browser. That is to say in stead of defining a bunch of rules for elements and having the browser figure out how to render them on a page together I need to follow those rules myself in my head as I put each element in its place.

And don’t get me started on how wireframes are supposed to be without visual design. That is nonsense. If you are using contrast, repetition, alignment and proximity, you are doing layout. That is visual design. I can’t stand wireframes with a bad visual hierarchy.

If I persevere, and I have a set of wireframes in my drawing program, they are static. I can’t use them. I then need to export them to some other often clunky program to make the pictures clickable. Which always results in a poor resemblance of the actual experience. (I use Marvel. It’s okay but it is hardly a joy to use. For mobile apps I still use it, for web sites I prefer not to.)

Prototyping in the browser

When I prototype in the browser I don’t have to deal with these issues. I am doing layout in a way that is native to the medium. And once I have some pages set up they are immediately usable. So I can hand it to someone, a team member or a test participant, and let them play with it.

That is why, for web sites and web apps, I skip wireframes altogether and prototype in the browser. I do not know how common this is in the industry nowadays. So I thought I would share my approach here. It may be of use to some.

It used to be the case that it was quite a bit of hassle to get up and running with a browser prototype so naturally opening a drawing package seemed more attractive. Not so anymore. Tools have come a long way. Case in point: My setup nowadays involves zero screwing around on the command line.

CodeKit

The core of it is a paid-for Mac app called CodeKit, a so-called task manager. It allows you to install a front-end development framework I like called Zurb Foundation with a couple of clicks and has a built in web server so you can play with your prototype on any device on your local network. As you make changes to the code of your prototype it gets automatically updated on all your devices. No more manual refreshing. Saves a huge amount of time.

I know you can do most of what CodeKit does for you with stuff like Grunt but that involves tedious configuration and working the command line. This is fine when you’re a developer, but not fine when you are a designer. I want to be up and running as fast as possible. CodeKit allows me to do that and has some other features built in that are ideal for prototyping which I will talk about more below. Long story short: CodeKit has saved me a huge amount of time and is well worth the money.

Okay so on with the show. Yes, this whole prototyping in the browser thing involves ‘coding’. But honestly, if you can’t write some HTML and CSS you really shouldn’t be doing design for the web in the first place. I don’t care if you consider yourself a UX designer and somehow above all this lowly technical stuff. You are not. Nobody is saying you should become a frontend developer but you need to have an acquaintance with the materials your product is made of. Follow a few courses on Codecadamy or something. There really isn’t an excuse anymore these days for not knowing this stuff. If you want to level up, learn SASS.

Zurb Foundation

I like Zurb Foundation because it offers a coherent and comprehensive library of elements which covers almost all the common patterns found in web sites and apps. It offers a grid and some default typography styles as well. All of it doesn’t look flashy at all which is how I like it when I am prototyping. A prototype at this stage does not require personality yet. Just a clear visual hierarchy. Working with Foundation is almost like playing with LEGO. You just click together the stuff you need. It’s painless and looks and works great.

I hardly do any styling but the few changes I do want to make I can easily add to Foundation’s app.scss using SASS. I usually have a few styles in there for tweaking some margins on particular elements, for example a footer. But I try to focus on the structure and behaviour of my pages and for that I am mostly doing HTML.

GitHub

Testing locally I already mentioned. For that, CodeKit has you covered. Of course, you want to be able to share your prototype with others. For this I like to use GitHub and their Pages feature. Once again, using their desktop client, this involves zero command line work. You just add the folder with your CodeKit project as a new repository and sync it with GitHub. Then you need to add a branch named ‘gh-pages’ and do ‘update from master’. Presto, your prototype is now on the web for anyone with the URL to see and use. Perfect if you’re working in a distributed team.

Don’t be intimidated by using GitHub. Their on-boarding is pretty impressive nowadays. You’ll be up and running in no time. Using version control, even if it is just you working on the prototype, adds some much needed structure and control over changes. And when you are collaborating on your prototype with team members it is indispensable.

But in most cases I am the only one building the prototype so I just work on the master branch and once every while I update the gh-pages branch from master and sync it and I am done. If you use Slack you can add a GitHub bot to a channel and have your team members receive an automatic update every time you change the prototype.

The Kit Language

If your project is of any size beyond the very small you will likely have repeating elements in your design. Headers, footers, recurring widgets and so on. CodeKit has recently added support for something called the Kit Language. This adds support for imports and variables to regular HTML. It is absolutely great for prototyping. For each repeating element you create a ‘partial’ and import it wherever you need it. Variables are great for changing the contents of such repeating elements. CodeKit compiles it all into plain static HTML for you so your prototype runs anywhere.

The Kit Language really was the missing piece of the puzzle for me. With it in place I am very comfortable recommending this way of working to anyone.

So that’s my setup: CodeKit, Zurb Foundation and GitHub. Together they make for a very pleasant and productive way to do prototyping in the browser. I don’t imagine myself going back to drawing pictures of web pages anytime soon.

Design without touching the surface

I am preparing two classes at the moment. One is an introduction to user experience design, the other to user interface design. I did not come up with this division, it was part of the assignment. I thought it was odd at first. I wasn’t sure where one discipline ends and the other begins. I still am not sure. But I made a pragmatic decision to have the UX class focus on the high level process of designing (software) products, and the UI class focus on the visual aspects of a product’s interface. The UI class deals with a product’s surface, form, and to some extent also its behaviour, but on a micro level. Whereas the UX class focuses on behaviour on the macro level. Simply speaking—the UX class is about behaviour across screens, the UI class is about behaviour within screens.

The solution is workable. But I am still not entirely comfortable with it. I am not comfortable with the idea of being able to practice UX without ‘touching the surface’, so to speak. And it seems my two classes are advocating this. Also, I am pretty sure this is everyday reality for many UX practitioners. Notice I say “practitioner”, because I am not sure ‘designer’ is the right term in these cases. To be honest I do not think you can practice design without doing sketching and prototyping of some sort. (See Bill Buxton’s ‘Sketching User Experiences’ for an expanded argument on why this is.) And when it comes to designing software products this means touching the surface, the form.

Again, the reality is, ‘UX designer’ and ‘UI designer’ are common terms now. Certainly here in Singapore people know they need both to make good products. Some practitioners say they do both, others one or the other. The latter appears to be the most common and expected case. (By the way, in Singapore no-one I’ve met talks about interaction design.)

My concern is that by encouraging the practice of doing UX design without touching the surface of a product, we get shitty designs. In a process where UX and UI are seen as separate things the risk is one comes before the other. The UX designer draws the wireframes, the UI designer gets to turn them into pretty pictures, with no back-and-forth between the two. An iterative process can mitigate some of the damage such an artificial division of labour produces, but I think we still start out on the wrong foot. I think a better practice might entail including visual considerations from the very beginning of the design process (as we are sketching).

Two things I came across as I was preparing these classes are somehow in support of this idea. Both resulted from a call I did for resources on user interface design. I asked for books about visual aspects, but I got a lot more.

  1. In ‘Magic Ink’ Bret Victor writes about how the design of information software is hugely indebted to graphic design and more specifically information design in the tradition of Tufte. (He also mentions industrial design as an equally big progenitor of interaction design, but for software that is mainly about manipulation, not information.) The article is big, but the start of it is actually a pretty good if unorthodox general introduction to interaction design. For software that is about learning through looking at information Victor says interaction should be a last resort. So that leaves us with a task that is 80% if not more visual design. Touching the surface. Which makes me think you might as well get to it as quickly as possible and start sketching and prototyping aimed not just at structure and behaviour but also form. (Hat tip to Pieter Diepenmaat for this one.)

  2. In ‘Jumping to the End’ Matt Jones rambles entertainingly about design fiction. He argues for paying attention to details and that a lot of the design he practices is about ‘signature moments’ aka micro-interactions. So yeah, again, I can’t imagine designing these effectively without doing sketching and prototyping of the sort that includes the visual. And in fact Matt mentions this more or less at one point, when he talks about the fact that his team’s deliverables at Google are almost all visual. They are high fidelity mockups, animations, videos, and so on. These then become the starting points for further development. (Hat tip to Alexander Zeh for this one.)

In summary, I think distinguishing UX design from UI design is nonsense. Because you cannot practice design without sketching and prototyping. And you cannot sketch and prototype a software product without touching its surface. In stead of taking visual design for granted, or talking about it like it is some innate talent, some kind of magical skill some people are born with and others aren’t, user experience practitioners should consider being less enamoured with acquiring more skills from business, marketing and engineering and in stead practice at the skills that define the fields user experience design is indebted to the most: graphic design and industrial design. In other words, you can’t do user experience design without touching the surface.

My plans for 2016

Long story short: my plan is to make plans.

Hubbub has gone into hibernation. After more than six years of leading a boutique playful design agency I am returning to freelance life. At least for the short term.

I will use the flexibility afforded by this freeing up of time to take stock of where I have come from and where I am headed. ‘Orientation is the Schwerpunkt,’ as Boyd says. I have definitely cycled back through my meta-OODA-loop and am firmly back in the second O.

To make things more interesting I have exchanged the Netherlands for Singapore. I will be here until August. It is going to be fun to explore the things this city has to offer. I am curious what the technology and design scene is like when seen up close. So I hope to do some work locally.

I will take on short commitments. Let’s say no longer than two to three months. Anything goes really, but I am particularly interested in work related to creativity and learning. I am also keen on getting back into teaching.

So if you are in Singapore, work in technology or design and want to have a cup of coffee. Drop me a line.

Happy 2016!

Blog All Kindle-clipped Locations: Destruction and Creation

I finished my previous post on why designers should be interested in John Boyd with the recommendation to read his essay “Destruction and Creation”. I thought I’d share the bits I highlighted in my copy. It is part of Osinga’s Science, Strategy and War, to which the locations below refer.

Location 3176 – Boyd introduces a very simple but fundamental reason for why we should care about decision making:

… a basic aim or goal, as individuals, is to improve our capacity for independent action

Location 3183 – the same applies to design and designers. We do not want to be controlled by our circumstances. Boyd was talking to a military audience, but the description below is true of any social situation, including the design practice:

In a real world of limited resources and skills, individuals and groups form, dissolve and reform their cooperative or competitive postures in a continuous struggle to remove or overcome physical and social environmental obstacles.

Location 3190

Against such a background, actions and decisions become critically important.

Location 3192

To make these timely decisions implies that we must be able to form mental concepts of observed reality, as we perceive it, and be able to change these concepts as reality itself appears to change.

Location 3195 – designers are asked to do nothing but the above. The succes of our designs hinges on our understanding of reality and our skill at intervening in it. So the question below is of vital importance to us:

How do we generate or create the mental concepts to support this decision-making activity?

Location 3196 – in the next section of the essay Boyd starts to provide answers:

There are two ways in which we can develop and manipulate mental concepts to represent observed reality: We can start from a comprehensive whole and break it down to its particulars or we can start with the particulars and build towards a comprehensive whole.

Location 3207

… general-to-specific is related to deduction, analysis, and differentiation, while, specific-to-general is related to induction, synthesis, and integration.

Location 3216

… such an unstructuring or destruction of many domains – to break the correspondence of each with its respective constituents – is related to deduction, analysis, and differentiation. We call this kind of unstructuring a destructive deduction.

Location 3225

… creativity is related to induction, synthesis, and integration since we proceeded from unstructured bits and pieces to a new general pattern or concept. We call such action a creative or constructive induction.

Location 3227 – here Boyd starts to connect the two ways of creating concepts. I have always found it gratifying to immerse myself in a design’s domain and to start teasing apart its constituent elements, before moving on to acts of creation:

It is important to note that the crucial or key step that permits this creative induction is the separation of the particulars from their previous domains by the destructive deduction.

Location 3230

… the unstructuring and restructuring just shown reveals a way of changing our perception of reality.

Location 3237 – so far so fairly straight-forward. But Boyd gets increasingly more sophisticated about this cycle of destruction and creation. For example, he suggests we should check for internal consistency of a new concept by tracing back its elements to the original sources:

… we check for reversibility as well as check to see which ideas and interactions match-up with our observations of reality.

Location 3240 – so this is not a two-step linear act, but a cyclical one, where we keep tuning parts and wholes of a concept (or design) and test them against reality:

Over and over again this cycle of Destruction and Creation is repeated until we demonstrate internal consistency and match-up with reality.

Location 3249 – in the next section, Boyd problematises the process he has proposed by showing that once we have formed a concept, its matchup to reality immediately starts to deteriorate:

… at some point, ambiguities, uncertainties, anomalies, or apparent inconsistencies may emerge to stifle a more general and precise match-up of concept with observed reality.

Location 3257 – the point below is one I can’t help but iterate often enough to clients and coworkers. We must work under the assumption of mismatches occurring sooner or later. It is an essential state of mind:

… we should anticipate a mismatch between phenomena observation and concept description of that observation.

Location 3266 – he brings in Gödel, Heisenberg and the second law of thermodynamics to explain why this is so:

Gödel’s Proof indirectly shows that in order to determine the consistency of any new system we must construct or uncover another system beyond it.

Location 3274

Back and forth, over and over again, we use observations to sharpen a concept and a concept to sharpen observations. Under these circumstances, a concept must be incomplete since we depend upon an ever-changing array of observations to shape or formulate it. Likewise, our observations of reality must be incomplete since we depend upon a changing concept to shape or formulate the nature of new inquiries and observations.

Location 3301 – so Gödel shows we need to continuously create new concepts to maintain the usefulness of prior ones due to the relationship between observed reality and mental concepts. Good news for designers! Our work is never done. It is also an interesting way to think about culture evolving by the building of increasingly complex networks of prior concepts into new ones. Next, Boyd brings in Heisenberg to explain why there is uncertainty involved when making observations of reality:

… the magnitude of the uncertainty values represent the degree of intrusion by the observer upon the observed.

Location 3304

… uncertainty values not only represent the degree of intrusion by the observer upon the observed but also the degree of confusion and disorder perceived by that observer.

Location 3308 – Heisenberg shows that the more we become intwined with observed reality the more uncertainty increases. This is of note because as we design new things and we introduce them into the environment, unexpected things start to happen. But also, we as designers ourselves are part of the environment. The more we are part of the same context we are designing for, the less able we will be to see things as they truly are. Finally, for the third move by which Boyd problematises the creation of new concepts, we arrive at the second law of thermodynamics:

High entropy implies a low potential for doing work, a low capacity for taking action or a high degree of confusion and disorder. Low entropy implies just the opposite.

Location 3312 – closed systems are those that don’t communicate with their environment. A successful design practice should be an open system, lest it succumb to entropy:

From this law it follows that entropy must increase in any closed system

… whenever we attempt to do work or take action inside such a system – a concept and its match-up with reality – we should anticipate an increase in entropy hence an increase in confusion and disorder.

Location 3317 – it’s important to note that Boyd’s ideas are equally applicable to design plans, design practices, design outcomes, any system involved in design, really. Confused? Not to worry, Boyd boils it down in the next and final section:

According to Gödel we cannot – in general – determine the consistency, hence the character or nature, of an abstract system within itself. According to Heisenberg and the Second Law of Thermodynamics any attempt to do so in the real world will expose uncertainty and generate disorder.

Location 3320 – the bit below is a pretty good summary of why “big design up front” does not work:

any inward-oriented and continued effort to improve the match-up of concept with observed reality will only increase the degree of mismatch.

Location 3329 – whenever we encounter chaos the instinct is to stick to our guns, but it is probably wiser to take a step back and reconsider our assumptions:

we find that the uncertainty and disorder generated by an inward-oriented system talking to itself can be offset by going outside and creating a new system.

Location 3330 – creativity or explorative design under pressure can seem like a waste of time but once we have gone through the exercise in hind sight we always find it more useful than thought before:

Simply stated, uncertainty and related disorder can be diminished by the direct artifice of creating a higher and broader more general concept to represent reality.

Location 3340

I believe we have uncovered a Dialectic Engine that permits the construction of decision models needed by individuals and societies for determining and monitoring actions in an effort to improve their capacity for independent action.

Location 3341

the goal seeking effort itself appears to be the other side of a control mechanism that seems also to drive and regulate the alternating cycle of destruction and creation toward higher and broader levels of elaboration.

Location 3347 – chaos is a fact of life, and as such we should welcome it because it is as much a source of vitality as it is a threat:

Paradoxically, then, an entropy increase permits both the destruction or unstructuring of a closed system and the creation of a new system to nullify the march toward randomness and death.

Location 3350 – one of Boyd’s final lines is a fine description of what I think design should aspire to:

The result is a changing and expanding universe of mental concepts matched to a changing and expanding universe of observed reality.

John Boyd for designers

The first time I came across military strategist John Boyd’s ideas was probably through Venkatesh Rao’s writing. For example, I remember enjoying Be Somebody or Do Something.

Boyd was clearly a contrarian person. I tend to have a soft spot for such figures so I read a highly entertaining biography by Roger Coram. Getting more interested in his theories I then read an application of Boyd’s ideas to business by Chet Richards. Still not satisfied, I decided to finally buckle down and read the comprehensive survey of his martial and scientific influences plus transcripts of all his briefings by Frans Osinga.

It’s been a hugely enjoyable and rewarding intellectual trip. I feel like Boyd has given me some pretty sharp new tools-to-think-with. From his background you might think these tools are limited to warfare. But in fact they can be applied much more broadly, to any field in which we need to make decisions under uncertain circumstances.

As we go about our daily lives we are actually always dealing with this dynamic. But the stakes are usually low, so we mostly don’t really care about having a thorough understanding of how to do what we want to do. In warfare the stakes are obviously unusually high, so it makes sense for some of the most articulate thinking on the subject to emerge from it.

As a designer I have always been interested in how my profession makes decisions. Designers usually deal with high levels of uncertainty too. Although lives are rarely at stake, the continued viability of businesses and quality of peoples lives usually are, at least in some way. Furthermore, there is always a leap of faith involved with any design decision. When we suggest a path forward with our sketches and prototypes, and we choose to proceed to development, we can never be entirely sure if our intended outcomes will pan out as we had hoped.

This uncertainty has always been present in any design act, but an argument could be made that technology has increased the amount of uncertainty in our world.

The way I see it, the methods of user centred design, interaction design, user experience, etc are all attempts to “deal with” uncertainty in various ways. The same can be said for the techniques of agile software development.

These methods can be divided into roughly two categories, which more or less correspond to the upper two quadrants of this two-by-two by Venkatesh. Borrowing the diagram’s labels, one is called Spore. It is risk-averse and focuses on sustainability. The other is called Hydra and it is risk-savvy and about anti-fragility. Spore tries to limit the negative consequences of unexpected events, and Hydra tries to maximise their positive consequences.

An example of a Spore-like design move would be to insist on thorough user research at the start of a project. We expend significant resources to diminish the amount of unknowns about our target audience. An example of a Hydra-like design move is the kind of playtesting employed by many game designers. We leave open the possibility of surprising acts from our target audience and hope to subsequently use those as the basis for new design directions.

It is interesting to note that these upper two quadrants are strategies for dealing with uncertainty based on synthesis. The other two rely on analysis. We typically associate synthesis with creativity and by extension with design. But as Boyd frequently points out, invention requires both analysis and synthesis, which he liked to call destruction and creation. When I reflect on my own way of working, particularly in the early stages of a project, the so-called fuzzy front end, I too rely on a cycle of destruction and creation to make progress.

I do not see one of the two approaches, Spore or Hydra, as inherently superior. But my personal preference is most definitely the Hydra approach. I think this is because a risk-savvy stance is most helpful when trying to invent new things, and when trying to design for play and playfulness.

The main thing I learned from Boyd for my own design practice is to be aware of uncertainty in the first place, and to know how to deal with it in an agile way. You might not be willing to do all the reading I did, but I would recommend to at least peruse the one long-form essay Boyd wrote, titled Destruction and Creation (PDF), about how to be creative and decisive in the face of uncertainty.