Design activity exercises

Results:

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).

#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

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:

• Heartbeat: from 2.40' into the video; Jonathan Ive's narration on the introduction to Apple Watch. See http://www.apple.com/watch/films/
• Force sensing: from 3.30'; recognising tap and press.
• The entire video continually emphasises the value of holistic integration of technology. Ive places huge emphasis on the aesthetics and the experience of using this device. How often does he mention the word 'expression'?
• On Kindle, "Amazon's new wireless reading device and the innovative things it can do". A conversation between Jeff Bezos (CEO Amazon) and Chris Anderson (editor in chief, Wired magazine) at BookExpo America 2008. See https://www.youtube.com/watch?v=kTM4pDdvqrU  On Kindle, "its ability to disappear, to get out of the way". Avoiding the risk of "breaking the reader out of 'flow'".
• The original iPod http://www.apple.com/pr/library/2001/10/23Apple-Presents-iPod.html 
• A video of the iPod launch event (link)
• Microsoft PixelSense http://www.microsoft.com/en-us/pixelsense/whatissurface.aspx

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. 

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).

Week 1 notes

MDD Week 01 2015

---

Notes from first week classes

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?

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?

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.

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 Method	Description
Behaviour Sampling	Snapshot people’s activities at different times. How do pervasive products intrude in your lives?
Be Your Customer	What is it like to purchase your product? Actual experience of searching, buying, consuming, disposing.
Bodystorming	Act out scenarios with many people, using space, place, sequence, queues, etc. Test performance in context.
Empathy Tools	Experience the range of users capability for involvement under real conditions.
Experience Prototype	Mock up a rough but workable prototype to simulate the experience of using the new product.
Informance	Act out scenarios observed in the field to interpret and analyse in the lab. Builds shared understanding and good for solution formation.
Paper Prototyping	Rapid paper based mock-ups that are manipulated to demonstrate functionality. To articulate design concepts with users.
Predict Next Year’s Headlines	Involve users in future design possibilities. Futuristic, wishing, unmet needs. Help separate what is needed now from what can wait.
Quick-and-Dirty Prototyping	Assemble a very rough mock-up of a new feature or product to help start and refine a design.
Role-Playing	Identify actors/stakeholders involved in design use, enact real activities in real or imagined context.
Scale Modelling	Simulation technique to test arrangements of space, place, context.
Scenarios	A character-rich story, to communicate (simulate) and test a plausible story in probable context.
Scenario Testing	Show depictions of possible future scenarios. Share reactions, refine concepts.
Try it Yourself	Like 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)

Method	Description
Paper Prototyping	Paper 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.
Composites	Are static graphic mock-ups that give a realistic visual impression of what the final product may look like.
Wireframes	Wireframes 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.
Storyboards	Storyboards 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.

Encountering Information Designs

Light switch in Schloss Münster building, University of Münster.

Sundial in the walled garden, Belfield House, UCD.

Learn (ID research)

USING PERSONAS AND GOALS
User involvement and use modeling is a key success factor for systems at both proposal stage and those undergoing on-going development. A major challenge however for any system of moderate size is that the active involvement of all users is quite simply infeasible. Productive user involvement is difficult to attain at any stage in the development life cycle. A practical enabling strategy is to choose a subset of users and involve them in the process. Another strategy is to model both archetypical and atypical users, using "personas". Model users termed personas are used to construct and direct the development effort (Cooper et al., 2007).
Model users called 'personas'. They are used to construct a cast of synthetic characters complete with values, personal histories, needs and goals. Personas are not average demographic 'types', they are individual characters whose biographical detail allows designers to 'imagine' the persona's individual aspirations, choices and behaviour as realistic, plausible, meaningful. It is simply another way for designers to generate empathy with their users. It enables them to build up a cast of characters, socialised and known among the design team, in order to focus the team's design attention, to enable and contain design ideation, development action, testing, user acceptance, etc.
A persona is employed as a shared sense making device, a fictional 'identity' or a character who is imagined in putative roles wherein some future version of the product is employed. These design strategies occupy the conceptual boundary between the design-world and the use-world. Each persona can be used to...

“Develop a precise description of our user and what he wishes to accomplish.” (Cooper, 2004) 

“Personas are not real people, but they are based on the behaviours and motivations of real people we have observed and represent them throughout the design process. They are composite archetypes based on behavioural data gathered from the many actual users encountered in ethnographic interviews.” (Cooper et al., 2007)

