Sunday, 27 September 2015

How do entrepreneurs do it?

A look inside NeXT. "Video: Steve Jobs brainstorms with the NeXT team (1985)"

Reality distortion field warning. Does this remind you of what goes on inside your own company? I'm tempted to think that the atmosphere the Jobs was recreating at the time was drawing on his experience with Apple, specifically trying to replicate the best bits (for him). My sense of the initiative is that they reverted very quickly into death march mode.
NeXt was 90 days old at the time, they initially anticipated a price point of $3,000. They were talking about an 18 month design and delivery schedule. At the second retreat the company was 180 days old and the project was already over budget, behind schedule and with an unclear feature list. Finally the first NeXT Computer shipped in limited quantities in 1988/89 with beta software and a price tag of $6,500. Not only had they designed a new computer and operating system embodying the most advanced and sophisticated technology of the day, they had also constructed an almost completely automated factory capable of manufacturing 150,000 units per year. Anecdotally they only ended up selling 50,000 units (Wired Magazine article and Wikipedia article).


Friday, 25 September 2015

#NoEstimates debate spreads

The #NoEstimates debate: An unbiased look at the origins, arguments, and thought leaders behind the movement - See more at: http://techbeacon.com

Tuesday, 22 September 2015

The Essence of Design: some notes

What is the essence of Design?
Competing on the eight dimensions of quality D. A. Garvin Harvard Business Review 65 101-109 (1997)
In Garvin's influential essay on the dimensions of quality (1987) he relegates aesthetics and perceived quality as the most subjective aspects of product design, the facets most open to interpretation and therefore least manageable and thus relegated to mere footnotes in the product management literature. The implication of this it would seem, is that "whole product experience" is perhaps relegated to footnote, that the essence of design, is essentially unmanageable, and yet...

Expressing Experiences in Design B. Moggridge Interactions 6 17-25 (1999)
In contrast, Moggridge argues that the essence of design should in fact be the central focus of product design. The term he uses is 'Design Expression', the expression of the design. Design expression suggests the particular manifestation of a design. It is a holistic concept. The notion of 'expression' draws on and supports the language of design, design values such as: tradition, simplicity, elegance, complication, playfulness, youth, childhood, age, skill, strength, transparency etc.

According to Moggridge, design should satisfy many senses, not merely the eyes. Another way of putting this; design can harness many senses to better fulfil the designer's intent.

Since the Moggridge's article, the then rather unconventional examples, have, largely become mainstream products or features. The following products amplify some of these ideas:

Montage of tabletop interface props used in Hawaii Five 0 series (search link)
Usability Evaluation Considered Harmful (Some of the Time) S. Greenberg and B. Buxton 111-120 (2008)
All well and good then, but what is the essence of design? A finished product? No. Greenberg & Buxton (2008) contend that design is processual, a process that should remain rather open-ended as long as possible to explore, learn from and respond to that learning. Sketching is a crucial stage in HCI (human computer interface) designing. But they caution against making design appear too polished, that there is value in presenting it in rough form, as contingent and open ended, in order to facilitate learning (from the field, from users, etc). They caution against using high fidelity prototypes too soon.
The problem is that these working interactive sketches – especially when their representation conveys a degree of refinement beyond their intended purpose – are often mistaken for prototypes, i.e., an approximation of a finished product. Indeed, the HCI literature rarely talks about working systems as a sketch, and instead elevates them to low / medium / high fidelity prototyping status, which people perceive as increasingly suggestive of the finished product. Yet this perception may be inappropriate, for prototypes are very different in purpose from a sketch. 

Monday, 21 September 2015

Media Analysis Method - Exercise

Media Analysis Method Exercise:

Watch and/or listen to the media (film, video, narrated presentation, audio recording etc.). Using the Research Notes for Media Template, make your own series of analysis notes, i.e.: factual observation + timestamp + research comment.

example of media analysis data capture sheet

Time-lapse video data/method

I was curious about how useable the various ticketing systems used for the Luas tram system are. The Luas is a light rail tram running in Dublin, Ireland.

There are two lines, the green line running from St Stephen's Green to Cherry Orchard near Bray, and the red line running from The Point/Connolley Station, to Saggart in the South West of County Dublin. The Balally Luas stop is halfway along the green line (link to map of Luas Green Line stops) and serves the Dundrum Town Centre shopping district, nearby Airfield Farm and surrounding suburban area. https://luas.ie/balally.html

