Core to design thinking is prototyping & testing. If you browse around the web you find many aspects linked to design thinking, one more fancy than the other. But central to all; prototyping and testing.
The reason is clear; designers think differently then the rest of us (let’s say the engineer). What differentiates a designer from an engineer is that an engineer creates a solution to a carefully analysed and understood problem, whereas a designer creates many solutions as a means to understand the problem. For a designer, a prototype is a hypothesis. Well, that is how I see it.
The image shown aims to illustrate my view on Design Thinking.
It tries to bring across 3 main points:
- Core to design thinking is prototype and test, serving the design process, of which evaluation (learning) is a core element. It does not say anything about time to market (speed to get it out there) nor about the quality of the prototype. This is a skill in itself. Talk to a designer to get a feel for this.
- Contextual to design thinking are the many tools and methods that you can apply to get a better understanding of the problem space and help you to identify the solution space. These tools are not core, and often distract from what design thinking aims to achieve, which is to make ideas tangible to find out why they do not work (which is a different way of saying “do I understand the problem”). Some even go as far to say that design thinking by itself may not be enough anymore. For example, “In the era of Living Services, Fjord have created their own design system – Design Rule of 3 – which consists of design thinking, design doing and design culture.” Yes, I agree. The larger the (scope of the) project, the more difficult it is to understand the problem space, so you need to scale up on your exploration, and manage expectations concerning time to market.
- Basis of any design project, at least in my experience, is a business opportunity and/or a business model. Only in rare situations, a design project is performed completely outside any business context. For that reason, I place the business model canvas as a leave of the root of the flower.
OK, I admit. I just wanted to create a nice illustration and immediately came up with a flower, so I tried to fit Design Thinking to the idea that I had and make it work. I think it does, more or less. What do you think?
Illustrations of space through movement, ‘3D’ on a single screen by linking action and perception, to insiders in Delft also known as the Delft Virtual Window System, (DVWS). This page shows some examples freely exploring around the topic of ecological perception and action/perception coupling, which was the basis for my PhD thesis work. An ancient archive of system designs, prototypes and experiments. Most movies are the result of a collaboration with ‘partner in crime’ dr. ing. Tom Djajadiningrat, the best industrial designer known to men, well, known to this man at least. Great times, great memories. Small and short movies. Remember, this was last century.
In this day and age, most of the illustrations below are mainstream ideas, and new technology would make implementation much easier. I mean, using two pendulums to measure the orientation of a monitor (which was an transparent LCD screen used to place on an overhead projector to share your computer screen – whoa…) ad link it back to the images shown on the screen. ‘Rocket science’ back in 1994….
|Depth through movement. This movie shows the basic principle. At the time created in PovRay, rendered on a Quadra (over-night), and then imported in macromedia Director to create a QT movie.|
|Just fun. Using a Mondriaan picture ti highlight the difference between static information and the ability to move. Without movement the image is perfectly flat. Add some movement and you see that it is actual a spatial structure.|
|Wobby – Exploring a spatial object by changing the orientation of the monitor. The orientation of the monitor is measured with two pendulums.|
|Exploring the spatial structure of a Rietveld Red-Blue-chair, showing what you see as observer and how you interact with the screen (inset).|
|Wobby – Exploring the depth map of the northern part of the Netherlands. One of the possible applications we were exploring. Again,shown is what you see as observer and how you interact with the screen (inset).|
|Interactive MRI. Moving the monitor allows navigation through the MRI slices, allowing you to get a better understanding of its spatial structure.|
|Wiggly – in most situations you sit on a chair behind a computer. The sensors or your chair can estimate the orientation of your upper-body, and therefore the position of your head position. Linking this estimation to the camera movements makes it possible to explore a virtual space in an elegantly simple manner; just sit down and explore.|
A prototype is an early sample or model built to test a concept or process or to act as an object to be replicated or learned from. This can refer to hardware (i.e. tangible items), but also to software models or simulations. An excel sheet with model of how a business may develop is also a ‘prototype’. A prototype is anything that is designed specifically to test and validate a new design.
The main reason for prototyping is to give you the ‘oh-I-should-have’ feedback. This is feedback you would like to have before you have the final version of what it is you are building or constructing. For example the figure on the right, let’s say you are building a chair and you are trying a classical connection method using dowels. If I would have created and tested a prototype, I would have realized that the diameter of the dowel is critically important and should not be selected too small. I now have in our living room a chair that is almost perfect, and a constant reminder of the ‘oh-I-should-have’-importance of prototypes.
As the purpose of a prototype is testing, a prototype is not defined by its quality, i.e. the material used, the precision of manufacturing, the choice of color, the finishing applied etc, provided it serves the purpose of testing. Clearly, the material and manufacturing quality used must be selected based on the purpose of the prototype. For example, if you want to test the maximal load balance of a bridge you will not build a bridge from paper, although a paper version of the bridge would be sufficient to evaluate the aesthetic properties.
The matrix on the left shows the generally accepted guidelines on situations in which prototypes are more likely or more appropriate. Basically, this depends on the risk of the final product as well as the cost of producing a prototype. The higher the risk, the more likely the design process is supported by prototypes, while higher costs inversely relate to the likeliness of using prototypes throughout the development process.
Types of prototypes are typically split into horizontal and vertical prototypes. A horizontal prototype is one that covers the product or process from start to finish. Typical examples of horizontal prototypes are fire-frames. The purpose of horizontal prototypes is clarify requirements and to validate the scope. Vertical prototypes, however, focus on a specific aspect of the product and make a working version. The purpose of a vertical prototype is a (technical) proof of concept; to show the design will function under realistic load and use.
The quality of the prototype (e.g. finishing, precision, care of creation) often is taken as proxy for the quality of the thinking leading to the prototype. Although those who have built prototypes know this is not necessarily related, but still motivates you to build a presentable prototype for every stage of the development process. However, this sometimes undermines the effectiveness of your prototype as means of testing and validating. Test subjects’ reaction and feedback often depends on the quality of the prototype. They may react differently to a sketch compared to a perfect rendering. With a beautiful rendering you may find them hesitating to even touch or point, while with a sketch they will be immediately look for their pen, even while talking to you. Depending on the phase of development and the characteristics of the product you are testing, you have to balance quality and finishing to optimize feedback.
I experienced this difference when I was called in to help evaluate a new software prototype. The development team told me they had produced a prototype, which they had evaluated with a few end-users. The feedback collected up to that point was very poor at best. To the users, everything seemed good and perfect. Too good and perfect, which contrasted with the feeling within the team. I participated in one of the evaluation meetings and verified that the end-user had little or no comments about the prototype. Except maybe for the position of the logo and the colors used, all seemed perfect. I am exaggerating a bit, but software, and especially software prototypes, are difficult to prototype for two key reasons. First, it is easy to make a software prototype appear like a finished product. With some artistic skill, basic web technology or even using a simple presentation tool, you can create a prototype running on your iPhone, which you can make to look like a finished App. The prototype from the example here is shown above. It shows two screens, one of which is the prototype (after two weeks of hacking) whereas the other is the real application, which took at least another 6 months to complete. I do not recall anymore which one was which, and at the time the state of development was also not clear to the end-users who were asked for feedback. With prototypes like this it is difficult to understand the state of development. This is less likely to occur with physical products. Take for example the images below, of the 1963 Citroen Ami6. Nobody will have difficulties understanding which is a prototype.
Just out of curiosity, I created a new prototype (right); obviously hand-drawn, and went back to a few of the end-users. This prototype, although in terms of structure was a copy of the previous version, it was more clearly in its initial stages of development. By presenting itself for what it was; a first sketch, this prototype invited a completely different type of feedback and discussion. Subjects revealed more flaws and eagerly looked for a pen to make corrections, resulting in a list of issues for the development team to chew on. This is exactly the purpose of prototypes; to invite examination and criticism. At the early stages of development a prototype that shows the stage of development, like the sketch in the example, is often more suitable to invite feedback compared to a more polished looking prototype, which may make users reluctant to criticize. Or worse, they may leave with the impression that the product is almost finished. Another risk of polished looking software prototypes is illustrated by the case of member of the marketing team testing a prototype and then one week later informing us that he already had a potential customer, and inquiring about release dates.
Prototypes help to ‘ground’ the discussion, to align different views and expectations. This is true not only for discussions with the client, but also between members of the design team, helping to facilitate work across disciplinary borders. A prototype cannot be disputed as a written description can. In this way, prototypes help to get a formal approval at each stage of the process.
In our digital life. we are connected constantly, but not all the time in the same way. To reach clients we need to be omni-present in the client’s digital life, whenever or however they connect .
Channel is a concept often used when talking about reaching clients. A channel is an means to transmit data and information. Channels typically are connected to a platform of some sort. The newspaper is a channel. The television is a channel. The tablet is a channel. but are they really? How can the tablet be considered a channel if the newspaper is also a channel, since the newspaper is made available on paper, on the desktop computer and on the tablet. Or is the paper version of the newspaper a different channel compared to the digital version? As a reader, this is not how we expect them to work. We expect that if I start reading an article in the printed version, I can continue reading the same article on my smartphone, should the situation call for it.
The concept of channels, as information channel towards a (potential) client, may shift away further from the actual tool or technology used to establish the data and information connection, and become a specific aggregation of tools and technologies through which the target segment can be characterised.
At the moment, a channels’ definition is linked to the technology used. We refer to a channel as a single technological infrastructure, such as for example a tablet computer or a smart phone. Wikipedia explains; Historically, communicating data from one location to another requires some form of pathway or medium. These pathways, called communication channels, use two types of media: cable (twisted-pair wire, cable, and fiber-optic cable) and broadcast (microwave, satellite, radio, and infrared). Cable or wire line media use physical wires of cables to transmit data and information. Twisted-pair wire and coaxial cables are made of copper, and fiber-optic cable is made of glass. Nowadays, in information theory, a channel refers to a theoretical channel model with certain error characteristics. In this more general view, a storage device is also a kind of channel, which can be sent to (written) and received from (read), like for example a smart phone.
The way we use technology, this traditional definition of channel as technological platform does to suffice. In former times, people were either watching the television, or reading a book or listening to the radian. That where the simple times. To communicate to your target segment you had to select a (technology) platform, and maybe a time frame (e.g. run the advertisement in the morning or in the early afternoon? On sunday maybe?). Reaching your target segment meant pushing the information or message through the selected channel, i.e. platform. Placing an add on the television. Running an interview won the radio etc.
In current times, we have the i-family of products that we use imexchangably, and worse, sometimes all at the same time. At the moment I am writing this on a laptop while following twitter on my smartphone. In half an hour I will be on the train home, and probably first browse my mail on my tablet. Reaching your target segments in current times means sending the same message via different platforms that your target customers are using. A channel used to be a single platform, but tends to grow into a specific constellation of platforms that are used by the target segment in combination to basically perform the same activities.
This is illustrated with the image above; Nowadays,we are are connected throughout the day with the same source of information, but depending on the time of day and on the kind of activity, the platform and tool used to access this information differs even if our activities are the same or guided by the same interest. Take Jack for example. Jack lives in the city and commutes to work by tram. When he wakes up he first glances over our smartphone to check latest messages and news snippets. During breakfast he reads the news on a tablet. Commuting to work he again browses his smartphone, while at work it is his (desktop) PC that rules. Commuting back home he plays a game on his smartphone, and in the evening he watches a movie while chatting with friends and liking Facebook posts on his tablet. Then just before going to sleep, he glance a last time over his walls on his smartphone.
The point is that in order to reach Jack, in order to get his attention, it is not sufficient to address a single platform. To reach Jack, we need to send small notes or ramified information to his smartphone, maybe full texts with multi media to his tablet, and again small notes to his desktop (since this goes in parallel to ‘working’). The channel to Jack in fact consist of a smartphone, a tablet and a desktop pc. Now, maybe you are not Jack, maybe you are more like Peter. Peter has a smartphone and spends his time commuting reading the newspaper he subscribed too, on his tablet. The channel to reach Peter is different, not only the platforms it consist of, but also the manner in which Peter interacts with them, and probably also the amount of time spent on them.
‘channels’, as connections to transmit information and data, have grown into an aggregation of platforms that function in full symbiose, based on the behaviour of the target segment. In reaching this target segment we need to identify the platforms the channel is constructed from.
redefining what are channels, forces us to re-think how we reach our target segment, and invites us to move away from pushing data over individual platforms towards orchestrating information over various platforms in with the purpose of becoming more effective in informing and reaching the target segment throughout our digital and ’always connected’ day.
Context of use is an essential input to the design process. It helps to frame the problem, define product goals, identify requirements, inspire conceptual design, and create basis for scenarios for validation and usability test. Information about the context of use of a product are generally collected early in the product life cycle and then refined as additional data are gathered from usability studies. By definition context of use determines usability. The ISO 9241 standard Part 112 Guidance on usability (ISO, 1997) defined usability as ‘the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.”
The Context of Use consists of the users, tasks and equipment (hardware, software and materials), and the physical and social environments in which a product is used. ISO 9241 standard Part 112 Guidance on Usability (ISO, 1997), or, in different words: the Context of Use is the actual conditions under which a given artifact/software product is used, or will be used in a normal day-to-day working situation. (ref: Interaction Design foundation).
The context of use analysis involves collecting and analysing detailed information about:
- The intended users, i.e. personas
- Their tasks
- The tools that support the users’ goals
- The physical environment in which a product will be used
- The user’s social and organizational milieu
- The technical environment and associated technical constraints
- Other contextual factors that will affect the user experience
Great. That sounds simple enough. Now what?
EMUS suggest that “Context of Use (CoU) analysis is a generic technique that assists development by posing certain probe questions about the project. [No] The probe questions elicit from the development team and other stakeholders in the project information that may be held ‘below the surface’ by one or more of the constituent groups (usually unwittingly). The effect of carrying out CoU analysis is to bring this information out into the open at an early stage in development, when the implications can be examined and to drive the formulation of a realistic test plan.” (ref: European MultiMedia Usability Services)
So a checklist is what we need?
Actually, browsing the Internet you stumble over checklist, summarizing items to check, record and consider. I’m not a fan. Checklists that have the problem that they do not give insights into the constraints, merely offer a list to tick-off. Often, the process of ticking-off dominates, shifting from checking usability to the next item on the checklist. You see a similar behavior with alert boxes. Are you sure you want to delete this file? Are you absolutely sure you want to delete this file? Are you definitely certain? By now you just want to get rid of the alert box, so of course you are absolutely definitely certain. Luckily, we have time machine.
Obviously, there are more methods then just checklists to collect data for context of use. For example interviews, workshops, surveys, site visits, artefact analysis, focus groups, observational studies, and contextual inquiry. Basically any method that helps to collect data can be used to collect information about the context of use (……).
If methods are plenty and available, critical for collecting information on context of use part must be in what the methods are applied for? What is it that we are looking for?
What we should be looking for when analyzing the context of use are the factors that constrain use. Yes, we want to know typical behavior and scenarios, but as designer we are especially interested in boarder-line situations. “Yes, I want to have that information on my tablet 24×7. Well, not when I am taking a pee, obviously. Then I want to have it on my smartphone. These borderline scenarios may not serve as requirement, but they will help prioritize the requirements we do have.
For mobile software, the most basic parameters that govern the constraints on use are; the physical location, the device on which the software is running, and the available attention span.
- The physical location is a fundamental parameter. Typical locations are home, office, on ‘on the road’, i.e. in-between. To specify this a little further, the locations are further detailed. For example, at home the areas have very specific application and because of this you can expect the portal use to be different. In the kitchen, while eating breakfast, you may have less time and attention compared to sitting in your study with a tablet on your lab.
- The device is an important parameter. Depending on you location and situation, you prefer a different device. A laptop in the office, an tablet at the kitch table and a mobile phone while walking through the city.
- Most important parameter may well be the user’s attention span. My attention span is different when I am sitting in a tram in Zurich with people entering and leaving every 3 minutes compared to being on the train gliding through the alps with, apart from beautiful scenery, nothing to distract or interrupt me for maybe a hour. Attention span and usability appear orthogonal, when it comes to their relative importance. In case attention span is infinite, usability becomes almost irrelevant; given infinite time anybody can learn anything. By contrast, when the attention span is limited, the tools must not be complex.
To analyze the context of-use I’ve created the form as shown below. You can download a free copy here. This context-of-use-form combines ‘device’, ‘attention span’ and ‘physical location’, into a basic grid to support the analysis of context of use.
To illustrate the use of this form, we use it to evaluate the context of use of a new to be developed research portal. A bank is developing a new research portal for their wealth management clients to give access to research material. The portal will be available via multiple devices, via a pc/laptop, via a tablet and via a smart phone.
As a first step, we looked at the use situations for the ‘standard user’. The result is shown below. This overview, although revealing, reflects the general expectation. For specific users the situation may be different.
To become more specific about actual user needs we use personas. In a previous project we have interviewed a large number of client advisors and based on this developed a set of client personas. From this set, we selected a few to create a small cast.
The next section gives two examples of how the context of use form will look like for specific users (as characterized through the personas). Meet Ana and Danny.
Ana is independent; not employed but with has moveable assets in the amount of 30 Million CHF, which was inherited. Her father was an entrepreneur while her mother took care of the household. Ana was married, has a University degree in Art History, and 2 children; a son 30 years working as electrical engineer and a daughter, 28 and married, with a university degree in Marketing. Ana is frequenting the club life. Clubs have beach campuses, city campuses, and sport campuses for members – and are very popular with the high society in Latin America. In addition, she likes to play golf and fitness. She drinks black coffee, but only in the morning. She has both the latest blackberry and iPhone. Ana consumes information throughout the day, both in paper form and on-line. She typically reads one local newspaper and one form the US. She will surely cover the economic, political, cultural and social life sections. Ana is in regular contact with the bank. She is fairly experienced and likes to be involved in the investment decisions.
Completing the form for Ana reveals a completely different situation, as show below.
Let’s have a look at Danny.
Danny (or Daniel as his mother calls him) obtained his wealth through a donation. He was born and still lives in Stuttgart, where he followed a professional education and became a certified accountant. His mother was a teacher. His father owns a company in network components of about 900 employees large. After his studies, Danny started working fro the KPMG in Zurich, mergers & acquisitions. He now is COO in his father’s company. Danny drives a Porsche 911, likes travelling, cooking, dine and wine. No sports. He reads the Wall Street Journal, the Frankfurter Algemeine Zeitung and the NZZ. He reads research information provided by his bank, provided it is crisp and clear. After receiving the donation he immediately invested all with his bank. He is a conservative client, and although he is independent and experienced, Danny allows himself to be driven by the Client Advisor.
Danny, being different person than Ana, also gives a different situation, as show below.
In combination (the form for the generic customer, for Ana and for Danny) the forms give a diverse overview of the constraints, sketching the solution space from the point of view of usage (i.e. context of use). Using the personas, and based on these overview it will be easy to describe a number of scenario that illustrate the usage and can be used as reference scenarios capturing the context of use in aspects that are relevant to consider when designing a solution.
Pre-school skills are effective to reduce the threshold and engage stakeholders in prototyping and collaborative problem solving.
A request-form is not exactly rocket science; it a form to enter data to request a service or object. In this case it concerns form as part of a tool to manage (i.e. plan/track) events at one of the larger Swiss banks. The form is used to enter the basic data about the event; where does it take place, what is the client segment, what is the topic to be presented on and who is organising it. Simply a list of items to be completed.
The only complication is the relationship between some of the items to be entered. In case it is an event of type A there is a different client segment compare to events of type B. In addition, incase the event is of type A then there are two possible types of event hosts, and each type requires different information to be entered. A small 2 layer decision three, with at each node two options. But this covers only 3 of the about 20 fields to be entered. The remaining 17 have no intrinsic sequential logic that could be used to guide the order of the fields.
The apparent randomness in order of the fields to be entered became crystal clear when the request-form was first presented. For various reasons the form could not be copied one-to-one from the wireframe, and the developer had to improvise. Developers are great at improvising, but not when business logic is missing. The result was a form with all the fields, but clearly in a less that organised sequencing and or grouping.
How to involve business in defining the order of the fields. Sounds simple enough, right. Just sit behind a screen, have business review the form and finalise the preferred order. Or print the form and review on paper. Get it approved or corrected by Business, et voila. Done, right? Well, no. Experience teaches that the real issues surface when the form is actually used; not when glanced over, despite all good intentions. Issues are found in interaction, not in observation.
So, how to ale business interact with a form when the they are not really performing the task for which the form was designed? The accepted approach is that you play through use-cases; “Imaging you want to request an event participation. Please fill out the form. Now what do you think about the order? “ One problem with this is that it just pretend, and everything will look ‘just fine’. You are playing through the case of entering data. Independent of the form order, you will be able to enter the data. Therefore, apart from major issues, the form in what ever form it is presented, will be ‘just fine’.
In a real situation you will be under time pressure with at least 37 other tasks waiting for you to complete, maybe with only part of the information at hand, etc. Such a situation makes you much more sensitive to suboptimal sequences and situations, compared to just staring at a piece of paper pretending to enter a request.
A second problem is that it is difficult to imagine the alternative. You can try to draw on the paper. Indicate with arrows what would be the preferred sequence. Field seven goes after field 3 but before field 12 and that as a block should be placed before the block containing field 1 8 and 11. Come again? Yes, you can also sit behind a screen and change the order as you discuss. That might work.
The solution tuned out childishly simple; cut the form in stripes, every stripe containing one entry field, and put them in the preferred order. It resulted in a short discussion with Business to define the order of the fields. A bit of back and forth on a few fields, but all in all it took 5 minutes, maybe 7 to arrive at the preferred sequence. Actually, it took 10 minutes because it took me 3 more to explain why this was effective, despite the fact that it looked like a pre-school kind of task. On a side node; I always wonder about this; we never worry about walking, even though we clearly learned this at a very early age. We use the skill to walk every day, simply because it is a very effective skill when you need to move from one place to the other. However, when it comes to other skills we learned at pre-school (cutting, glueing, drawing) which are equally effective in certain cases, they often are discarded as something childish. Not done.
After the meeting with Business I documented the newly defined order of fields and briefed the developer. In an attempt to make it easier to recognise the fields and the order, I left some space in-between the fields. Feedback from development was priceless; everything was clear, but they wondered if I really wanted to have the spaces in-between the fields. OK. So I got a solution and a smile.
In the end, the approach proved a very effective way to resolve a – agreed – simple issue; presenting the problem in such a way that you can collaboratively prototype the solution. Important was not just the approach of prototyping by itself, but the manner in which we created a very low threshold to engage in prototyping and making and reviewing changes. Well, after the pre-school approach was accepted of course.