By modelling users, through personas and goals, systems developers establish a conceptual instrument for judging the validity and quality of the system and its detailed use-behaviour. Each persona (many may be constructed) has something to say about the system, its requirements and on-going evaluation. A persona may even be produced to explore non-use of the system.

The idea of a persona as an instrument and method has broad application and impacts the whole systems development lifecycle. In particular good use of a persona ensures that goal, feature, and functionality decisions will moderate and balance design decisions driven by the technology itself. Technology (or technologist) driven ‘user’ design decisions fall into three categories: the elastic user, self-referential design, and edge cases. All three categories distort the decision making process in favour of systems development rather than actual users. The creation and use of goal directed personas goes some way to overcoming the in-built biases of the development process.

Human-Centred Learning Techniques
IDEO’s ‘Learn’ cards suggest human-centred techniques and methods to analyze, interpret, present and judge the information gathered from ethnographic and other interpretive field studies. These methods and tools may also be applied to some kinds of quantitative data gathering.
Table: IDEO 'Learn' techniques (IDEO, 2003)

LEARN

Research Method	Description
Activity Analysis	A description of project relevant dynamics: actions, interactions, tasks, and objects of achieving goals.
Affinity Diagrams	Represent or diagram clustering of design elements with activities, goals, obstacles. Proximity, dependence and relationships
Anthropometric Analysis	Human factors or ergonomics to assess project relevant use factors.
Character Profiles	Personas. Archetypes of real people with real goals, lifestyle, behaviour, identities.
Cognitive Task Analysis	List, summary of all available sensory inputs decision points and actions.
Competitive Product Survey	Collect, compare, and conduct evaluations of extant and competitive products.
Cross-Cultural Comparisons	Personal accounts of differences in situations, behaviour and artefacts in different national or cultural settings.
Error Analysis	Capturing the things that actually go wrong in the project relevant setting.
Flow Analysis	The flow of information in existing and/or new system.
Historical Analysis	Identify trends and cycles of product use, customer behaviour, market, and practice. Relate to timeless goals
Long-Range Forecasts	Narratives of future scenarios complete with social and technological trends to predict behaviours.
Secondary Research	Summary analysis of existing sources and 3rd party data on project relevant areas.

A cast of personas can be gradually built up during the process of field study and gathering requirements. Afterwards as the data is analyzed and interpreted we construct personas that appear relevant to the project context. The cast of personas grows initially but will gradually be whittled down as duplicates and distinctive behaviour patterns are identified. Cooper et al. (2007) suggest differentiating user personas based on their different goals (motivations) and their behavioural attributes (Table below).
Table: Identify behavioural variables (Cooper et al. 2007)

Identify behavioural variables (Cooper et al. 2007)

Behavioural variable	Description
Activities	What the user does; frequency and volume.
Attitudes	How the user thinks about the product domain and technology.
Aptitudes	What education and training the user has; capability to learn.
Motivationss	Why the user is engaged in the product domain.
Skills	User capabilities related to the product domain and technology..

Cooper provides an example of how personas become part of the evaluation and decision making process of system design. The following discussion between the product owner (interaction designer) and the programmer deals with a persona named ‘Rosemary.’

Programmer: “What if the user wants to print this out?”
Interaction designer: “Rosemary isn’t interested in printing things out.”
Programmer: “But someone might want to print it.”
Interaction designer: “But we are designing for Rosemary, not for ‘someone.’”
(Cooper et al., 2007)

---

EXAMPLES: The following examples are from a number of personas developed for a project to develop a training product for a Telco billing system.

---

Telco systems administrator persona
Persona – Dave Taurus: Network Engineer
Industry Mobile Operator, Telco
Description
Network engineer - five years experience with Ericsson AXE and IN platforms
Responsible for configuration and maintenance of network elements
Switch database maintenance
Switch database interface guru
Hardware focused, resents the IT guys who are always sticking their noses in his switch database.
Skills
C, Sybase
Goals
1. Ensure 100% switch uptime.
2. Avoid anything that interferes with 1.
Tasks
Interface with switch manufacturer
Interface with internal business development people
Provide switch data definitions to the business/IT people
Provide access to switch data (FTP, file dumps)
Rollout new services
Occasional manual provisioning. Troubleshooting of provisioning problems.
Does not use any operational aspect of EPlus.
Will need to review event collection docs to check data transfer etc.

---

