Events, loops and the innovation process

Systems Thinking helps us to visualise and understand complex systems with many interrelationships, like an economy. Me, and you, are another example of an immensely complex system that can, at a high level, be modelled with inputs, stocks and outputs.

Systems are everywhere, and systems and collections of them are really always loops in real life. Most systems are not simple cause and effect chains. They go on in circles, one part affecting another. In the same way, there is no beginning or end to an innovation process (system).

Consider for example a new service, product or feature that a business releases today: it will affect the products coming out from its competitors and potentially from other markets, and from providers. It will also change how consumers behave, which in turn will change how organisations in that market behave. All these changes will in turn affect the next move of the organisation.

What does it all tell us in practical terms? In my opinion, the most important point is to avoid thinking of innovation as a project: something that starts today and finishes at some point in the future with a new feature or product in the market. Innovating should be a continuous process that responds to changes in the system it belongs to.

Innovating with the Iceberg Model

Product development projects are often started by events, like a competitor launching a product that threatens your own, by requests from commercial teams, trends in your analytics metrics, or even some customers asking for a new feature (sounds familiar?). We are reacting to what others do, trying to protect ourselves from these changes in a part of the system, but it is easy to forget seeing the system as a whole.

Working in that reactive way, we can only see events happening here and there: we keep steering the boat in one direction or another reacting to the waves, but we are not seeing the currents on the route ahead.

If our knowledge of the market gets deeper, we may get into action when we spot patterns of changing consumer behaviour. An opportunity or a thread in the future will be the spark that puts efforts in place to innovate. It is an improvement: we now have a route to follow.

The levels we want to reach though, are those of the systems structure and the mental models (see the Iceberg graph above). Thinking in terms of systems can help us to understand how our market operates and can see how tiny changes in one place will have a snowball effect into the future and in far away places. We’ll see opportunities and threats that others simply cannot see or understand if they are looking at causes and events in isolation.

When our knowledge gets even deeper, we not only have a hand on the material side of things out there but also how we humans behave in that context and what to expect from us and from others. This insight is what we seek in innovation processes when we interview an audience in-depth, analyse data and compose behavioural models. We test assumptions and create hypothesis based on what we see and what our intuition (based on deep understanding) tells us: it is the nirvana of the innovation strategy.

Complexity is a key characteristic of systems (and of innovation)

That’s why we have Systems Thinking in the first place. In complex systems, every part affects the whole, and the whole is more than the sum of its parts. Systems are also interconnected with each other, making systems of systems, and on an on ad infinitum.

In my latest experience in product development, helping organisations to do market and user research, I often come across teams conducting AB tests on an existing product and failing to get anywhere with them. In a good part, this is because of the complexity of the system at play: those AB tests don’t tell us why the differences in behaviour happen, so we do not improve our knowledge of either the part or the whole of the system.

Another drawback with this type of feedback is that we are again concentrating in the events and their causes: a change in our product causing a change in consumer behaviour. In order to understand systems, as we saw, we need to see the loops, the interrelationships, the complexity. We need to be comfortable not knowing all of it too. Sometimes, we know what we don’t know, but we never know what we don’t know that we don’t know (the Unknown Unknowns).

Growth limits

You pull a lever somewhere to increase growth (say, sales), but the effects are weak, if any. You increase it even more. And more… with the same weak results. What is happening? Why are we not seeing the results of our actions?

Donella Meadows gives the soil for agriculture as an example of growth limit (the soil can be modelled as a system too). You can add nitrogen to help your potatoes grow, but it won’t have much effect if the limit to their growth is potassium. And indeed, you can add as many chemicals as you want, but if in the process you harm the microorganisms living in the soil, you are going nowhere.

There are many interrelated limits to the growth of a system, and it is impossible in most systems to model all of them, let alone control them. The best we can do is to have in place good feedback systems so we can correct as we go.

In The Lean Startup, Eric Ries touches on a related point. He describes how startups often focus on some metrics and push their teams towards goals on those, but often those metrics are what he calls “vanity metrics”: the number of sign ups, or the number of visitors to your website, or marketing leads... But the actual business figures stay the same (net profit, for instance).

The most confusing thing in this scenario is that those same metrics probably where at some point in the past good KPIs, but not any more. They have reached their growth limit, and the system does not respond to increases in that area any more. Solution? Know your system.

Bounded rationality — the problem of the common green

I think the classic example used for explaining bounded rationality is still the best one. Imagine a small rural village with a common green that is used in a rota by farmers. When it is your turn to use the green, it makes sense for you to take there as many sheep as you can, trying to maximise your time using it. But of course every farmer will sooner or later do the same thing, eventually putting in danger the viability of the grass on the green.

Back to our digital world, take this scenario: a newsletter is put in place and visitors to the website are forced to decide to join with a popup. “It works very well” says the web leads team, “we have increased subscriptions by 230%!”. But they are not the only farmers in this common. How is that growth impacting other metrics of the website? (say, visitor retention).

Each team makes decisions that are good for their area, with the knowledge they have, and they are getting good feedback for them. But no one is worrying about the effect on the whole of the system. This is bounded rationality: rational decisions for a small context, irrational for the larger one.

To fight the problem of bounded rationality we usually need someone who takes a view of the whole, and works on knowing the why behind the data.

In product development, we can avoid bounded rationality by working with multidisciplinary teams and doing research and testing that tells us the “why” behind the causal data. Thinking again about the example of the newsletter popup: if you interview a handful of users, you will learn that some are subscribing out of frustration, others are counting on just marking the emails as spam as soon as they arrive. Yet some others may like the idea of subscribing to the newsletter, and be grateful of having that popup notifying them. You now have some knowledge of the loop that is going on, and you can see how that small change might be affecting other metrics.

Rock’n’Roll non stop

Another key attribute of systems is that they can run forever (sometimes). These loops can be self-reinforced or self-balancing, depending on whether they tend to grow exponentially or whether they tend to be in equilibrium.

The important point is that they give feedback to themselves. In our previous example of the logging business, the system will tend to get to an equilibrium between the trees in the land and the sales of wood products. As the input gets more scarce, the output will be more costly and hence have less demand, which will slow down the input.

This never ending process is important when we think of innovation, which is another endless self-reinforcing loop, growing mostly exponentially (that’s certainly the case in technology).

If the system does not stop, it means we cannot stop acting on it either, if we want to control it to some degree. What we need is information. If something changes the input, we need to know it so we can adapt our stock and output. If the audience changes in attitudes, that will affect our output and in turn we need to optimise the system. When the system changes enough, say a disruptive competitor, we will need innovation in order to make a big enough difference in the system.

Information flows and delays

Delays are not good. Delays mean that we change something in our product, only to see no feedback of it for some time. We react to it, change the system again, and again we are left in the dark for some time until we get the feedback. Your instinct will probably tell you to increase the reaction times, but we cannot rely on our instincts here. Indeed we need to do the opposite: slow down, not act faster. We need longer term data, with averages and smaller confidence intervals.