This video covers a 15 minute period, using time-lapse, the footage is sped up 2,000%. I added a blur to anonymise the citizens and a vignette to provide a focusing effect.

Watch the sweep pattern of the two security personnel in black.

Watch 5 trams pass through as the person in orange struggles with the ticket machines on both platforms, and still doesn't catch the tram.

Tags: Luas, time-lapse, public transportation, Dundrum, Ireland
Balally Luas stop, Dundrum, Dublin. by Allen Higgins on Vimeo.

An alternative to Product Roadmaps?

The product roadmap idea is ubiquitous in high tech development. So much so that we rarely challenge the idea, let alone question its usefulness.
Marty Cagan's post on the topic tries to do both, while at the same time presenting a better way of achieving the underlying goal. (link the alternative to roadmaps SVPG).
My view on this is that a product roadmap usually repeats that old problem of design versus need.
State the requirement in terms of the problem or goal that you want to address, rather than in terms of how you think it should work.
A collection of images produced by "product roadmap template" search term.

The essential character of a product roadmap is, ultimately, yet another GANTT chart (YAGC; a pretty horrible acronym after all).

Friday, 18 September 2015

Week 1 notes

MDD Week 01 2015
















Notes from first week classes

Tuesday, 8 September 2015

Starting a Tech Business by Alex Cowan

Alex Cowan's recent book on starting a tech business is one of the most practical guides I have found. This book brings it all together but in a way that is engaging, relevant, current, and, if it's not too difficult to believe, in a FUN way.
Cowan's highly recommended "Starting a Tech Business".

Alex's metaphors for each of the main periods the business undergoes are quirky yet insightful. The metaphors resonate because they capture an element of the truth. For example; The Lawn Gnome of Indolence, the Butterfly of Incoherence, Chihuahua of Unruly Development, and the Hydra of Operational Readiness; each of these metaphors says something, as wry but insightful observations on the character and challenges involved in tech business at different times.

Highly recommended as a guidance for entrepreneurs starting out on systems development or a tech business for the first time or even as a framework to refresh an existing business, product, system, etc.

Sandbox area

A link to a temporary sandbox area on Google Drive. (link)

A reflection on the themes, theories, and exercises of MDD


What is the focus of the MDD course? The course is designed to critique the lifecycle/methodology perspective and to highlight the necessary tension between orderly and responsive production of high tech systems. It draws a link between the management of systems development with its impact on innovation through technology.
How do the topics, themes, readings and exercises in the MDD course relate to the focus of the course?
Consider these two personas as the audience for this course:
  • a business person participating within a development dynamic
and
  • a developer interacting within a management dynamic

The themes, theories, and exercises.


The material covers three fields of action or understanding that are ultimately linked by activity and processes.
  • Basic Theories
  • Methodologies or Frameworks (addressing the outward structure of organisation)
  • Practices and Techniques (addressing micro-practices and interpersonal interactions)
The teaching method employs a seminar style with traditional presentation, discussions, case-based learning and practical exercises.
Classroom discussions focus on the readings, cases, exercise or other topics. The benefits of discussion are:
  1. To review the subject matter. 
  2. And more importantly, to familiarise students with the terminology and language of development.
Relating the themes and subject matter to the syllabus

Classroom discussion allows you to acquire and exercise your own knowledge and allow you to employ these terms and the language of development in a risk-free supportive environment.
Each of you will have different knowledge and experience gaps. However the most important part of this exercise is you, the novice wishing to learn or the practitioner wishing to reinterpret your professional practice. You bring a questioning attitude (and a load of questions). The lecturer (and other members of the class) will bring their own experiences and knowledge to the setting in an attempt to interpret and address your questions, suggest alternatives, or suggest new sources of knowledge.

Comment:

Reflecting on the course, the subject matter and the material presented over the duration of the lectures it is obvious that, at the very minimum, the ideas in the readings are relevant as are the notes and slides on the themes, the optional readings, and perhaps more importantly, the learning you acquired through independent investigation. The book (Soul of a New Machine) and the case studies present opportunities to apply these ideas more broadly and in multiple ways. Consider reflecting at a personal level on own changed perspective or new understanding (or not but if not why not?). Are you able to relate the goals of the course to the content?