Telco billing consultant persona
Persona – Stephanie Billings: Background
Stephanie is 26, single and an occasional (when not travelling for work) member of the company soccer team. A bit of a lad when it comes to 'football', she's a die-hard ‘Latics’ supporter since the age of 6 when her dad started bringing her to matches. Doesn't give a toss for the Premier league - or won't until Oldham claw there way from 2nd division to 1st division to Premier...
Stephanie works as a consultant Java programmer for Accenture and is based in the Redding office. She calls the projects she works on 'gigs' and has a long list of humorous project disaster stories (though no companies are ever identified directly).
As a contractor all of Stephanie's time is accounted for, she has a personal revenue target and charges in detail down to the minute for every project she works on (even if she's back in the office doing internal stuff and not on a gig). She is a competent hardworking professional but is NOT interested in doing massive overtime (overtime is charged at time and a half, weekend work is double time).
She uses the Incode time tracker from OYOY on her Nokia 9210 Communicator to keep track of what she's doing and for billing clients.
Stef (as she is known to her friends) is passionate about JAVA and J2EE, considers herself a pretty hot JAVA programmer, highlight of her professional career to date was doing a joint presentation with Kari Kukkoaho (head of development, operations support at Nokia Networks OY) JAVAONE in San Francisco last year on OSS JAVA 3G Business Models for 3G Wireless Network. Has some product ideas about embedded JAVA and MIDP and might go off and do something about them some day.
GoalsStefanie was 'volunteered' to attend a 4 day programmer training course in the Dublin office to become a ‘certified mobile billing consultant’ because Accenture is getting primed for a project for client side implementation and integration of the EPlus billing service for a ‘major’ finance house in London.
Stefanie needs to fully understand any technology she is working on, expects all training to be an intense burst of information overload and will do a huge amount of preparation prior to the training, so wants access to all the information NOW (e.g. would like it presented like the JAVA Training Trails).
She wants to be perceived as the expert – has nightmares about not being able to answer a question, and in turn expects to be able to find answers quickly.
Training needs
Personalize training needs, expressed by questions like:
“where do I start?”
“how do I...?”
“where do I find...?”
“what do I do when...?”
“my work integrates with the rest of the team by...”

---

REFERENCES

Ask (ID)

"Developers must understand the application and the needs of users. It often takes a long-term relationship between users and developers, with a lot of dialog to uncover what users really need."
(Raccoon, 1995)

User participation must be part of software development.

RESPONDING TO SYSTEMS IN USE
IDEO’s ‘Ask’ methods (Table below)can be used to elicit feedback from users engaged ‘in use.’ These methods or strategies focus on user’s active participation interacting with a new technology to achieve their goals.
Table: IDEO ‘Ask’ techniques (IDEO, 2003)

ASK

Research Method	Description
Camera Journal	A written and visual diary of project relevant circumstances and activities.
Card Sort	Organise cards spatially in ways that make sense. To expose mental models of device or system.
Cognitive Maps	Create a map of an existing or virtual space. The pathways they know and navigate, mental models.
Collage	Self created collage of arranged images. Used to help verbalise complex or unvocalised themes.
Conceptual Landscape	Sketch and juxtapose social and behavioural constructs from participants. People’s mental model.
Cultural Probes	A visual journal for participants to build up themselves. A self generated reflection. Gathered and compared across many participants.
Draw the Experience	Ask participants to visualise and draw the experience in their own way, with their own associations, order, relationships, theories.
Extreme User Interviews	Evaluate (ask) users at extreme ends of market (early adopters, power users, beginners) to highlight their issues.
Five Whys?	Ask “why?” in response to five consecutive answers. Expose/uncover deeper attitudes perceptions.
Foreign Correspondents	Elicit inputs from others (snowball sample) to build up varied cultural and environmental contexts.
Narration	Users perform tasks and achieve goals while describing aloud. Talk aloud protocol. Stream of consciousness.
Surveys & Questionnaires	Targeted questions to assess design, usage, interaction characterises and perceptions of users.
Unfocus Group	Gather a range of tools or materials and get diverse user group to create things relevant to the design or project.
Word-Concept Association	Users associate words with design. Cluster user perceptions to evaluate design features & concepts. Value and priority.