We have all seen this happening when product teams react to requests from users, releases from competitors or sudden changes in commercial figures, translating them as fast as they can into new features.

Without enough quality data, we will find ourselves steering our boat in all directions, as you react to changes (the boat analogy is very handy!).

The Innovation System

You can see below a simple visualisation of the process of product development as a system (my interpretation anyway, there are many possibilities): our input is the business and market needs (sometimes we have raw ideas that are already available, based on those needs). The outputs are the tested prototypes. Whether they go well or bad, they give us valuable data. That’s our currency in Innovation: knowledge of the market.

Our stock is the knowledge of how our ideas (or prototypes) play out in the market: the data coming back from testing those ideas with end users. The more stock we have, the easier it is to come up with more output. The output is affected by the stock, but mainly by the reaction from people using our prototypes, which in turn increases and changes our stock.

You can see that we have a self-reinforcing loop, in which the more output we get from the system, the greater the stock, the better the output, which increases our stock… Innovation improves innovation.

If you think of the innovation process in this way, you can see how it is a never-ending loop that affects itself.

Thinking in Systems

If you are interested in learning more about systems thinking, you cannot go wrong with Donella Meadow’s classic “Thinking in Systems” (affiliate link).

Donella’s postomous non profit, The Donella Meadow’s Project, also offers on its website some free resources on Systems Thinking: http://donellameadows.org/systems-thinking-resources/

Systems thinking in product development was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

Want to make the most of your emails? Make sure they’re accessible to all your users.

Disabilities lie not in individuals, but in their environments. Kate Holmes, director of inclusive design at Microsoft, explains how the design of the elements within a playground dictate who can play and who cannot. Something as simple as the height of a swing can create a disability in some kids — those who are not tall enough.

Take a more considerate and flexible design decision and the barrier disappears.

To interpret the term in its broadest sense, we all experience varying degrees of “disability” at some point in our lives: when we use a phone in overly bright light, when we try to open a door while pushing a pram, when we break an arm or suffer from RSI or leave our reading glasses at home… In designing your environments and tools to be accessible, you’re helping everyone.

As email marketers or designers, we have the same level of responsibility when we create our emails. It is in our power to decide who gets to read them and who is left behind. It is not only a matter of social responsibility: the potential financial gains of using inclusive design are not to be ignored.

A huge market

The “disability market” (in lack of a better term) is estimated to be worth 1 trillion US dollars per year, and the current global population classified as disabled is estimated at 1.3 billion — that’s approximately the same as the population of China.

With those figures in mind, it’s hard to understand why some businesses still see accessibility as a nice-to-have instead of an absolute requirement. The EU’s Accessibility Act tells us that the financial benefits of an accessible service are usually greater than the cost involved in practicing inclusive design.

In order to get the best ROI, studies have shown that implementing accessibility from the start is better than patching a system as an afterthought. When it comes to email creation, we should take accessibility into account early on, during the planning phase.

If your message can be read by a wider audience, that means there are more people that could click through via your CTA and buy that product, learn about your services, or engage with you as a brand.

Practical guidelines

I’ve broken down accessibility best practice according to the content affected, so you can more easily use this list for reference as you compile your next email:

General and layout

• Can your email be made linear? Users of screen readers get a linear version of your content regardless (a bit like the options you might hear when using automated telephone systems). To check how your email performs when read in this way, disable the CSS styles.
• Put content in one column only. Multiple columns are tricky for people using screen magnifiers, and add cognitive load for everyone.
• Make your email responsive. The more ways people can access your email, the better! Also, many people choose to use their phones for certain tasks (such as reading email) because it’s easier to have the device read it aloud; on IOS, for instance, all you need to do is swipe three fingers down the screen.
• Include a web version. Many users have their browsers set up in a specific way which suits them. This may include custom CSS styles, bigger text, extensions to invert colors or to navigate using the keyboard alone. As a result, they might prefer to open emails in their browsers.
• Include a text-only version. Another way of providing flexibility. Starting your campaign creation with the text-only version will force you to think twice about the organization and structure of your content, and the value that images and other visual elements add to it (or not).
• Add the attribute “role=presentation” to the HTML code of tables used for layout which, as we know, are ubiquitous in email design.

Text content

• Keep language simple and to the point. If you’re targeting a broad consumer audience, you should aim for text that would be intelligible to the average 12 year old; that equivalent to a SMOG index of 8 or even lower. Before you recoil in horror, bear in mind that we all perform better with simpler texts. If your target audience is comprised of professionals, you can aim at a SMOG of 12 — the score of this article. Plenty of tools are available to help you check the readability of your messaging.
• Use a large font and left-align text. It will be easier to read for everyone, but is vital for people with cognitive issues. The British Dyslexia Association has produced a simple guide to designing content for people with dyslexia, ADHD, and similar difficulties.
• Break text down into short paragraphs and use headlines and lists where appropriate. Headlines are especially important, as screen readers gather them in order to provide users with a navigable table of contents.
• Links should be descriptive, so don’t use the lazy “read more” and “click here”. Users of screen readers rely on links and their descriptions a lot more than other users.
• Increase the tappable area of links and buttons. For touch interfaces, the minimum height and width should be 10mm — roughly the size of the average pinky finger.

Images

• When adding alt attributes, it sometimes helps to think of them as side notes or highlights. E.g. “chart showing variation in sales” is unhelpful to those who can’t see the chart, whereas “data from sales over the last 3 months show an average increase of 10% during the period” would be far more appropriate.
• Provide alternative content if necessary. You could provide a table with the same data shown in a chart, for example.
• Try to keep the images light. Users may be on a slower connection or restricted by data contracts. Most of us expect an email or web page to load in under 2 seconds.

Forms

• Put all fields in one column where possible. Users of screen magnifiers have trouble understanding and navigating multi-column layouts.
• Always use labels for form fields and always include important information in the label (e.g. whether the field is required or not).
• Forms should be as short and simple as possible. Nobody likes form-filling, but for users of assistive technology, the task is much more tedious.

Colors

• Do not rely on color for meaning. Links should be differentiated by something other than color alone. Charts need to be readable in black and white; to test this, take a screenshot of your chart and turn it to greyscale — can you still understand it?
• Name your colors, particularly when they represent an important part of the information provided. You might like to include the color of a product in its title, e.g. “Men’s classic bicycle frame in dark red.”
• Try not to combine red and green. These two are the most troublesome for people with color blindess, a group which represents 4.5% of the UK’s population. Use tools like Color Oracle to check the interpretability of your design.
• Ensure good contrast between foreground (usually text) and background. Remember: colors can be hard to differentiate in bright light, and they can vary a lot from screen to screen.

You may feel overwhelmed by the extend of the things that have to be considered, but most of the points are very easy to implement and add no time at all to your design process if considered from the start.