Monday, 7 September 2015

What is a system?

A SYSTEMS PERSPECTIVE ON HIGH TECHNOLOGY DEVELOPMENT AND USE
Mid-Range Systems Concepts and drawing the Boundaries of High Tech
Systems development is closely associated with the production of technological artifacts, in particular with computer based high tech products and projects. Systems development is presented as an engineering design method (Gregory and Richard L., 1963, Brooks Jr., 1995). Indeed engineering design has become doubly system-like as systems development concepts were applied both to the design of high tech products and to the organization of the work of high tech production itself. The very idea of systems and systems thinking is so pervasive as to become an intuitive concept. A system can be considered as any assemblage or set of objects (concepts, things, distinctions) connected in some orderly or meaningful arrangement.
“The systems approach to problems focuses on systems taken as a whole because there are some properties of systems that can only be treated from a holistic point of view.” (Ackoff, 1971)
Like any powerful concept the idea of system is flexible and adaptable. The questions posed by systems thinking are what elements to include, how to relate them, and where to draw the outline of the ‘whole.’ The boundary (if any) becomes crucial, what is considered inside or outside, is the boundary itself another element or does the idea of boundaries or interfaces even make sense?

THE PROBLEM OF HIGH-TECH SYSTEMS
Why does it take so long to get software ready?
Why are development costs so high?
Why can’t we find all the errors before we give the software to our customers?
Why do we continue to have difficulty in measuring progress as software is being developed?
Adapted (Pressman, 2000).
The same questions have been raised at every point in the history of computing and are still being raised today. Furthermore they are as relevant now as they were then. However, in 2003, Nicholas Carr famously declared that IT doesn’t matter anymore (Carr, 2003). He suggested that organisations should spend less on IT, copy other organisations’ technology infrastructure rather than generate innovations, and focus on operational improvements rather than creating competitive advantage through radical innovative development. So, if IT doesn’t matter anymore, why is there an on-going problem managing high tech products and IT governance?

We observe a continuous current of media, practitioner, and research literature reporting the failures of large-scale system implementations (Ruey-Lin, 2006, Krigsman, 2010, Lyytinen and Robey, 1999, Currie and Willcocks, 1998, Keil and Montealegre, 2000). Much of the reportage and research concludes that IT use, production, delivery and management are brittle. IT is incredibly sensitive to situation, context and human factors (Suchman, 1987) and, evidently, as IT shifts across the product/service spectrum from stand-alone product to service rich high tech systems, outcomes become more costly and chaotic (Brooks Jr., 1987).
IT systems have become more complex and therefore more difficult to manage. Project planning and governance is particularly challenging when the subject matter is highly virtualised and intangible. IT systems become organisationally systemic even as system knowledge and skills become more specialised and rare. Various actor strategies and organisational structures may disconnect or invert necessary links between knowledge, responsibility and power.
Adapted (Avison et al., 2006).
First some definitions. IT (Information Technology), ICT (Information Communications Technology), and High Tech are broad terms and difficult to pin down. For the purposes of these readings we can consider them to be products and services utilising microprocessors and the related objects they entail. High tech systems utilise hardware (electronics) and software (programs), often in the form of computing devices, computers, networks and Internets, although some high tech systems are less evident or may now be considered old tech, e.g. wrist watches.

The organization of the high tech development and production is naturally important but equally significant is how the development process is used to understand, formulate and resolve the real world needs or problems addressed by high tech products. Product systems are created against a backdrop of our prior assumptions and understanding of what systems actually are. Our understanding of what constitutes a system needs therefore to be clarified, so, what in fact are ‘systems’?

The idea of systems and ‘systems thinking’ is so prevalent as to have become an intuitive concept or perspective of any aspect in the world. The word system is now linked with the environment, ecology, markets, engineering, society, and politics. The OED defines a system as;
“a set or assemblage of things connected, associated, or interdependent, so as to form a complex unity.” (OED, 2010)
The system concept is used for operations research to create models; mapping representations of disparate phenomena and functions, presenting them as an organizational whole. In the most general sense the system concept is applied when a complex phenomena is perceived to
“…display the character of being organized.”
(Emery and Trist, 1965)
The appearance of organization, of being organized, is assumed to arise out of interdependencies between underlying processes or other related phenomena. One of the challenges to studying and interacting in complex relational environments is the very act of defining the system.