What is the relevance of considering information elicitation at such at late stage in high tech systems development as implied by including the ‘Ask’ methods here in a discussion of ‘Maintenance’? The point is twofold, the first is to underscore that the nuanced view of the SDLC presented in these chapters emphasizes the interrelatedness of the various activities, phases or stages of the SDLC. The second reason is to acknowledge that for many users the release and delivery of the product is their first use of the product/system and therefore the first opportunity we have to learn how they got on. As the system is live there must be mechanisms for their experience, particularly the problems they encounter, to be recorded and directed back towards the product development initiative. Consequently, even a high tech system in maintenance mode but still used presents valid and valuable learning for future versions or future systems. In a real sense the SDLC entails doing everything at once, all activities from initial concept, through to design, development and maintenance will be in play at the same time, although to greater or lesser extent depending on the situation.

In particular, for maintenance and support, it may be productive if instead of casting support activities as outwardly assistive, to do as IDEO suggest and ask the people at the centre of your work (users and customers) to help you: ‘Ask them to help.’

Look (ID research)

TOOLS AND TECHNIQUES; SEARCHING FOR INFORMATION AND INSIGHT
Interpretive research methods often pose considerable challenges for the systems analyst and interaction designing. Knowing what to look for, to ask, to observe and record is hard enough. Knowing how to analyze, categorize, distill and present complex, entangled, messy qualitative data is also a challenge.

The IDEO method cards are an aide, to help break the impasse if the analyst gets stuck deciding what method to use or adapt for field studies and requirements gathering (IDEO, 2003). IDEO’s method cards are grouped into four categories: Learn, Look, Ask, and Try. Observational techniques are suggested by the Look category. The objective in this case is the uncover insights and understanding into what users actually do as they go about achieving their goals. The following table summarizes the Look category (Table below).
Table: IDEO 'Look' techniques (IDEO, 2003)

LOOK

Research Method	Description
A Day in the Life	Catalogue a person’s whole day without necessarily focusing on project relevant aspects.
Behavioural Archaeology	Look at use, wear, the detailed arrangement or organisation of use objects in their use setting.
Behavioural Mapping	Map position, movement, and use of space over time.
Fly on the Wall	Observe in context without interfering.
Guided Tours	Ask the user to guide you through project relevant spaces and activities.
Personal Inventory	Ask the user to reflect on and describe the things they view as important or significant
Rapid Ethnography	Participate and experience it first-hand with the user for as long as possible.
Shadowing	Tag-along with people through the day.
Social Network Mapping	Notice the relationships between people, groups. Look for identity, profession, culture, and connections.
Still Photo Survey	Build up a visual record of key use and interaction moments over time.
Time-Lapse Video	A way of summarising activity over time, use of time, space, and location.

The cards are used as prompts for researchers involved in field studies. They also provide a shared language for research teams and their customers (users, designers, developers) undergoing the process of designing research protocols for fieldwork.

Constructing System Descriptions...

There are many methods and tools proffered as system frameworks and aides for the job of gathering information and constructing system descriptions. The following approaches are helpful approaches for describing the more or less complex organisational, inter-organisational, market, and social relationships of technologies and their working contexts.

Organigraphs for Describing Organizations
Organigraphs are a tool for drawing and representing the relationships and activities of an organisation. They are an alternative to organisational charts as a tool for mapping an organisational relationships and interactions.
They can be treated as an antidote in some respects to the traditional organisational chart, instead of the familiar hierarchical view depicting names, titles and formal lines of authority.

“Organigraphs have been able to demonstrate how a place works, depicting critical interactions among people, products, and information. …to stimulate conversations about how best to manage their operations and which strategic options make the most sense,” (Mintzberg and Van der Heyden, 1999)

Organigraphs are a view of the organisation that can be more aligned with its activities and their interrelationships or workflows. Activities and functions could be thought of as the organs and muscles of an organisation. The act of redrawing the system of the organisation in this way offers a lexicon for represent and redefining organisational action. It offers an approach for analysts to elicit and generate “new vocabulary, and associated pictures... [to bring] choices into high relief.” (Mintzberg and Van der Heyden, 1999)

The Organigraph Palette consists of: People, Products, and Information (Figure below). Different actors internal and external to the organisation are included. The boundary of the system is loosely defined; in fact the value of depicting organization in this style is that the boundary can be redrawn and rethought.

Basic Organigraph graphical elements and simple example applied to a newspaper publisher

The ‘ecology’ of the organization, its products and the environment within which they exist can be highlighted. Furthermore these views depicts people (as individuals, teams, or divisions), products (things, services), and information, equally. There are three basic representations; chains, hubs and webs. Typically nodes will be people or products and arcs or connections will be product movement, transformation or information. The following example illustrates the multiple ways we may represent the product development and support function in an IT organization (figure below).