As we have seen, accessibility is far from being a minority concern, and prioritising it in your email creation results in a host of benefits. By practicing inclusive design you are improving the lives of all users, and giving them access to what your brand has to offer.

On the 12th of February 2002, Donald Rumsfeld, back then Secretary of State of the US, used an until then little known framework to help him in making the case for the invasion of Iraq: the Knowns and Unknowns framework. I think it is fair to say that the reception by the press was mixed: some accused him of playing with words with little meaning, while others saw some method in what he was trying to do.

Rumsfeld’s words have been turned into a poem, written by an unknown poet (very appropriately!) and included in a collection of poems all based on speeches by Donald Rumsfeld, Pieces of Intelligence, by Hart Seely (here in an edited version by Daase and Kessler):

As we know,
There are known knowns.
There are things we know we know.
We also know
There are known unknowns.
That is to say
We know there are some things
We do not know.
But there are also unknown unknowns,
The ones we don’t know
We do not know.
Finally, there are unknown knowns
The knowns
We do not want to know.

What is it?

The Knowns and Unknowns categorisation has been used since the Greek era and in many areas of knowledge. It is a powerful tool to surface what we know and don’t know about a problem.

The apparent simplicity of the Knowns and Unknowns framework is deceiving: it can byte you and get people thinking that you are just playing with words, as happened to Rumsfeld. So you’ve been warned, be careful with it. And please don’t let it into the hands of war seekers.

The framework can help us to understand our approach to knowledge, to research: What do we know already (known knowns)? Are we conscious of what we are not exploring (unknown unknowns)? What about biases and unconscious decisions (unknown knowns)? Are we aware of our assumptions (known unknowns)?

The known and the unknown have to be treated in very different ways. We need to adapt our methods to the type of knowledge (including our lack of knowledge, which is also knowledge, if we are aware of it).

If you are working with your unknowns (the Unknown Knowns or the Unknown Unknowns) you need to use exploratory techniques: How might we surface some of those unknowns? How might we prepare for the surprises ahead?

If instead you are investigating what you already know about a problem (the Known Knowns or the Known Unknowns) you have to work in an inductive way: how might we use those facts to learn new things? How might we test our hypotheses?

We will explore some ways of making sure that we take all our knowledge and lack of it into account as part of our research or Design Thinking methods. Before that, I have a few interesting stories about this framework.

Where did it come from?

You could argue that Socrates was using it indirectly when he said (according to Plato) “I only know that I don’t know anything”. But the first use of the method comes much later, in the thirteenth century, by the islamic philosopher Ibn Yami. This is how he categorised human beings according to their knowledge:

One who knows and knows that he knows… his horse of wisdom will reach the skies.
One who knows, but doesn’t know that he knows… he is fast asleep, so you should wake him up!
One who doesn’t know, but knows that he doesn’t know… his limping mule will eventually get him home.
One who doesn’t know and doesn’t know that he doesn’t know… he will be eternally lost in his hopeless oblivion!

He tells us that the act of acquiring knowledge is as important as what we already know.

In the 1950s two psychologists, Joseph Luft and Harrington Ingham, developed the Johari Window, a method to help people evaluate what they think about themselves in contrast with what others think of them. A Blind Spot, for instance, is something that we don’t know or think about ourselves but others do see in us. As a side note, the method uses adjective cards similar to those used in usability evaluation tools like Microsoft’s Reaction Cards.

The link between NASA, Rumsfeld and the Unknown

A few decades later, NASA reported that they were using the framework as part of risk analysis in space missions, specially to uncover Unknown Unknowns. In a presentation from 2003, we can see how they used the framework to evaluate the risks in the return journey of the Space Shuttle. They concentrate on moving the unknowns to the known realm.

Donald Rumsfeld re-appears in this short history of the Knowns and Unknowns: it is believed that it was a senior engineer from NASA that told Rumsfeld about the framework before he made use of it in the famous press conference in 2002. Rumsfeld certainly made the framework more popular than NASA, for good or bad.

The chaos and the bees

Slavoj Zizek is a Slovenian philosopher well known for his controversial statements, like this one: “We are all basically evil, egotistical, disgusting”. He also has something to say about our framework. In his article “Rumsfeld and the bees”, Zizek tells us that the most important category of knowledge for humanity is the Unknown Knowns: those things that we know but remain hidden as unconscious biases and prejudices that we are not aware of when making decisions. He gives the example of Climate Change: we all know it is happening, but we fail to act on it on our daily decisions.

In decision making it has been used to identify different environments and how organisations should proceed in each of them. The Chaotic environment, for instance, corresponds to our Unknown Unknowns. The way to deal with chaos is by being prepared to respond to eventualities: agility and adaptability are key. Organisations that insist on doing forecasting and detailed planning in a chaotic environment will fail.

The South China Sea disputes

Risk analysis is another area that uses this framework in an interesting way. For instance, in the South China Sea disputes, the countries involved often create Unknown Knowns on purpose, so the other contenders are left in a state of limbo, not knowing for sure the sea borders recognised by others or how willing they would be to defend them, which creates unknown geopolitical risks.

Looking for anything

Alistair Croll & Benjamin Yoskovitz used the Knowns and Unknowns framework in their book Lean Analytics to describe different ways of looking at data. This is how they recommend to use the four knowledge categories:

• Known Knowns (facts): you use analytics data to check those facts against them.
• Known Unknowns (hypotheses): can be confirmed or rejected with measurements.
• Unknown Knowns (our intuitions and prejudices): can be put aside if we trust the data instead.
• Unknown Unknowns (it can be anything!): are often left behind, but can be the source of great insight. By exploring the data in an open-minded way, we can recognise patterns and hidden behaviour that might point to opportunities.

Using the framework in Design Thinking

Scientific research often ignores what it cannot observe, that is our Unknown Unknowns. Researchers don’t usually gather data in order to just explore it. Most often, a theory of some sort is already on the table before observations or measurements begin. Theories are often built based on previous knowledge, inferred, not observed. This leads to incremental improvements, but it cannot take you to a big leap in discovery. The unknown can take you there.

At its core, the way of using the Knowns and Unknowns in Design Thinking is simply as a reminder to take all forms of knowledge into account. By doing this, we make the problem space larger and so the solution space also becomes larger. There are many possible ways of doing this. The techniques themselves are not new. The power comes from using a combination that allows you to surface all knowledge and lack of it.

Unknown Unknowns

To surface the Unknown Unknowns you need to explore a problem with an open mind. In user research and design research, the interviews that are often conducted at the formative stages of a project can surface these unknowns. As an example, in a recent project we discovered that some users were creating innovative workflows with external tools in order to solve their very unique problems. That is the kind of insight that takes you on big leaps to understanding the problems and to creating products that solve them.

Unknown knowns