Systems can therefore be understood as descriptions that limit the extent of an enquiry. A system is constructed by description. A system is a more or less exhaustive statement of more or less arbitrary boundaries, inputs, outputs, interactions, behaviour, performance, relationship, of abstract and concrete objects.

At its most general the very idea of a system helps us to organize ideas about the relationship between things. The system concept offers a way of representing, sometimes modeling, an often arbitrary arrangement of elements that exhibit a relationship or correlation of behaviour.
“A system is a set of interrelated elements. Thus a system is an entity which is composed of at least two elements and a relation that holds between each of its elements and at least one other element in the set. Each of a system’s elements is connected to every other element, directly or indirectly. Furthermore, no subset of elements is unrelated to any other subset.” (Ackoff, 1971)
A closed system is self-contained with interaction taking place solely among the system’s elements. Delineating the set of elements in a closed system defines the boundary between that system and its surrounding environment. For a closed system the environment acts simply as a source of variables affecting the system’s initial state or condition.

An open system is a system that interacts both internally and with the surrounding environment. The outputs of an open system alter elements in the environment which in turn affect the system’s state over time and so on. Dynamic systems change over time and may both generate and respond to events thus changing even more over time.

Where systems concepts include human actors, as individuals, or organizations and markets, the act of defining the system becomes a subjective exercise that may or may not correspond to obvious or unambiguous distinctions (Avison and Fitzgerald, 2006). Ackoff (1971) presents a hierarchy to classify systems (Figure below). At the lowest level a mechanical system is state-maintaining. A goal-seeking system uses the environment as a source of information to attain a goal. Multi-goal-seeking systems are devices or objects that can be re-tasked to achieve multiple goals such as a general-purpose programmable computer. Purposeful systems involve humans and are intrinsically open, dynamic and unstable. Purposeful systems are subject to changing goals, motivations and relations as the human actor constructs these things through their interaction with/in the system and their constantly evolving interpretation of goals, values, outcomes, identity etc. Purposeful systems may contain all other system types as more or less well-understood elements and objects. Weinberg (1975) characterised types of systems with respect to associated methods we have of dealing with them (Figure below). Organised simplicity: I (machines), unorganised complexity: II (large populations and markets), and organised complexity: III (mid range systems between the extremes of I & II).

Figure: Classifications of system types.

SYSTEMS THINKING
Systems thinking analysis can be used to illustrate and group the problem domain of trade-offs between the scale of a system and its connectedness as depicted below. We can imagine a problem space for systems thinking to vary along the dimensions of complexity and randomness, or as suggested (Figure below), by connectedness and scale (complexity and complication). I have adapted Weinberg’s terminology in this diagram his original axes were x=complexity, y=randomness however the original intent remains the same; to characterize a conceptual problem space between mechanistic models and statistical models which he termed ‘medium number systems’ or ‘organized complexity.’

Different regions in the problem space are amenable to either: analytical, statistical, or (as Weinberg argues) a systems thinking approach. Recalling the trade-off between scale and connectedness. The first category: organised simplicity, describes relatively well-described simple systems that may be modelled analytically or deterministically as machine-like systems. The second category: unorganised complexity may be modelled statistically and applies in situations with sufficiently large, complex populations when aggregate behaviour begins to approximate stochastic (probabilistic) processes. The third category: organised complexity, describes dynamic structure-determined systems as evidenced by emergent properties and behaviour. These are medium number problems that are…
“too complex for analysis and too organized for statistics. This is the region of systems.” (Weinberg, 1975)

Figure: Types of systems with respect to methods of thinking (adapted from Weinberg, 1975)

Mid-range complex systems are typically the subject matter for management, engineering, sociology, and politics. They deal with problems that are dynamic and interrelated but essentially beyond finite analytical modelling because factors cannot be isolated or parameterised, or the computational load of a detailed model is excessive or based on unrealistic assumptions. Yet these problems are not large enough or randomised such that stochastic or probabilistic methods are useful for predicting or managing outcomes.

MID-RANGE COMPLEX SYSTEMS
So what is a mid-range complex system? Weinberg suggests that it is an open evolving system. The assumption of being bounded and approximately mechanical does not hold. It is a structure-determined system that adapts and evolves over time. A mid-range complex system is coupled with its environment and its boundaries are defined by its interfaces; processes of interaction and transformation with the environment it exists in and which it in part constitutes (Winograd and Flores, 1986).