Three different representations of customer interaction with the organisation

There are no ‘right’ organigraphs, just those that are more or less useful. Remember, the different organisational metaphors are simply useful ways of thinking about organisation. As an analytical approach this kind of organisational mapping can draw out and juxtapose the various connections and flows. It highlights sequential, radial and web-like relations. They allow us the opportunity to redesign the relations, or highlight them so they can be better understood and supported. The graph provides a system-like view of the organisation in its environment and the activity focus within the organisation and for actors outside the organisation.

Activity Theory as a System for Describing Systems
Activity Theory has been employed as a descriptive theoretical framework to assist systems development, for eliciting and refining requirements with the goal of developing prototypes through to new technology in live user settings. It was adapted to analyse user situations and needs when cooperative work settings are reconfigured with computer support. It has strong theoretical constructs, an iconic structure, it focuses on the individual within organisations and society, and its primary unit of analysis is activity. Activity Theory includes the actors and objects involved in the process of someone transforming something into something else. This is the key process of development where the new product embodies or signifies new meaning for a wider community of others (e.g. customers, other members of the organisation). The approach has also been drawn on as a theoretical foundation to design methods like Interaction Design and Participatory Design (Moggridge, 2006, Cooper, 2004, Cooper et al., 2007, Kaptelinin and Nardi, 2006). Researchers have also used it to look at organisational interaction specifically in the contexts of seeking to attain new outcomes in the wider environment. As such activity theory can be used when we attempt to manage the development or intervention in mid-range systems, to innovate social, organizational, and technological processes. It provides a conceptual framework for making sense of how organisational actors can or should go about taking action in situations of changing requirements in dynamic market environments.

The generic Activity Theory dimensions for describing resources affecting change in any setting.

HUMAN SYSTEMS
Human behaviour in groups has proved difficult to manage well using classical scientific methods. Human behaviour is intrinsically complex and revisable. Social phenomena , purposeful systems (Ackoff, 1971), are the edge cases for scientific enquiry (Checkland, 1981). Checkland describes four classes of systems: natural, designed physical, designed abstract, and human activity systems. In spite of the elusive and changing character of purposeful human systems there remains much we can do when acting mindfully in settings to develop new technology and systems.

This issue of boundary setting and description dogged early attempts to construct detailed models of physical processes (e.g. in biology, materials, etc) and led to the idea of closed and open systems. ‘Systems thinking’ is presented as a systematic approach to thinking about ‘wholes’ rather than simplified reductions. By thinking holistically ‘systems thinking’ makes explicit the role of the problem describer (not necessarily the problem setter) as both observer and as an agent actively involved in articulating and refining the problem statements. There are, potentially, many relevant aspects of human activity systems that remain unknown or may be ignored based on how the object of concern and its environment are understood. For example, we generally assume that the outputs (products) of an organization are its primary means for acting in its market or operating environment. However there exist multiple other avenues that are often overlooked: welfare effects from corporate profits, political actions in industry and public forums, marketing, word-of-mouth, ethical and wider corporate governance etc.

The challenge for defining and describing product systems when humans are involved is in determining what we should include (and exclude) from analysis, and therefore, what is understood as relevant ! In essence the description of a complex real world system we be inevitably incomplete. Quantitative models of human activity systems become increasingly sensitive to initial conditions and are vulnerable to unknown factors, in large measure due to “the messy richness of ‘biological effects’” (Checkland, 1981). The problem of complexity is compounded in social studies and organizational behaviour because the social environment and its conditions of possibility are themselves social constructions; where a social construction can be understood as an on-going process of participation in collective sense-making (Giddens, 1984). Therefore, in human systems (organisations, markets, culture, society) – the subject matter for management, engineering and social science – working hypotheses, laws and generalities may hold for periods of time, but they remain open to revision and reinvention. The added complexity of social processes in society, markets, and organisations, and associated problems we hope to resolve, may often work against the rationality of scientific or engineered solutions (experimentation, observation, reduction).

REFERENCES

Case studies of Interaction Design

These links offer a starting point for those of you seeking exemplary models for your own research projects, or better, considering empirical research outlets for your own case studies...

Note, the following eJournals will typically keep articles behind paywalls, therefore use the UCD library pages to access (login in to UCD Connect).

Behaviour & Information Technology often carries articles describing new products developed for users, novel user interfaces and information systems (link).