If you want to surface Unknown Knowns, you need to get people to speak their thoughts aloud without too much thinking. Brainstorming fulfils this need. The presence of a group is important, because something that a person says serves as the catapult for others to surface related facts. Also, there are points that some will ignore because they don’t fit their agenda or some other reason, but chances are that others in the group will raise. Group sketching and other ways of rapid collective collaboration can also work towards uncovering Unknown Knowns.

Known Unknowns

With the Known Unknowns you want to create hypotheses. In a Design Thinking or UCD context this usually translates into creating quick sketches or diagrams with potential solutions that you then need to pass through the sieve of the team, and test with users. But these are basically just ideas based on existing knowledge. We have to make sure that we state them as hypothesis and not facts.

Known knowns

Facts are Known Knowns. With them you generate more knowledge. Lateral thinking techniques, like analogies, allow you to see those knowns in a different light, to create a parallel reality from the one you know. The goal is to break with convention, to create something valuable and original from something (facts) that is probably not that valuable, because it is already being exploited.

Use it!

I have been using this framework for a some months now, both for personal problems and work projects. I believe that, like other Design Thinking techniques, it opens up possibilities and forces you to think more holistically. It makes a good starting point when exploring any problem and a proven way of analysing our knowledge.

The knowns and unknowns framework for design thinking was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

There are an increasing number of options out there, with a large variation in features and even larger differences in prices. Some of the best known providers of remote usability testing require a hefty annual price that is often beyond what small businesses can afford, let alone freelancers offering their UX services. That has been my case more often than not, so I’m concentrating here on more affordable services that I have used recently, specially those that do not require an annual contract.

Usability testing tools

Validately is another tool that sits somewhere in the middle between the enterprise-oriented big names and the simpler, most affordable services. It has an easy to use interface, basic segmentation, a useful report-building tool and a reasonable annual price. The main problem of Validately is that they do not offer per-project packages. If you can sign up for an annual contract, it is a very good option. They offer trials in exchange for a call with a sales person, which is a good thing to do anyway, they will tell you how their service can fit with your needs, and they are not the typical pushy sales rep.

TryMyUI sits at a step down the path to simplicity and affordability. It has a decent panel of testers with segmentation, highlight reels and up to 20 minutes of video recording per session. The UI is a bit simplistic, but well worth the very affordable prices for both per-project packages and monthly contracts. The tests are usually completed in a matter of hours.

UsabilityHub is a different beast: it allows you to do quick testing like First Click tests, Five Second tests, Navigation (tree) tests and a few others. I have used it a few times to get both qualitative and quantitative data in one study. For instance, ask participants to click on a screen in order to start a task, and in the question after that, you can ask them why they clicked on the specific button, or what they think the second step would be, or whatever you need to ask. You get a report of results with the quant and qual data. With a bit of ingenuity you can run many different studies for a very affordable fee (per project or monthly). I wouldn’t live without it these days.

Loop11 is only a tool for recording, no panel of testers. It is affordable, easy to use and, most importantly, it stores your recordings online so you don’t have to manage all that data on your local machine. It integrates with Ethn.io’s intercepter, which is another tool to keep in mind.

LookBack is another testing-only tool, i.e. they have no panel of testers. Only URLs can be tested, as it is the case with Loop11 as far as I remember. You do have tools to be able to run moderated as well as unmoderated sessions. All for a very reasonable monthly fee.

UserTest.io: This is the only one that I haven’t used myself, but I thought it was worth mentioning it: a very basic service, with a small panel of testers, but good segmentation tools. You pay a small fee per test: it is probably the most affordable of the tools for standard usability testing.

Other tools

I’m going to include here a few other services that are not strictly for usability testing, but I have used them often for other research with users, and again, they are affordable!

Google Surveys is a great way to run a survey for B2C. They have a huge panel of participants that are intercepted on partner websites and offered to complete the survey in exchange for access to content (you have to take that into account). The samples can be representative of the UK or US population a posteriori. The price per participant is so affordable that you can have hundreds of completes without breaking your bank. Importantly, the survey instrument can include pictures. One thing to take into account: it is some 10 times more expensive once you add a second screen or more. For that reason, if you need screening, the price is not that cheap, because it uses the first screen for it. A similar platform is Survey Monkey, which now also has a panel of participants. Survey Monkey gives you a lot more control over the design of the survey, but it is slightly more expensive.

TestingTime is a recruitment service, and a very good one in my opinion. It is a German company with an office in London. I have been using their panel for a year or so, and even when my participants are B2B and quite specialised ones, they managed to get a decent panel for me. I have used them for discovery-stage interviews more than usability testing. You pay per project or packages, with a minimum of three participants. You have tools for basic demographic segmentation and you can set special requirements for an extra fee.

Other recruitment services that I reviewed some time ago but I haven’t used in real life projects are UserInterviews and Respondent.io. The latter is a bit different, it works like a market where you post your study and participants give you a price for their participation.

The more expensive and well-known names are so for a reason of course. They offer a lot of extras that these simpler and more affordable services do not. Their panels are also larger with excellent options for segmentation and screening, and they include account management support. So if you can afford them, I’m sure they are good value. If you can’t, these other services have been a good solution for me so far.

Affordable user research was originally published in AJ on Innovation on Medium, where people are continuing the conversation by highlighting and responding to this story.

Checklists are very simple tools, but they have proven to be very effective in helping people to evaluate the state of a system or as a memory aid when completing a task. I reviewed all of the relevant research papers I could find in order to give an objective overview of the possibilities –and drawbacks– of using checklists on software interfaces.

The old checklist
Checklists have long been in use in aviation and health care, perhaps the two fields that we all associate with the traditional, paper based checklist, although they are also used in maritime transport, weapon systems, space exploration, quality control in manufacturing, and many other fields.

In aviation, they have two main uses: first, as a way to follow critical procedures, so crew members don’t have to rely on memory alone, specially in processed like preparation for take off that require each step to be done in a specific sequence. The second use case is in helping crew members to deal with emergencies, when we all lose a good part of our cognitive abilities due to the raise in adrenaline and cortisol. (Degani & Wiener, NASA, 1993). In both uses, checklists also allow for mutual supervision between two crew members (pilot and copilot), something that is considered crucial to avoid mistakes in life-threatining scenarios (Degani & Wiener, NASA, 1991 and 1993).

In healthcare, checklists are also used both for normal and emergency procedures. A normal checklist could be used to pre-check the configuration of a device; a non-normal one, in situations like resuscitation (Clay-Williams & Colligan, 2015). Interestingly, in some uses, like surgical checks, the checklist is combined with team discussion: the list is used for linear processed, and briefings and team discussions are preferred for more complex tasks that need adaptation (Clay-Williams & Colligan, 2015). Clay-Williams & Colligan (2015) argue that checklists are probably misused in healthcare and need to go back to basics, reserving their use for those linear and simple processed that require standardisation and are too long to commit to memory.