How do system-like effects arise in the environment for high tech product/services? High-tech products typically invoke new system-like behaviour from users that over time begins to pervade the lives of individuals, families and groups in ways that we cannot predict with certainty.

EXAMPLES: The following examples depict the emergence of system-like interaction and behaviour arise between people and high tech objects (credit: Stefan Klein).

The telephone is not just another way to talk to someone over a wire; the mobile phone is not just a traditional telephone without a wire. The telephone, a spatially fixed communications device, could never attain the pervasive availability and use that the mobile phone has achieved. Mobile telephony has led, in turn, to the discovery of novel forms of coordination, collaboration and surveillance. It has redefined the notion of availability, and dramatically extended the scope of options to get information or call for assistance in everyday situations.

RFID technology was designed for simple product identification, but it can also be used for tracing and tracking things, ranging from the identification of licit products to the surveillance of teenagers. The meaning that is assigned to technologies and their modes of use is highly contingent on the context of use, (groups of) users, their relations, etc.


ThinkD.org - design thinking in the world

Worth looking at, an eye for common annoyances that could have been avoided with a caring 'design attitude'

So, how about these as a set of 'Norman' Doors. Which one should I use? The one on the left? The one on the right? Or the middle door?

NormanDoor_02
Both signs read "Please use this door".
Have a look at ThinkD.org for examples of contending with designs encountered in the world

Your own website...

Free website services that are useful, useable and reliable.

Blogger (blogger.com). Lightweight and simple. Works well if you have a gmail account as they're a subsidiary of Google.

Wordpress (wordpress.com). An independent blogging service provider with both free and paid-for offerings. Very fully featured with a focus on addressing the needs of dedicated bloggers.

Weebly (www.weebly.com). A freemium model. Free basic, pay for upgrades.

There are many many other service providers and approaches.
In addition you might go the route of registering your own domain name and then pay for it to be hosted by a third party hosting/application service.

What customers really want?

How do you decide what product feature to develop next, how to enter new markets, address more customers, how to disrupt and innovate with your product?
  • Innovation is hard.
  • Innovation is not simply a matter of inventing new stuff.
  • But yes, innovation is all about the introduction of the new.
  • Introduction implies dialogue, talking with and listening to.
  • Innovation holds out the promise of growth and transformation, both of which are difficult to predict based on historical data.
What customers really want is something for a "job to be done". Think of this in terms of what the customer comes into your shop to buy.  Think of it as your customer having 'a goal in mind' and your product or service is simply an 'in order to...' But sometimes the product you deliver is like an infrastructure or background against which the customer does something.
SnapChat is a bit like this (as are email, FaceBook etc). The service offers some way that lets the customer do something; send a message, post a photo, annotate or draw on a photo, share the picture with friends.
Think of your product and features in this way. No one buys a phone for the pleasure of owning a phone, they own it in order to call and receive calls. At a very basic level your product or service is simply an 'in order to..', it is necessary equipment for the 'job to be done.' This basic level of utility merely gives your product permission to be considered for use. 