Science, Technology & Human Values (link)

Information Systems Management (link)

A index of journals that include publication of similar case studies, as indexed at HCI and Interaction Design dot Org (www.interaction-design.org)

Have a look at this site with its examples of advanced and often speculative cases of new design or re-imagined systems interaction; from the Copenhagen Institute (link).

Finding your way around the blog?

How do I find my way around the blog?
The syllabus sets out the structure of the course.
Use the navigation elements along the top bar of the blog.
Archive lists on the RHS for example depict the time of publication of blog posts.

Introduction to systems development

This course reviews management perspectives on developing high-tech digital technologies and their characteristics. We discuss the implications for projects and work: organisational processes, methods, technique, tools and practice.

MANAGING SYSTEMS DEVELOPMENT
The innovation engine of an ICT-enable organization is its capacity to configure, construct, create, develop, deploy and maintain high tech systems. However, the collaborative production and delivery of robust systems presents significant challenges and team issues. An understanding of the tools and techniques used by professionals is therefore essential for managers who supervise systems developers or liaise with them during innovation projects. For each era and moment in the history of high tech development there is an associated technical backdrop representing the acme of infrastructure, technology and tools. The technical infrastructure is mirrored in turn by a social infrastructure – specialist knowledge, norms for communication, professional identity, behaviour, and expectations for teams. It is fruitful therefore to learn about the spectrum of current practices and apply theory to (critically) evaluate and subsequently adapt or formulate new processes, activities, and practices necessary for development in the situations we encounter ourselves; thereby better understanding and acting effectively in settings of high tech use-production.

How should a manager, software architect, designer, programmer, team lead or product manager,act to organize and manage high tech systems development projects? My goal is to help form answers to this and to the following questions:

• What management techniques, practices, lifecycles and frameworks are applied in contemporary systems development projects?
• How might we integrate the diverse concepts and theories of software systems development, and translate these concepts into personal, team, and management practice?
• How is value generated and delivered in real situations?
• What is the significance of new engineering approaches, from agile and lean methods to more functional approaches like CMMI and RUP?
• How do lifecycles and methodologies balance the tension between a necessity for orderly production and quick responses to changing contexts?

The material covered includes current and emerging organizational/management approaches to development include: lifecycles like SDLC, Waterfall, Spiral; frameworks like CMMI, RUP, ISO 9001; and approaches termed ‘agile’ like XP, Scrum, and Lean Production. The key goal that these software production and systems development lifecycles address is how to create digital media, although they attach differing importance to the need for various system artifacts (design diagrams, code, documentation, issues, etc.).

The overarching objective for us here it is to explore how the generation of any or all system artifacts is produced by underlying social interactions such as joint development, peer review, user involvement, automated testing, use assurance. Consequently system development’s process and its context is itself a kind of social structure for managing production (in the development team) and users. Power is an essential and underlying concept in order to understand the 'assumed' orderly underlying social interactions of programming teams and others they need to deal with in order to 'get the work done'.

Why do we need to think about the processes and structures used for developing high tech products and services? It is true that the emphasis on organizing high tech production has shifted focus from gifted individuals to being a team-based mode of production if not a team-of-teams in case of large-scale infrastructural architectures. Engineers do not start and complete whole projects overnight. Producing value takes time, effort and many small instances of failure and learning to create viable systems. It takes time, people and other technologies to produce these things. Managing the process involves making trade-offs between the ordering of events and activities over time, access to other complex systems (software, tools, work techniques) and the services of other actors. Importantly the very idea of a system implies ‘use’ and modern innovation processes are increasingly reliant on lead user involvement to establish both how the system is used and consequently how it is designed (Von Hippel, 2005).

Positioning the role: managing high-tech production
What does a manager need to know about the IT function in order to manage it? The manager of the IT function needs to know how to go about producing the product, and also, how to go about producing users. However, rather than relegating ‘use’ to a phase of implementation and delivery at the end of the systems production cycle, ‘use’ and ‘users’ have become intrinsic to driving the development process. The following highlights ways of producing, delivering and servicing our demands for ICT, IT and high tech goods. We don’t need to be engineers to manage the process, but we do need to be technology savvy and know enough to make a difference; how to bring technology, business and users together. The technology manager’s role is to bridge the two communities of production and use, to translate, interpret and make sense of the gaps between the technological and customer worlds (Figure below).

Roles translating between technological and customer worlds.

From Scrapbook Photos