Digital checklists
Years ago, an accounting web platform run some qualitative research to learn how users managed their daily working tasks. They discovered that, contrary to their believe, the participants did not follow a linear processes: they got distracted, they forgot things, they made mistakes. A task like collecting paperwork for tax filing was started and then left alone for hours or days, and many other tasks where started during that time.

If you are anything like me, you probably imagine an accountant as a very efficient person, with very good eye to detail and keen to follow processes. While that may be a fair representation, accountants are still like you and me: they procrastinate from time to time, they get distracted, they forget things, they make mistakes.

Without the field research, the company would probably never have thought of implementing checklists on their platform. The humble checklist solved the problem, or at least part of it, by helping their users to keep track of tasks and to evaluate the state of an ongoing task. One of the benefits of the checklist is that it can be tested even without a device: just a printed sheet of paper and a pen will do fine.

At my current position at Adestra, we help online marketers to create email marketing campaigns. We discovered with our own user research that marketers were using checklists (either todo lists or old fashion ones, i.e., pen and paper) to keep track of tasks that they need to complete in order to launch a campaign. This is how this research got started. We already use checklists in our platform, but we are now looking for ways to make this simple tool accomplish even more.

The two sides of a checklist
There are two main uses of checklists: as memory aid and as an evaluation tool. When used as mnemonic tools, checklists have proven to reduce omission errors. For evaluation purposes, they make tasks reproducible and reliable. An example of the latter, is the use of checklists to ensure that all members of a team (or multiple teams) complete a process in the same way.

With either use, checklists can help to improve quality standards, to implement best practises and to condense large and complex information (Hales, Brigette et al, 2008. Ziewacz et al, 2012). Checklists are specially helpful in stressful situations, when our cognitives abilities decline drastically (Hales, Brigette et al, 2008). The adrenaline and cortisol released by our body reduce the rational thinking in our cortex, potentially to levels that can make us freeze completely, unable to make decisions.

Checklists do have a few potential drawbacks as well. The most important is arguably that they force users to take time away from the task itself, which in some contexts may be important. The excessive use of checklists is also a known problem that can produce checklist fatigue, which in turn causes users to perceive them as a nuance (Hales, Brigette et al, 2008. Anderson, Judith et al, 2010). After prolonged use of one checklist, users may also start to memorise it, either consciously or unconsciously, and this in fact can be a problem, because our memory is weaker than we think. With digital lists, we can partly avoid this by forcing users to go through a given order of sub-tasks, and to ask confirmation or double checking of important steps.

Degani and Wiener, from NASA (1991), point out another problem: distractions. This is one of the problems we are trying to fix with checklists in the first place! It is not a problem with the checklist in itself, but the list can make it worse because the user feels confident in the process. In aviation, most recorded cases of distraction are due to users trying to complete an unrelated task at the same time that they were following the checklist, then going back to it and marking an item as done without doing it (Degani & Wiener, 1991).

Distractions are the main reason why, for critical tasks, it is recommended that two users do the checks: one reads out an item, the other checks that it has been completed. That is how it is now done in aviation. This interaction gives the process a redundancy check. In digital products, the system is normally the one that gives us the feedback to know whether an item has been completed or not, acting as that second person in the team. I find this to be a good analogy to keep in mind when considering the use of checklists: would the process benefit of having a second person doing the checks? If so, make the system be that person. Using a conversational graphical interface would make an stronger analogy.

Primary/secondary task inversion
This is another potential problem with using checklists that deserves special mention. In most cases, you want the checklist to either act as a backup to ensure that a task is completed, or to be a means to evaluate the work done. But the list can end up being the primary task, and the goal becomes completing the checklist, and the original task is a means to complete the checklist. Users end up relying on the list, not even trying to use their rational thinking. This is task inversion at work (Palmer and Degani, 1991).

In health care and aviation, task inversion has to be avoided at all cost. You want the nurse to be able to follow a task using his or her own knowledge and experience, probably changing it slightly to fit the patient or situation. The checklist should be a backup system in this case. In other cases, task inversion is not a problem at all. At Adestra, we would not be worried to see users relying on the checklist to complete and launch an email campaign. This is in part because the checklist is not part of the steps to launch the campaign, but a pre-requisite. If the checklist was part of the launch process, task inversion would probably show up. Usability testing should uncover task inversion, but you will need to test with current users of the system that are familiar with the checklist and the tasks.

Design guidelines
Verdaasdonk et al (2008) recommends to follow a more-or-less standard iterative approach when designing checklists:
1. Define its purpose, audience and expected outcome.
2. Research the tasks with direct observation and interviews.
3. Make a list of tasks that compose the checklist.
4. Review it.
5. Test it with users.
6. Repeat 3, 4 and 5 as necessary.

The initial research and testing should help to identify the tasks that are critical and the ones that can be left behind (Verdaasdonk et al, 2008). Verdaasdonk et al also recommend to keep human limitations always in mind: it is easy to get carried away with long and complex checklists for the sake of completeness and exactitude that makes sense on paper, but not in a real life environment. Again… we research and test with users to avoid that.

Good checklist design can also help with disorientation. Long or complex lists can easily cause it, and this in turn can make the user skip a point or check as done the incorrect one. To avoid it, make checklists linear, so you cannot check a point if there are unchecked ones before it. Making the list shorter or grouping points in some way (effectively creating multiple shorter checklists) is another way of helping with this distraction. The Civil Aviation Authority in the UK (2000) also recommends to provide an index (ordered list for you and me) or other navigational means.

Bichelmeyer (2003) also addresses list length and grouping in her paper “A checklist for formatting checklists” (how about that use of a checklist!). She too recommends grouping similar items together and numbering them, even if the task does not need to be completed in a specific order. She points out that users are more likely to complete the checklist if it is numbered. If you decide to group the items, it is a good idea to review them for inclusiveness (you don’t leave anything behind), clarity and parsimony (include what is required and nothing else) (Stuflebeam, 2000).

A variation in the typical use of checklists is to help users follow best practise or standards they need to meet. On our email platform, we remind users to add a text version of the email and to test it thoroughly with the help of checklists. The launch process includes a variation of a numbered checklist design (a step-by-step wizard) that encourages users to follow the recommended checks.

More generally, we want to be specific with the terminology that we use in our list (Bichelmeyer, 2003). Better “fix” than “needs attention”; “weekly” instead of “periodically”. In real life, you will have to spot more subtle vagueness, for example: “Go to the previous location and switch back on the notifications setting”. The user needs to rely on memory (or find and re-read a previous item) to work out what that previous location is and which exact setting to turn on. A better way would be: “Go to Settings > Notifications and turn back on the Permission Alert notification”.

Finally, Palmer & Degani (1991) and Verdaasdonk et al (2008) make the case for doing field testing, specially to identify the task inversion problem. We have to assume that human behaviour is going to change with the introduction of checklists, or any other aid for that matter. Monitoring user behaviour before an after the introduction of the checklist in beta access or prototype is the best way to go (Palmer & Degani, 1991).