http://blogs.hbr.org/2014/05/generating-data-on-what-customers-really-want/
also
(http://www.ie.edu/business-school/faculty-research/faculty/juan-pablo-vazquez?_adptlocale=en_US)

Juan Pablo Vazquez Sampere offers the following diagnostic in order to address this problem, of finding out what customers really want.
  1. List what you think are the 10 key characteristics of your product offering (e.g. speed, easy to use, ergonomic, cheaper than rivals, etc.)
  2. Then interview 10 users and 10 non-users of your product, but importantly ask them questions that seek to understand their "job to be done" and "in order to's'.
For users start by asking:
"
a) Where are you when you are using this feature?
b) When you use this feature, what are you really trying to do? (accomplish, achieve...)
c) If this feature were not available, what would you be using instead?
You can ask the second two questions without reference to your product.
(Sampere, 2014)"
Likewise as non-users the second two questions without reference to product, they don't use it anyway but they still attempt to achieve "in order to's" or complete "jobs to be done". Vazquez's steps 3, 4 5 & 6 are methodological: 3 - Transcribe the recordings, 4 - code the transcripts, 5 - group codes, 6 - interpret the data (in this article Vazquez recommends quantitative analysis of the coded data). Alternatively I recommend the application of grounded theory to code and interpret this kind of interview based quasi-ethnographic qualitative data. Basically Vazquez has provided a light-weight sketch of an interpretive investigation, how to research the subjective aspects of product use.
The same questions are employed for product design, in particular for discovery and evaluation. These activities may go by different names; requirements engineering, feature design, and testing. They may be embedded within the various documents of a product project plan or design specification. They are however of such fundamental importance to good product design that we really should bring them to the front.
Don Norman's design framework in the Design of Everyday Things (1988) highlights the need for designers to focus on these 'jobs to be done' or 'in order tos'. These are equivalent to the question we ask users; 'what is the goal'? Norman elaborates further on two 'gulfs' between users' intention and what happens in the world. Designs must necessarily overcome these gulfs in order for the user to succeed in their intention. The designed object is the link between a user's goal and the world they are situated in. Execution refers to a designed object's capability to satisfy the user's goal. Evaluation refers to how a designed object responds or signifies state, essentially how feedback is presented to the user. 
Seven questions are posed for designer and user:
"
The goal question:
1. Forming the goal (Q: What do I want to accomplish?)
The gulf of execution involves 'discovery'. Users ask:
2. Forming the intention (Q: What are my alternatives?)
3. Specifying the action (Q: What can I do now?)
4. Executing the action (Q: How do I do it?)
The gulf of evaluation involves feedback. Users ask:
5. Perceiving the state of the world (Q: What happened?)
6. Interpreting the state of the world (Q: What does it mean?)
7. Evaluating the outcome (Q: Is this OK? Have I accomplished my goal?)
"
(p48 DOET and in Instructor Notes on Udacity)
"Good designers empathise with the people that they're designing for" Don Norman. The key concepts that designers employ (according to Norman) are the following:
  • Affordances
  • Signifiers
  • Conceptual model
  • System image
  • Discoverability 
  • Feedback

Exercise: Defining a system

Allocate approximately 5" for this exercise:

Ask each student to answer the following:
What do you define as a system?

Reflection:
In pairs discuss the definitions.
Whole class on whiteboard capture definitions.

Sunday, 6 September 2015

Try (ID research)

We consider techniques and strategies for prototyping and designing for interaction, user centred goal-driven scenarios.

TECHNIQUES FOR DESIGN AND TEST
Interaction designing is predicated on a belief in trial and error, using prototyping and mock-ups to test new design ideas. IDEO’s ‘Try’ cards suggest methods to inform design decisions as the development of a new product progresses. These methods or strategies focus on user input, feedback, and responses as they attempt to use a new technology to achieve some goal. The methods stimulate and simulate users’ experiences, feelings, and perceptions in ways that are quite often completely absent or ignored in traditional product design projects. Among these techniques ‘prototyping’ in all its various guises is particularly valued by both developers and users as they grapple with the challenge of designing interaction between user and technology (Moggridge, 2006).
Table: IDEO ‘Try’ techniques (IDEO, 2003)

TRY

Research MethodDescription
Behaviour SamplingSnapshot people’s activities at different times. How do pervasive products intrude in your lives?
Be Your CustomerWhat is it like to purchase your product? Actual experience of searching, buying, consuming, disposing.
BodystormingAct out scenarios with many people, using space, place, sequence, queues, etc. Test performance in context.
Empathy ToolsExperience the range of users capability for involvement under real conditions.
Experience PrototypeMock up a rough but workable prototype to simulate the experience of using the new product.
InformanceAct out scenarios observed in the field to interpret and analyse in the lab. Builds shared understanding and good for solution formation.
Paper PrototypingRapid paper based mock-ups that are manipulated to demonstrate functionality. To articulate design concepts with users.
Predict Next Year’s HeadlinesInvolve users in future design possibilities. Futuristic, wishing, unmet needs. Help separate what is needed now from what can wait.
Quick-and-Dirty PrototypingAssemble a very rough mock-up of a new feature or product to help start and refine a design.
Role-PlayingIdentify actors/stakeholders involved in design use, enact real activities in real or imagined context.
Scale ModellingSimulation technique to test arrangements of space, place, context.
ScenariosA character-rich story, to communicate (simulate) and test a plausible story in probable context.
Scenario TestingShow depictions of possible future scenarios. Share reactions, refine concepts.
Try it YourselfLike Microsoft’s famous ‘eating our own dog food’ being the first user.