Conclusion
We often dismiss or not even consider simple solutions like checklists. We probably tend to think of checklists as old fashion, a pen and paper tool for a time long gone when they didn’t know better. In the digital world we have indeed many options to solve our problems, and checklists may not come to mind.

Checklists can be disguised in many dresses though, and there are plenty of examples of this: the step-by-step wizard and the checkout process are two of them. If your users need to complete a task that needs multiple subtasks, you can probably improve it with a humble checklist. The two key questions are: does the user need help to remember how to complete the task? does the user need to evaluate how well a task is or was done? If any of those is true, a checklist will probably help.

References
Anderson, Judith, et al, 2010. Using human factors engineering to improve the effectiveness of infection prevention and control. Critical care medicine 38 (2010): S269-S281.
Barbara A. Bichelmeyer, 2003. Checklist For Formatting Checklists. Western Michigan University.
Clay-Williams and Colligan, 2015. Back to basics: checklists in aviation and healthcare. BMJ Qual Saf, 24(7), pp.428–431.
Daniel L. Stufflebeam, 2000. Guidelines For Developing Evaluation Checklists: The Checklists Development Checklist (CDC).
Degani, A., Wiener, E. L., NASA, 1991. Human factors of flight-deck checklists: The normal checklist.
Degani, A., Wiener, E. L., NASA, 1993. Cockpit checklists: Concepts, design and use.
FAA, US dept of Transportation. Jan 1995. Human Performance Considerations In The Use And Design Of Aircraft Checklists.
Hales, Brigette, et al, 2008. Development of medical checklists for improved quality of patient care. International Journal for Quality in Health Care 20.1 (2008): 22–30.
John E. Ziewacz, Sigurd H. Berven, Valli P. Mummaneni, Tsung-Hsi Tu, Olaolu C. Akinbo, Russ Lyon, and Praveen V. Mummaneni, 2012. The design, development, and implementation of a checklist for intraoperative neuromonitoring changes. M.D. Neurosurg Focus.
Palmer, E. and Degani, A., 1991, April. Electronic checklists: Evaluation of two levels of automation. In Proceedings of the Sixth Symposium on Aviation Psychology (pp. 178–183). Columbus: The Ohio State University.
UK Civil Aviation Authority, 2000. Guidance on the Design and Presentation of Electronic Checklists.
Verdaasdonk, E.G.G., Stassen, L.P.S., Widhiasmara, P.P. et al, 2008. Requirements for the design and implementation of checklists for surgical processes. Surg Endosc (2009) 23: 715.

Designing with checklists was originally published in AJ on Innovation on Medium, where people are continuing the conversation by highlighting and responding to this story.

Jeremy Bentham, the philosopher regarded as the founder of Utilitarianism stated that “it is the greatest happiness of the greatest number that is the measure of right and wrong”.

During WWII, the British government initiated a scheme that had a similar premise as its principle: to help to furnish thousands of homes of newly married couples and families whose houses had been bombed at a very fair price. It is known as the Utility Furniture scheme, and you can still find this furniture on sale in auctions and eBay.

The logo of the scheme, known as CC41 (standing for Controlled Commodity 41–1941 being the year that the scheme was created, lasting for 11 years) was known at the time as the Two Cheeses logo. Nowadays it would surely be known as the Two Pacman logo!

The designers in charge of implementing the scheme followed the principles set by the Arts and Crafts movement more than half a century earlier, with their main premise of respecting materials and craftsmanship and avoiding superfluous decoration. They also incorporated the newer vision from the Bauhaus and similar movements that dictated that form should follow function. The designers that participated in the scheme took the opportunity to design with the philosophy that they valued, a way of designing that had been until then very difficult to put into practice, because neither the manufacturers nor the customers had been interested.

In my opinion, those designers (Edwin Clinch and Herbert Cutler are among the best known) did a pretty good job given the restrictions in budget, materials and time. Of course the designs were never going to be inventive or novel –the scheme was not there to support risk-taking, quite the opposite, and the best way to avoid risks is to follow established designs and existing manufacturing methods.

But you cannot design in a vacuum: the people who were going to use that furniture, even during the hard years of the 1940s, had a set of expectations that had to be met and those designs were not what customers were looking for. The fashion back then was for heavily decorated objects, novelty for its own sake or imitation of classic and upper-market styles: not what most designers, either then or now, see as good design.

Taste is, of course, very subjective and prone to change depending on factors like what your neighbour is buying. Can we, designers, impose new fashions? Should we? It didn’t work out very well for the Utility Furniture. The scheme was successful for as long as the limits on the wood market were in place, but as soon as the government removed those restrictions, the scheme died and the design movement was forgotten. Nobody wanted to buy those pieces of furniture if they could buy something else: they were seen as crude, basic, lacking expression and personality. People started carving patterns into the plain chairs and tables bought through the scheme while it was still running. There was an obvious disassociation between the design professionals and the public.

In the book Twentieth Century Design (in the series Oxford History of Art), it is pointed out that the main reason for that disassociation was probably that the end of the Second World War reinstated optimism in the British public, and this translated into an appetite for novelty, richer decoration and simply for change. Anything that reminded them of the war was rejected.

Utility design and interfaces

The minimalist philosophy that has monopolised interface design during the last decade or so can be seen as a kind of utilitarian design, in the sense that it makes design serve specific practical issues: avoiding the usability problems and useless decoration and animation that invaded the web during the first decade of its existence.

The dot-com bubble and subsequent crash in the early 2000s was due to many factors, but one of the lessons that we interface designers took from it was that users didn’t want 3D interfaces, or splash screens, or fancy animated menus, or background music. The big survivors of that crash (Yahoo, eBay, Amazon) were all using very minimal and down-to-earth interfaces. They demonstrated that what designers were creating was very different from what consumers wanted.

Those two events in design history were quite similar in the way designers were acting: CC41 was looking for simple designs when the public wanted novelty and decoration; the early interfaces on the web were decorative, innovative and individualistic, and the solution that we found in order to engage users was to go back to the old form-follows-function, the vision that the Utility Scheme designers were also trying to make popular but failed. A important distinction though, is that in most cases innovation and decoration in furniture design does not get in the way of usability, as was the case with the early web pages.

A lesson to be taken from the Utility experiment is that we don’t design in a vacuum, and our users are never as simple as our generalised personas. They have dreams for the future, they have emotional attachments and they want to fit into a group as much as to express their individuality. Raymond Loewy also stated that we humans are torn between curiosity and fear of the new (from his Most Advanced Yet Acceptable –MAYA– theory).

Utilitarian design was originally published in AJ on Innovation on Medium, where people are continuing the conversation by highlighting and responding to this story.

I have recently started doing remote usability testing, and although there is plenty of good advice already out there, I thought it was worth sharing my own experience, both the good bits and the not-so-good ones. I am using the services of WhatUsersDo.com and I am so far happy with them, but this article is not about any specific provider, and I would certainly encourage you to do your research as I did, before signing up. The offers vary wildly in price and features, and not least important, in the support you get if you need it.

Hassle-free usability testing

With fully automated services like those offered by WhatUsersDo.com (and many others), you avoid all of the issues involved in contacting participants, setting up appointments, having the office space booked and ready, welcoming participants, setting up the equipment, etc. You don’t even have to find your participants or be there at specific times.

For this reason alone, you get more tests done, even without trying to do so. Whenever I think I need to run tests I just do it, no planning required. I usually have the video recordings ready for me to review within 24 hours of launching them. I then tag them, write down more formal notes with the most important findings, analyse them with the help of colleagues to prioritise issues and find solutions. I am ready for the next iteration in less than 48 hours.

You can’t get it wrong

Since you cannot interact with the participants, you cannot ask questions you should not ask, or help the tester indirectly, or communicate frustration with your body language. You cannot affect how participants behave in any way, except perhaps with your instructions, but this is not easy even if you try.

This of course also means that if the participants are confused, or they don’t understand a point in your instructions, or you are curious about why they did something, you are left frustrated, but this seldom happens in my experience. During the first few tests I did find that my instructions were too detailed. The main advice I can give in that respect is to keep it simple. Let the participants do their job. Two lines to introduce the scenario/persona and another line or two to describe each task is enough. Separate the tasks clearly, and avoid having to give explanations or asking too many questions. If the instructions are long, many participants will scan them instead of reading them properly.

I can give you one more piece of advice: make sure you tell the participants to stop working on a given task and continue with the next one if they find it hard to complete it, otherwise they will probably spend all of the available time on that one task.

Have someone else correct your instructions, and test them twice.

Since your instructions are the only way to interact with the participant before and during the test, you have to put a bit more effort into planning a good test and describing it well. I also always “test the test” with somebody at the office or a friend, to make sure everything is clear in my instructions and the time necessary to complete the task is within the limits I have (30 minutes max with WhatUsersDo, but I try to keep it at half of that, remember that you will have to review each video in its entirety).

I once made a naive mistake: I asked participants to find a template in a list of templates and delete it. All of the testers were told to manipulate the same templates, so of course, after I tested the instructions with a colleague, the first actual tester tried to find the template and couldn’t, since my colleague had already removed it. If the whole test were about this one task, I would probably have spotted it, but it was one of many, so I didn’t stop to think about it. Had I tested it twice, I would have caught it.

Get more from your testers

In my experience at least, the participants feel more free to give their opinions about the design in remote testing. You don’t need to tell them to give their opinions, they will probably give you more than you want to hear anyway.

In my experience with face-to-face tests, I always have to remind testers about thinking aloud during the test every 2 minutes, which gets annoying very quickly for both of us. With remote testing, participants tend to speak their thoughts aloud often enough. I guess that they are less embarrassed about speaking their thoughts if they are alone with a microphone than sat 2 feet away from a stranger who is staring at them and taking notes as if her life depended on it.

I find it helpful to ask an entry question, as soon as the person sees the screen they are going to work on. The first task I give them is to say what they think of that screen: is it clear? How does it compare to similar apps they have used in the past?

I compare the opinion they give at the start with the one they give me on the exit question, which I make sure to always include. This one is usually about describing the experience as a whole, something along the lines of: “What did you think of the interface you were given in order to complete the tasks? Did you find it easy or difficult to use in general terms?” Of course, you don’t want to ask them for a solution, they are not designers, but to ask about the issues that they think were most important or the general feeling they got from it.

Invisible users

You don’t see the faces and general body language of your participants when working remotely, and although I have not missed this at all so far, I can see how it could be an important issue in some situations, for instance if you are testing a very innovative interface, specially on mobile where seeing how a user handles the device can be very informative.

The good side of this is that the participants are doing your test from their own homes, or at least with their own devices, wherever they decide to sit down. This means that they feel as comfortable with the environment, technology and setup as they can feel. They are also probably less prone to try to do things in a different way from how they would usually do them.

Reviewing the videos

In some cases it is utterly boring to watch the full videos, specially when the participants are too verbose and slow. This is never the case with a new test of course, but when you are running the 3rd iteration of a design, and you are maybe watching your 20th recording, it can certainly become tedious, and this is very seldom the case with a face-to-face test.

A note here about those not-so-good participants, because they do exist: we do get the odd one (1 in every 10 perhaps) who is so slow in completing a task that it takes 3 times longer than it should, making it also a real pain to watch. You may also get a participant who doesn’t read the instructions at all and completes the task (or not) in whatever way she fancies. More rarely, you can get participants that do not speak their thoughts aloud and this makes the test far less valuable.

Remote usability testing was originally published in AJ on Innovation on Medium, where people are continuing the conversation by highlighting and responding to this story.

Google Glass failed for many reasons, but I think their lack of a simple and obvious selling point was clearly an important one. For geeks, a selling point was really not necessary; a lot of us were just curious enough to give them a try. However, the rest of the public could only see a threat to their own privacy, and no obvious reason to wear a pair themselves. We are for the most part still in love with our shiny mobile devices, so why would anyone leave their precious phone in the pocket and use a pair of odd-looking glasses instead?

Snap’s Spectacles are a completely different beast: they are simple, cheap, approachable, they look fun and cool for their very specific audience and, importantly, they fulfil one simple need: to record yourself and your friends while on the move, doing sport, having fun outdoors.

These are sun glasses, and that is not a trivial point, because it implies that they are not meant to be worn all the time, or indeed indoors, but instead to be put on whenever the weather is good and you are out and about with friends or when you are practicing your preferred sport. No misunderstandings are possible. No one is going to feel awkward wearing a pair of simple sun glasses and no one is going to stare at you: they are indistinguishable from any other pair of sun glasses.

Being simple and approachable, and given the audience they are aimed at, I am sure that many original ways of using the Spectacles will appear. They will probably substitute those odd-looking cameras that cyclist wear. They will record moves on the dance floor. We will see art pieces created with them. They will be personalised and hacked. Sure, they are not going to be the next big thing, but they are not trying to either. They are not meant to be anything but a little camera on a pair of brightly coloured glasses. The recorded video, in circular format and with a 115 degree of vision, emphasises the fun side of it, their simple selling point.

On a less optimist side, I think their biggest risk is to be associated with the failed Glass. Also, we cannot forget the privacy concerns that have been aired in the past about SnapChat, or their controversial filters, which may put some potential users off.

Spectacles are not Glass was originally published in AJ on Innovation on Medium, where people are continuing the conversation by highlighting and responding to this story.