PAPER PROTOTYPING
“Paper prototyping is a variation of usability testing where representative users perform realistic tasks by interacting with a paper version of the interface that is manipulated by a person 'playing computer,' who doesn’t explain how the interface is intended to work.” (Snyder, 2003)
One of the perpetual challenges of high tech systems development is the cost of up-front design. High tech products and services have highly intangible qualities across a number of dimensions; in terms of time to deliver, dependence on other technologies, flexibility of the realization (product), dependence on rare skills and expertise. High tech products and services are themselves highly virtualized constructs or dependent themselves on the features of intangible goods; source code through to compiled application is a digital media, brittle, and based on architectural concepts that are difficult to represent, interpret and understand. Consequently high tech systems are associated with large up-front development costs before the product is usable or even visible. Compounding the problem is the observation that over 90% of a digital good’s implementation is manifest in the arcane digital back-end consisting of software architecture and computing infrastructure. The most visible aspect of a high tech product, its interface and user interaction driven aspects are a small fraction of the overall implementation. The interface is also often the last aspect to be finished for a high tech system. This delay between the conceptual ‘idea’ of the system and its eventual implementation ends up compounding the risk of systems development projects because late changes to user and interaction interfaces often necessitate fundamental redesigns of the underlying back-end architecture. All of this can be avoided with early interaction design.

Paper prototyping is one of many techniques that can and should be employed as early as possible in the development process to trial and refine design ideas surrounding user interaction. Paper prototyping is a method for rapidly constructing product mock-ups that are manipulated by users (but managed by a ‘computer’) to demonstrate design concepts and raw functionality. Paper prototyping and associated techniques for mocking up a system prototype (Table below) are effective ways of simulating and articulating design concepts with users.
Table: Some visual prototyping tools for design (Snyder, 2003)

Some visual prototyping tools for design (Snyder, 2003)

MethodDescription
Paper PrototypingPaper based mock-ups that can be put together rapidly and are operated by users and manipulated to mimic expected computer response. Paper prototypes are used to simulate functionality and test design concepts with users.
CompositesAre static graphic mock-ups that give a realistic visual impression of what the final product may look like.
WireframesWireframes are layout templates, often created within visual programming environments using the GUI toolset. Wireframe templates are usually static but realistic, employing off-the-shelf widgets and GUI elements.
StoryboardsStoryboards are sequences of sketched views of the interface or images of the product in different states. Graphical depictions of product performance, usually flowcharting the click-flow of windows, dialogs and screen sequences.

Paper prototyping is used to ‘enact’ system walkthroughs, of either the whole product or a single feature. They help to identify user paths through the system and can highlight parts that aren’t usable, accessible or that don’t work as users expect them to. Paper prototyping enables fast feedback on technical requirements and the feasibility of different design concepts. A paper prototyping walkthrough session can use the following roles: computer, expert user, scribe, and facilitator. (Exhibit below) Usability tests and pilot tests are simply more elaborate walkthroughs, with progressively fewer in-place supports for users and progressively less flexibility in reconfiguring the simulation.

EXHIBIT: Paper prototyping walkthrough session roles (Snyder, 2003)
Computer. The person who organizes and manipulates all those bits of paper (may be more than one person).
Expert user. A product team member plays this role, performing the tasks as an expert (someone who understands the interface) would be expected to do. It’s not part of this role to make bizarre mistakes or other radical departures from the norm – leave that for the real users!
Scribe. This person writes down all the missing pieces, issues, and questions that come up. It’s not always the best use of time for the entire team to discuss each issue on the spot and come to a decision. The scribe makes a list so that these things can be addressed after the walkthrough. On small teams, the scribe role may be combined with any of the other roles.
Facilitator. Strictly speaking, a walkthrough doesn’t need a facilitator, although it doesn’t hurt to have a designated person lead the session and make sure it doesn’t digress too much. Whoever plans to facilitate the usability tests should attend some walkthroughs in preparation; walkthroughs are a great way to become familiar with the functionality and behavior of the interface. For new facilitators, it’s also an opportunity to practice.

REFERENCES

Self-checkout interactions

3rd generation self-checkout systems, Dundrum, 2010.