John Maeda describes in his book Laws of Simplicity how trust can help in simplifying a design or a process. One of the examples he gives is the Omakase Japanese menu, which translates as I’ll leave it up to you, or more freely as Chef’s Special. When asking for this special menu, the customer puts her trust entirely in the hands of the master chef, who has to read the body and mind of the customer in order to come up with a set of dishes that are the perfect fit for that individual. No doubt there is mastery in it, but the menu works precisely because of the trust the customer puts in the chef: the master cannot fail, if the customer completely surrenders to his mastery.

It was for me one of the most innovative ideas in his book, because it had never occurred to me that trust could bring with it simplification in design. But an even more interesting question is whether trust could make a process or design more complex.

Are you being served?

In most cafes and bars in Spain, you pay for your order after you have emptied your container of its tasty liquid. There are exceptions, and in big cities it happens less often nowadays, but it is still the norm. Bar attenders cannot possibly remember all of the orders, and they usually don’t even try to do so. They just trust their customers.

Trust, in this case, makes things harder and slower for all parties: customers have to wait twice: first to order and be served and afterwards to be charged and pay; waiters have to prepare your drinks, then go back to you when you are ready to pay; finally, the owners of the businesses are losing some money every day due to people forgetting to pay before leaving or the odd person getting away with a free drink.

The origin of trust

My grandma, now 84, was born in a small rural village in the north of Spain in 1932. The daily life in rural Spain sounds now like medieval history to me: everything happened within the boundaries of the small village, and all the neighbours knew each other as if they were a big family.

In the village’s tavern (it served both as a convenience shop and as a bar) most transactions were not paid at the moment of ordering: the owner kept a record of expenses per household and charged them days or weeks later. Money was not something that most people carried with them on a daily basis in rural Spain, so customers paid whenever they got hold of some cash, usually once a month after selling their goods in the market. Trust was, hence, not an optional, but a necessity if you wanted to do business.

I believe this is probably the origins of the current custom of charging customers just before they leave the premises, although I have to admit that I haven’t been able to find any research on this yet.

The problem of un-trusting

When money became used more often, this custom of letting the customer pay whenever it was convenient for them, could have evolved to charging them just before they left the place. The next step, to serve and charge in one go, never happened.

The problem is that once you bring trust into a process, it is very difficult to get rid of it, because it implies “untrusting” that same person that you were trusting until yesterday. So it is easy to see how that owner of a cafe or bar would be wary of starting telling the customer to pay at once after the drink is put in front of her. It would be as she was telling that person “I don’t trust you”, in an indirect, but still pretty confrontational way.

So trust, in this case, has made a pretty simple process a lot more complex for all the parties involved.

Trust and design was originally published in AJ on Innovation on Medium, where people are continuing the conversation by highlighting and responding to this story.

It is often argued that in a not-so-distant future we could end up with the only job of serving machines, as we see pretty much all sectors being computerised. In a not-so-distant future, when robots are able to do almost any job, including maintaining themselves, we are going to have a hard time finding a job for us humans. What could we have left for our organic brains and brute force to do?

Creative thinking

Creative thinking could be applied in two different ways, similar to the two main approaches to scientific research, induction and deduction: calculating first and then imagining new realities, versus imagining new realities first and then calculating their possible implementations. The calculating part would be handed over to the machines of course.

For the first implementation, based on the inductive approach, professional thinkers would pass on their ideas to machines in order to be analysed mathematically. We are already doing this when scientists develop a hypothesis and then prepare a computing system to test it (the CERN being an extreme example), but for now we are required to build the machines and computer programs ourselves. We are good at imagining, not so good at implementing and calculating, so I’m sure that in a not-so-distant future AI could build algorithms and hardware and run the tests themselves, taking also away our subjectivity.

For the professionals on the deductive approach, the job title could be machine forecasters. We already have machines deciding sales and purchases in stock markets, changing accordingly the prices that you and me eventually pay for those commodities. Machine forecasters could work in a similar fashion to a meteorologists. To forecast the weather, models are run by computers and the results are then analysed by humans. We could end up having to do the same in order to forecast all our economy, transport or even social issues like movement of people.

The ultimate responsibility of these professionals would be to shape the way that machines work in order to keep the outcomes within the results that we expect. A big part of this would be morals and human values.

The artist

Chengde Chen, a Chinese philosopher living in Oxford that I had the pleasure of meeting, has a very pessimistic view of our technology-driven world. In one of the essays in his book “‘Five Themes of Today: Philosophical Poems” he explores the idea that technology, or accumulation of knowledge more generally, grows exponentially and hence cannot be maintained indefinitely. More importantly, he makes the point that as we increase our knowledge we also become more dangerous to ourselves (genetic modification, nuclear arms, climate change, … robots?). He arrives at the conclusion that we have one only alternative: to give up on accumulation of material knowledge and dedicate our lives to Art, because it is the only thing that does not need to grow exponentially.

Perhaps we could have our cake and eat it too. If robots will eventually be able to do everything required to maintain us — and them — , mankind could be free to dedicate their lives to leisure, Art and creative thinking. Andrew McAfee talks about this idea of a market-free, workless society, and he compares it with the Athens of the past, where wealthy citizens lived pretty much without needing to work, dedicated to philosophy, art, and other creative endeavours. The difference is that, back then, the leisure society was supported by an army of slaves, and this time around that army would be made up of machines.

Robot vs human

There is one crucial problem with any of these possible outcomes though: how are we going to stop robots from reaching the point where they entertain the thought of getting rid of the empty weight of humans?

One solution to that problem is to make machines share our morals and our same necessities, but then will they be machines or humans? Would we be happy having an army of slave robots that can think, have morals and values and have the same daily needs that we have?

There is another problem, closer in time, that we will need to faced: how can mankind make the transition from our current civilisation to that machine-based one, without producing big pockets of poverty and global social unrest? Can a capitalist system deal with such an environment? It does not seem like it can at the moment.

Elsewhere

A brief article about the paper that I have referenced at the beginning of this piece: “47% of US jobs under threat from computerisation, according to Oxford study”: http://www.gizmag.com/half-of-us-jobs-computerized/29142/.
The research paper itself: http://www.oxfordmartin.ox.ac.uk/downloads/academic/The_Future_of_Employment.pdf

“The second machine age” a book around the same ideas I wrote about here, by Andrew McAfee: http://andrewmcafee.org/the-second-machine-age-the-book-and-the-blurbs/. Link to an interview of him on CBC Radio’s Spark program. I encourage you to listen to it, it lasts only around 8 minutes and Andrew McAfee expresses his ideas very well indeed.

Quantum robots will learn in real time, making possible a big leap in artificial intellegence: http://motherboard.vice.com/read/quantum-robots-will-do-your-job-better-than-you-can

One in Three Jobs Will be Taken by Software or Robots by 2025

Jobs in a robot world was originally published in AJ on Innovation on Medium, where people are continuing the conversation by highlighting and responding to this story.