Design, Develop, Create

Friday 4 October 2024

PNP Arcade - an outlet for creators to self-publish print and play games

 Like the title says - PNP Arcade - an outlet for creators to self-publish print and play games. Some games are free to download, others are pay per download. PNP Arcade promotes a Game of the Week, New Games, lists of publishers, and also offers a wealth of support and guidance for new Game Designers, for crafting printable aligned components, cards, boards, on cardboard and plastic, and all the other gritty details of creating a board game of publishable quality. As PNP Arcade sets out on their mission page...

PNP Arcade is looking for games that are printer friendly and can be played with common game components. Games that play well remotely are great too!

Our selection of games are curated therefore not all submissions will be added to the site.

While we wish we could send a personal reply for each submission, we unfortunately cannot guarantee a response due to the number of submissions.

PNP Arcade does not accept games that utilize any form of AI generated art at this time.

Explore the catalogue from PNP Arcade's homepage www.pnparcade.com/



 

Thursday 26 September 2024

DataCamp 2024

Dear class. I am pleased to announce that we have been granted 6 months of unrestricted access to DataCamp for self-directed learning (not for credit). Please be aware, this access is an optional additional feature and not formally part of the MIS41020 course.

DataCamp supports self-directed learning to grow and develop your own special tech power.

The "Design Development Creativity (MIS41020)" group Academic subscription starts immediately and runs for 6 months only. This opens unlimited DataCamp Learn Basic access and DataCamp Workspace Starter access for the duration of the access period.

I encourage you to register and explore what DataCamp has on offer. DataCamp provides learning tracks supporting career roles such as Data Analyst, Data Engineer, Data Scientist. It also provides technology centred tracks for acquiring competence with tools like Python, SQL, R, Google Sheets, Excel, ChatGPT, OpenAI and much much more. (Note this access does not include DataCamp Certifications).

Wednesday 18 September 2024

Research Project

GENERAL GUIDELINES

0. Scope

The scope for this year's research project, the Game Design Evaluation, is outlined in the document linked here...
https://managingdesignanddevelopment.blogspot.com/2023/09/scope-for-term-paper-2023.html

1. Goal

To write up original methodological research in the style of an academic research article.
Study a product (see Scope above) using a small selection of product-design research methods chosen by you (but not surveys or questionnaires). You will apply a small number of empirical research methods to scrutinise an object or system that you have access to can interact with people who use it. Your aim is to better understand the use of the object. A secondary aim is to form an opinion on the efficacy of the chosen methods. You will generate data and findings applicable to the object (and methods).
Apply two or more chosen research methods (in addition to literature review): You will gather primary research data, applying chosen research methods empirically to technology objects, and their contexts and use situations. These activities are supported by literature review and secondary documentary data, for example scholarly articles etc. which support the main objective - conducting field research.


Tips on how to start this project...

Attempt to gather various kinds of data that you can analyse to make substantial inferences. Contrast your findings with those of other published studies (i.e. mentioned in your literature review).
  • Phrase your investigation as a question - the "Working Title".  Initially, phrase a research question as the title of the paper (you can change it later).
  • Identify an exemplary paper that you aspire to emulate or to compare your own paper with. 
  • Write a statement of intent: This will probably evolve into the 'abstract'. Restate and expand on the research question in the abstract (you can change it later when you have analysed your findings).
  • Consider Research Access: Do you have an interest in a particular product, or contacts in a company developing a product? Do you have access to a company that you would like to better understand or experience working on a project that would benefit from being studied like this?
A rubric for your proposal - ask yourself...
1. Wording of the Title stated as a question? 
2. Is/are the research target(s) identified? 
3. Is/are the research target(s) accessible? 
4. Are research methods stated? 
5. Are the research methods suited? 
6. Did you use the template? 

2. Deliverables: Term-paper plus video presentation

Term-paper: Paper May Not Exceed Ten Pages Including References. 
A 1-page Personal Reflection to be written and included as an appendix.
Appendices are not included in the page count limit.
Video presentation: The video presentation can give a concise overview of the subject matter and impact of your term-paper in a short video format (4-minute duration).
You are expected to create your own original narration and/or spoken audio content, similarly you should utilise as much of your own visual/graphical material as possible. You can of course utilise various elements sourced elsewhere (subject to licence) as background or linking pieces, e.g. diagrams, music etc. if needed as content or for artistic balance.
Grade deduction if the presentation/video has text-to-speech narration or uses 'canned animation.'
While not being graded separately from the term-paper, no presentation video results in losing half the available mark for the research project.

3. General pointer on writing...

The term paper is written in an academic style, presenting your background reading, method, research, analysis, theorising and critiquing aspects, for example of the history, situation, processes etc of a particular sourcing context. 
 
You must use the scientific conference template for the Hawaii International Conference on System Sciences (HICSS). Choose between either the LaTeX or Word template - copies of both are available on Google Drive, links below.

Most important! Please ensure that any direct use of 3rd party material (particularly internal documentation) is presented within quotation marks or boxed or otherwise marked in some way and with the appropriate citation/identification.

4. Structure of a typical journal style research paper

 Please note, this is not a rigid structure. The scope of your project may require you to adapt the names of sections and sub-sections as needed.
Title
The title and abstract should both capture the essence of the study.
Abstract 
Introduction / Literature (positioning)
Give a brief introduction to the literature and positioning for the study.
Research Design / Methods / Context
Outline your research protocol, approach etc.
Data / Findings
Tell the story, provide the evidence, findings, account or narrative.
Analysis / Discussion
Analysis and discussion allow you to draw out the significance of what you have discovered. This is where you can apply/trial various analytical models or produce your own interpretation of the data, in order to better understand the evidence.
Conclusions
Conclusions summarise the findings concisely, often in a page. This is an overall synthesis distilling your analysis and its relevance to theory and the literature.
Bibliography/References
The bibliography/reference section is crucial to get right as it is the index to prior research and literature that you have referred to previously.
Appendices (if needed)
Use appendices to provide additional detail if necessary. Usually data samples, or intermediate representations, for example a sample of the data analysis process, coding frames, stages in the coding and summary or intermediate categories from data.

5. Grading

Grading will consider the following criteria:
  1. The research project is clearly explained.
  2. Critical positioning in literature.
  3. Empirical work, data and evidence presented.
  4. Overall quality of the document as a finished product.
  5. Contributions are clear.

A brief explanation of letter grade descriptors is provided below.

Modular (letter) grades.

A+/A
  • The report is suitable for submitting to conference, journal, or executive with little revision.
  • There is a compelling logic to the report that reveals clear insight and understanding of the issues.
  • Analytical techniques used are appropriate and correctly deployed.
  • The analysis is convincing, complete and enables creative insight.
  • The report is written in a clear, lucid, thoughtful and integrated manner-with complete grammatical accuracy and appropriate transitions.
  • The report is complete and covers all important topics.
  • Appropriate significance is attached to the information presented.
  • Research gathered is summarised in some way, research and analytical methods described and discussed, evidence linked to argument and conclusions.
A-/B+
  • The report may be suitable for submitting to conference, journal, or executive if sections are revised and improved.
  • There is a clear logic to the report that reveals insight.
  • Analytical techniques used are appropriate and correctly deployed.
  • The analysis is convincing, complete and enables clear insight.
  • The report is written in a clear, lucid, and thoughtful manner-with a high degree of grammatical accuracy.
  • The report is complete and covers all important topics.
  • Appropriate significance is attached to the information presented.
B/B-
  • The report may be suitable as a discussion draft for further development or refinement.
  • There is a clear logic to the report.
  • Analytical techniques are deployed appropriately.
  • The analysis is clear and the authors draw clear, but not comprehensive conclusions for their analyses.
  • The report is written in a clear, lucid and thoughtful manner, with a good degree of grammatical accuracy.
  • The report is substantially complete, but an important aspect of the topic is not addressed.
  • The report may have used or presented some information in a way that was inappropriate. 
C
  • The report may be suitable as a preliminary draft but needs substantial revision in a number of areas to develop further.
  • The basic structure of the report is well organised but may need rebalancing.
  • The content of the report may be partial, incomplete or unfinished with important aspects not addressed.
  • The report used information that was substantially irrelevant, inappropriate or inappropriately deployed.
  • The report’s analysis is incomplete and authors fail to draw relevant conclusions.
  • The report may contain many errors in expression, grammar, spelling.
D/E
  • The report may appear to be preliminary, speculative, and/or substantially incomplete.
  • Whatever information provided is used inappropriately.
  • The structure of the report may be inappropriate or need substantial reorganisation and/or rebalancing.
  • There may be little analysis, evidence may not be founded, the findings may be inconclusive.
  • The report appears to frequently use information that is substantially irrelevant, inappropriate or inappropriately deployed.
  • The report may be poorly written, organised and presented.
  • Frequent errors of grammatical expression.

Monday 9 September 2024

Scope for the Term Paper

Game Design Evaluation

A design evaluation of an indie boardgame released at Spiel 22, Spiel 23, Spiel 24 e.g. see the Spiel website - SPIEL ESSEN - https://www.spiel-essen.de/en/  Each student to select a recent game published within the last 3 years. No mainstream games or videogames. Cross check the game details on BoardGameGeek BBG https://boardgamegeek.com/.

The term-paper will be a practical project based on your personal-plus-friends evaluation of an indie (independent/small company) board game as the 'whole product'. You will consider overall design, its playability, potential for improvement, its digital aspects or digital potential, and product variants such as expansions, spin-offs etc. 

Audience: Create a document that tells a story that people such as the designer, investor and publisher would benefit from learning about what you learnt by using and observing others using the product. It could be a useful input for a journalist to use in preparation for writing a product review.  Content and structure may include any/all of the following...

Pitch warm-up

---------

In a sentence “It’s like…”

Single player, multiplayer, puzzle, builder, collaborative, cooperative, competitive, open-world, sandbox etc?

Family/Adult, player age, number of players, time to play. Casual vs campaigning etc. 

Background research

----------

Inspiration? 

Genre?

Related titles in this genre? 

Published influences, related and similar titles (even, if you look for it, references in the game literature!!!!) 

Design structural elements

--------

Game design elements? Gamifications?

Outcomes? Win/lose? Display/sharing?

The application of emotion principles?

The application of the uncertainty principles?

Narrative backdrop constructed by the design

Narrative potential constructed by the players

Complexity, scope? Too much, too little?  

Developer perspective

------

Paper prototype or mock-ups?

Any playtest feedback?

Comment on ease to ‘onboard’ new players? Simple version, complex version. House rules.

Identified ideal player types, market segment? Appeals to who?

Market perspective

-------

Potential to adapt or expand, levels, extent, add-ons, expansions? Is it a platform.

Market size of equivalent or similar titles?

Route to market? (publisher, self-publish, Kickstarter, Gamefound, crowdfunded)

Packaging/presentation? (box, components, online, platforms) look and feel.

Countries/languages? Cultural fit. Suggest markets. 

Product Production: Value, costs, price, effort

--------

Price-point/Pricing? Cost to design/develop?

Cost to service/operate?

IP or licensing questions?

Potential to rebrand or repurpose the ‘engine’ to another genre?


Tuesday 27 August 2024

Software Engineering at Google


 

(copied from the abseil website - a project involving some of the authors of the SWE Book)

In March, 2020, we published a book titled “Software Engineering at Google” curated by Titus Winters, Tom Manshreck and Hyrum Wright.

The Software Engineering at Google book (“SWE Book”) is not about programming, per se, but about the engineering practices utilized at Google to make their codebase sustainable and healthy. (These practices are paramount for common infrastructural code such as Abseil.)

We are happy to announce that we are providing a digital version of this book in HTML free of charge. Of course, we encourage you to get yourself a hard copy from O’Reilly if you wish.

Click on the link below to access a HTML copy of the book.

https://abseil.io/resources/swe-book


Tuesday 5 December 2023

Research Writing - when to use 3rd Person or 1st Person

The question I'll try to answer here is; when can we use third person versus first person pronouns in research writing? Contrary to common understanding, the researcher is not always expected to erase themselves or be absent in research writing. Research writers may use both writing styles but should ensure the transition between them is appropriate and clearly signalled. For example, applied in different sections or introduced via a lede, a lead-in sentence or introducing paragraph.

The third person form (collective pronoun terms) is widely accepted as the main style for academic writing. This narrative form is used to present data, facts and findings in a factual and objective style but must not be misused to make exaggerated or unfounded claims. The third person form is highly appropriate for writing the literature review, critique, and analysis. The third person conveys truthfulness and facticity by presenting arguments, data and findings in a balanced objective manner. The construction of objectivity is highly valued and helps to convey and justify the deep trust we place in scientific writing. 

While third person narrative is the dominant style in academic writing, the use of first person voice ("I", "my", "we", "our" pronouns) in a research narrative may be appropriate when describing contexts and motivation. As the research writer, you, the author, are at the heart of a research account. You are the person who ties the various threads together, of research design, its conduct, the account of findings. 

When and why would you use a first person narrative? A first person perspective is inherently interesting and compelling (when it isn't indulgent), but more importantly, is probably more appropriate for describing the researcher's agency. What is researcher agency? Agency is evident in how the research design is arrived at, what research methods are chosen (and why), in how access is negotiated or gained, in devising protocols and analytical methods etc. Researcher agency is implicit (if not usually acknowledged) in devising, conducting and communicating research findings. It is therefore incredibly valuable for the research author to be reflexive. One way to do this is to draw back the curtain, to employ introspection to reveal the hand of the researcher and comment on the potential for omissions, biases etc. and the messy practical reality of research action. 

A final note. The target journal, publication or conference you publish your research in will usually have a house-style or provide guidelines on use of voice in the same way as it does for document template, citation style, number of citations etc.

Friday 24 November 2023

Exercise: Creative Problem Solving

robot, n. The word ‘robot’ was first used in Karel ÄŒapek’s play R.U.R. (Rossum's Universal Robots), a science fiction play in the Czech language in 1921.

This exercise simulates a creative-problem-setting-solving-setting etc in teams.
Objective: Understanding theory, principles and guidelines for group brainstorming sessions.

Materials
"Lego Mindstorms" Robot Base (1 per group of 4 to 7 people).
Creativity Assessment Sheet.
One hour to run.

Technology Familiarisation Stage
1. Introduce the robot and programming tools.
2. Allocate 7 minutes for individuals to take turns familiarising with the robot's capabilities.

Play Prototype then Try 
Part 1 
1. Turn the robots OFF.
2. Problem 1 is set.
3. Allocate approximately 3 minutes for initial exploration and solution working individually. Individuals working alone write a program to solve the problem on paper.
4. Allocate approximately 5 minutes for group discussion and determination of group program.
5. Robots can now be turned ON.
6. Allocate approximately 5 minutes to program the robots and 3 minutes for the teams to demonstrate.

Part 2
1. Turn the robots OFF.
2. Problem 2 is set.
3. Robots can now be turned ON.
4. Allocate approximately 15 minutes for groups to determine own approach to solve challenge.
5. Allocate approximately 5 minutes to program the robots and 3 minutes for the teams to demonstrate.

Reflection and discussion
Was leadership difficult?
Could you put yourself forward, could you step back?
How did the team feel?
How did the team perform? On the task, overall?
Comment on behaviours that reinforced or diverged.
Was failure evident? How often? Personalised or not?
If you feel you failed do you think you learned more or less than if you hadn't?
Comment on risk taking.
Comment on the workspace.
Describe your ideal workspace; what things would be present, how would space be arranged?
Are you an 'insider', an 'outsider'?
Was 'talk time' shared? If not who didn't speak and why? If not who spoke most and why?
Does physical control of the 'things' limit collaboration?
What behaviours enable collaboration?
What is your motivation?

Additional links
In defense of brainstorming by Scott Burkin, blog post (link)
My creative process workshop 2010 (link)
A student solution (link)
UCD-TCD Innovation Academy has a module on Creative Thinking (link); Also see the module "Inspiring Creative Thinking: Didactic methods in practice" (link)

Results

Class of 2012/13 
Group IDTest 1Test 2Test 3Test 4
aOK-OK-
bOKXOK-
cOKXOK-
e1/21/2OK-
f1/41/2OK-
g1/21/21/2-
hOK1/2OK-
iOKXOK-
jOK1/2OK-

Class of 2012 
Group IDTest 1Test 2Test 3Test 4
1OKXXX
2XX1/21/2
3OKOKXX
4XX1/21/2
5OKOKXX
6OKXXX
7XXX1/2
8OKOKXX

The blame is not for failure

Jørgen Vig Knudstorp: At LEGO, Growth and Culture Are Not Kid Stuff
"The blame is not for failure, it is for failing to help or ask for help"
Grant Freeland interviews Jørgen Vig Knudstorp (Boston Consulting Group video)


Exercise: Construction

DesignConstruction from Allen Higgins on Vimeo.

Preamble:


  1. Do the Lego Mindstorms familiarisation exercise first (see slides)
  2. Then have individuals make their own sketches of a lego robot that can guard a "base",

Objective:
To experience the different activities and issues that can arise in teams constructing a shared object in accordance with a well specified design.
To enable people to get to grips with a particular technology ecosystem to enable reasoned judgement and design thinking relevant to other related exercises.

Preparation:
1x copy of the design/construction document per group.
1x LM construction box.
Index cards, pencils, paper.

Instructions (45”):
e.g. A group race to construct a driving base.
Provide a brief introduction to the construction environment and capabilities of the tools used. 

Outputs:
A completed driving base.

Interjections:

  • At intervals team members have to 'rotate' around the workbench. 
  • About 15' into the exercise pause and reflect how they have ended up organising themselves. Would you choose a different arrangement? Roles? Spatial arrangement? Move things around? Leadership? Democratic?
  • About halfway to completion offer the colour booklet.
  • About 30' into the exercise pause and reflect. Ask 'what is the design? The guide? Which page? The finished product? The small details? The ideas? Did anyone notice errors? What was the impact of colour? Any improvisation? Coping with missing parts?

Debrief:


Class of 2014/15 FT 


Group ID
Time (mins)
a
1 hr 13'
b
non-finish


Class of 2013/14 PT 


Group ID
Time (mins)
a
24'
b
non-finish
c
29'
e
27'
f
non-finish
g
non-finish
h
non-finish
i
23'
j
non-finish


Class of 2013/14 FT 


Group ID
Time (mins)
a
non-finish
b
non-finish
c
non-finish
e
20'
f
non-finish
g
'1'? non-finish
h
non-finish
i
31'
j
non-finish

Class of 2012/13 
Group IDTime (mins)
a20
b35
c40
e29
fnon-finish
g42
h47
i40
j34

Class of 2012 
Group IDTime (mins)
1non-finish
2non-finish
333
440
533
625
728
834

I couldn't resist "Why Your Employees Should Be Playing With Lego Robots"

Arguing for play-like activity in work (not just using Lego to communicate ideas) by Colin Lewis...
"Participants from all backgrounds gain key team building skills through collaborating closely at every stage of ideation, innovation, deployment, evaluation and scaling. At the end of the training teams are required to present their ideas and results, building effective communication skills." (Lewis, 2014)

Monday 6 November 2023

Exercise: Battleship as a metaphor for Plans or Planning

This game may be all you'll ever need to know about project management :-)

You Lost! €-300.000

Exploring the relationship between action and plans, having a plan and planning, design and designing.(note: the game uses a dot "." separator for 'thousands' as per common usage in many countries)

The Rules of Planning Battleship
  • There are 5 ships hidden in the grid - one ship of size 2, two ships of size 3, one ship of size 4, and one ship of size 5.  
  • Reveal the ships by taking shots at grid coordinates.
  • Each shot costs 10.000.
  • You have a balance of 400.000 to spend on shots (i.e. equivalent to taking 40 shots).
  • Try to generate a positive return.
  • You only receive a payout if a whole ship is revealed. The payout is worth the ship size * 50,000.

Step 1: Design a pre-prepared plan of attack
Individuals produce one or more up-front plans using provided blank sheets.

Step 2a: Play Planning Battleship using the 40 shots per iteration game.
  1. Open the playable version of battleship on https://tech.zilverline.com/battleship/public/index.html
  2. Enter each of your pre-prepared plan of attacks.
  3. Record your results in the survey form (survey form here) - these will be numbers from 1 - 40 and values from -400000 and above that are multiples of 10000.
Step 2b: Play Planning Battleship using the 10 shots per iteration game.

Step 2c: Play Planning Battleship using the 1 shots per iteration game.

Step 2d: Play Planning Battleship using another number of shots per iteration game.

Step 3:
Look at the results (data spreadsheet here)


Discussion:
What is an 'iteration' with respect to the game?
When does it make sense to run a project without feedback?
What is the 'design' with respect to the game?
What is 'strategy'  ?
What is 'project planning' ?
What (if anything) might this exercise highlight for projects in general?
What is the maximum payout? *1
What is the maximum cash position possible? *2.


Acknowledgement to Zilver - Zilverblog The Power of Feedback in Scrum:
Zilverline developed this simple version of the Battleship game, written in Javascript, as a tool to explore ideas related to the design and development and dynamics of projects.
  • The difference between Plans and Planning
  • The value of feedback
  • Cost and reward
  • The size of an effort versus the payback in terms of information
  • The game-like nature of projects (like pinball, the goal is to play again?)
"Board layouts are random and you get 40 shots in total to destroy the enemy’s fleet. After each iteration you get feedback about hits and misses. If you use iterations of 1, you are playing the regular battleship-game. Each shot costs 10.000 and when you sink a ship you get the_ships_size * 50.000 (e.g. the submarine of size 3 will reward you with 150.000). If you keep track of the balance after each iteration, you could also try to get across the idea that stopping after a few iterations might give ‘good enough’ rewards."

The game can be downloaded from the GitHub repository as a zip or you can take a look at our code. Just double click on the index.html (in the public folder) to start a game.

Source code from Zilverline - https://github.com/zilverline/battleship

*1. Max payout from hits will be 5 ships of total size 17 * 50,000 = 850,000

*2.  Max cash position will be 1,080,000 (based on spending exactly 17 shots to gain 850000 and retaining 23 shots worth 230000, resulting in a retained profit of 1080000). Note that the game engine cannot be completed in this scenario.

Requirements (SDLC)

Part of successfully designing and maintaining a high tech system is having a strong top down vision. In the absence of vision nobody has a clear idea of what belongs and what doesn’t.
"It's really hard to design products by focus groups. A lot of times, people don't know what they want until you show it to them." Steve Jobs, quoted in BusinessWeek (25 May 1998) cross ref. (link)
THE USER AND REQUIREMENTS
Understanding the requirements process. An overview of the need for requirements and how they can be gathered and managed for systems development.
If you have a product or if the product is still just a concept you must be able to answer the question: “what goal does the user attain by using your ‘offering’ or product?”
INTRODUCTION
Why do we need to talk about requirements? Aren’t requirements usually self-evident? Are the really valuable requirements obvious or easily captured?

Product management needs to be grounded in a disciplined approach to managing high tech design and development. The product or project manager, right down to the programmer, must be able to answer the question "how do I know when I'm done?" However requirements may may not capture a clear or coherent statement of the problem we need to solve. Requirements can state outwardly perceived problems but in ways that are value laden and suggestive of remedies (perhaps as band-aids) rather than as simple statements of issues that could be addressed in . In these cases requirements encroach on design and may result in the worst aspects of incremental change. (Foote and Yoder, 2000).

Identifying the real problem is often the problem (Curtis et al., 1988). The requirements process is therefore more often a process of mutual discovery; uncovering and discovering the need and use for a high tech system.

Three simple questions offer a revealing insight into the maturity and capability of the organization:

  1. Show me a statement of the requirements your product delivers?
  2. How were the requirements gathered?
  3. From where does each requirement originate?
User requirements and analysis is often considered to be the starting point for the systems development process but it is rarely a straightforward process of transforming a list of requirements into a product. It is more often a process of intervention and change that impacts “personal and group efficiency, effectiveness, job satisfaction and the quality of working life.” (Mumford, 1985) Edith Mumford suggested that the best possible approach for design teams is to involve users with the developers as part of the requirements capture and design process. To create a situation where user requirements can be clarified and defined in the absence of solving underlying technological considerations. Requirements definition should therefore focus on user problems and needs before looking at current tasks. Identify the goals before looking at the minutia of the current list of tasks undertaken to overcome or satisfy the goals.


AN UNDERLYING THEORY OF REQUIREMENTS?
Why have a requirements process and what are its distinctive aspects? In an ideal world the developer and the user would communicate directly and perfectly. The user would be able to perfectly articulate some need, the developer would understand the need and be able to create and deliver it. However in the real world our understanding of needs and ability to communicate them is imperfect. In addition, in the real world, there isn’t a one to one correspondence between users and developers. A successful product may have hundreds, thousands, if not millions of users (Figure below, a). Conversely a product development team size may be anywhere between five and a hundred people (rarely more). The more users there are the less likely all their various needs can be articulated, communicated, implemented and satisfied. The more users there are the less likely the developers can interact and communicate with them on a one to one basis. The immediate role of an analyst may be quite simply to buffer or manage interaction and communication between users and developers.

The challenge of such a role is its potential to further distort the process of communicating between users and developers (Figure below). But simply adding an analyst to the equation doesn’t address the core challenge of large user communities interacting with small developer communities (Figure below, b). Consider the following three cases as ways of organizing interaction between users and developers. Case I (Figure below, I) corresponds to direct communication between developer and user, case II (Figure below, II) to the business analyst as a buffer between and two, and case III (Figure below, III) to open communication between developers and selected users. The solution to addressing large user communities is to select a representative subset of users and work with them (Figure below, c). As a general rule of thumb we could assume the number of representative users will be of the same size (or order or magnitude) as the size of the analyst/developer team (Figure below, d). The risk with a product requirements document is that it lies between the user and the designer; its use may both communicate and mis-communicate. The key to success is to selectively enable direct interaction to clarify and validate both the requirement and its delivery.

The ETHICS approach
There are many requirements management frameworks most of which are basically templates and checklists for gathering and recording a variety of user-oriented data. Mumford's ETHICS framework is a useful approach to organizing participative problem solving initiatives for systems development. The acronym is also intended to convey that an ethical orientation is also necessary to allow and enable the analyst to contribute to good systems design resulting in increasing “the positive factors and eliminate or reduce the negative factors” (Mumford, 1985) for user interest, effectiveness, job satisfaction and commitment. Mumford's ETHICS approach to structuring systems requirements specification consists of question challenges and resolving activities.

The risk however with a requirements gathering process cast in this format is that it can expand into an open-ended discovery of a range of problems that weren’t previously articulated. You quickly loose yourself in changing, evolving goals. This is amplified by users awareness of the coupling between requirements and design. They understand fully that implementation of new technology impacts and challenges the target organization. New IT alters the day-to-day organization of work, job satisfaction and corporate mission. Impacts and challenges may be both positive and negative thus Mumford’s emphasis on the ethical treatment of people. In this case changing people’s tasks and responsibilities is predicated (and made valid) on the basic assumption that the exercise is to produce changes that improve the conditions, effectiveness and satisfaction of work.


METHODS FOR GATHERING REQUIREMENTS
The end result of any process of requirements capture should be a body of raw data (interviews, statements, recordings, diagrams, images, documents, objects). The requirements are a distillation of that data as lists, categories and descriptions that are wherever possible, traceable back to its originator or source for validation.

Contemporary methods for gathering and managing requirements range from formal negotiated approaches like ETHICS to informal (though still negotiated) processes evident in newer Agile methods (Cockburn, 2002). New methods for organizing systems development such as Extreme Programming (Beck, 1999) and Scrum (Schwaber, 2004) create distinctive roles for the customer or product owner at the heart of the development process (Figure below). Kent Beck popularized the idea that a development team needs an ‘on-site customer.’ Ken Schafer asserts the need for a ‘Product Owner,’ someone who speaks for the customer authoritatively and with ownership. Scrum’s insistence on a product owner is essential as the process is driven by value and therefore it is crucial to identify the person who is responsible for the product’s ROI and who is therefore responsible and accountable for decisions such as what the requirement is and which requirement to deliver first. The ideas of an on-site customer and a product owner are designed to simplify the communication process between users and developers. However they say little if anything about how to choose the users, communicate or interact with them.

Interaction Design (IxD), which has grown in popularity among HCI/CHI designers, directly addresses the methodological challenge of gathering requirements from user communities. Interaction design positions the role of the interaction designer rather than ‘analyst’ as the central figure bridging the gaps between users and developers. A more open interpretation of the role of Analyst or Requirements Analyst is anyone who is involved in requirements gathering and analysis. Various business titles could be applied to the same role: Product Manager, Marketing Analyst, Researcher, Interaction Designer, etc.

Product requirements can be thought of as a rather unique kind of shopping list, a shopping list written by (more often on behalf of) the user, and written for (usually by) the developer to deliver (Figure above). Taking the analogy further the requirements shopping list is for a shop where the shelves are initially empty because the things the user wants haven’t been made yet. Alternatively there may be something on the shelf that approximates what the user wants but it’s not quite right and needs to be customized. To compound this seemingly odd situation we may also find that product requirements may be written (created) by someone who is neither the customer (user) nor the designer (developer). In this situation those charged with requirements capture have a lot of responsibility and power to influence the design process. Product requirements lie between the user and the designer and act as a communication device between the two. The requirements document is merely a representation of a potentially unbounded set of product requirements therefore the process used to create the representation is perhaps more significant that the document itself.

METHODS FOR ELICITING REQUIREMENTS
Methods for gathering requirements from user communities at the early stages of systems development will usually consist of research and data gathering methods that are more exploratory and interpretive that conditional/quantitative (Cooper et al., 2007). After all, you won't know what questions you need to ask or the relevant information until you have undergone a process of open-ended learning and discovery.

A similar categorization of methods attuned towards requirements gathering is presented by Moggridge (2006). Specific methods are indicated for specific situations. Observational and recording methods are indicated when requirements or needs are initially unknown, latent, unvocalised, or problems of physical ergonomics etc. Survey, focus groups and expert opinion are useful for situations where explicit opportunities exist. Conversely the research method may be indicated by the size of the group being addressed. Statistical techniques are essential for assessing large markets or populations of users. Interpretive methods allow the researcher identify and explore concrete cases of use and associated goals.

THE RISKS OF REQUIREMENTS PROCESSES
Requirements are distillations of information, selective presentations of potentially vast unbounded wish lists and issues. The person charged with requirements capture has the power to influence the design process and therefore has a responsibility to carefully record and preserve the data from which selection is based. Creating and managing requirements involves discriminating and selecting information. It carries an onus to be truthful, fair, accurate, factual and impartial. Research data should wherever possible be preserved and indexed so that requirements can be traced back and associated with the users or situations they were generated from.

The task of requirements gathering is all the more difficult because what is learnt was previously unknown or unarticulated. A requirement is often tentative and uncertain. Furthermore, the statement of a requirement does not necessarily equate with its solution. Requirements may be functional and concrete (the product does X, Y and Z) or they may be non-functional and abstract (the product is fast, easy to use, secure). Requirements capture demands a level of attention and rigor to data gathering, storage, management and presentation equivalent to that of academic research. Whenever possible data should be verifiable, traceable, reproducible, and useful. Raw data is the body of evidence and material necessary for reasoned decision-making in the design process. It is no coincidence therefore that many of the methods and techniques for gathering and analyzing data are derived from academic research methods. Among these research tools qualitative research methods have achieved particular prominence in the technology design community (Cooper, 2004, Cooper and Reimann, 2003, Moggridge, 2006).
The value of qualitative research techniques is that they both complement quantitative methods and enable access to information that is impossible to capture via quantitative approaches. More importantly, qualitative research methods involve the researcher analyst directly with the user community and open the possibility for gestalts and insights that quantitative assessment may overlook.

CASE: A vignette on the value of qualitative research (Cooper et al. 2007)
“In one particularly illustrative example, we were asked by a client to perform a user study for an entry-level consumer video-editing product for Windows users. An established developer of video editing and –authoring software, the client had used traditional market research techniques to identify a significant business opportunity in developing a product for people who owned a digital video camera and a computer but hadn’t connected the two yet.
In the field, we conducted interviews with a dozen users in the target market. Our first discovery was not surprising – that the people who did the most taping and had the strongest desire to share edited versions of their videos were parents. The second discovery, however, was quite startling. Of the 12 people whose homes we visited, only one person had successfully connected his video camera to his computer, and he had relied on the IT guy at work to set it up for him. One of the necessary preconditions of the success of the product was that people could actually get video onto their computers to edit, but at the time it was extremely difficult to get a FireWire or video capture card functioning properly on an Intel-based PC.
As a result of four days of research, we were able to help our client make a decision to put a hold on the product, which likely ended up saving them a considerable investment.” (Cooper et al., 2007)

CONCLUSIONS
Contemporary ideas of user-driven adaptation, technology-in-use, and situated use imply that high tech development efforts remain in a perpetually unfinished state. IT, ICT and high tech products more generally are constantly being adapted for use by developers as they observe or become aware of users exploring and adapting technology to fulfil their own needs. We might think of the process of modern product development as being in a kind of constant surveillance with the producer or developers receiving a steady stream of reports from the market place, to try to better understand everyday use as well as user driven innovation. This open-ended orientation to technology requires both developers and users to be agile, as each creates conditions of possibility for shifting the meaning and functions of technology. Such agile approaches assume that technology is typically not used in isolation but that it becomes embedded in users’ everyday practices and lives. These processes of appropriation are creative processes of identifying novel forms of use or shaping the conditions of use.

REFERENCES

Gathering and managing requirements

User requirements and analysis is often considered to be the starting point for the systems development process. There are many requirements management frameworks most of which are basically templates and checklists for gathering and recording a variety of user-oriented data.

Examples:
  • Atlassian's Confluence/Jira offers a sophisticated holistic model for capturing, storing, presenting requirements for future development. See this example from the Confluence/Jira tutorial (link).
  • A typical/conventional/traditional requirements document; source - a student engineering project (link)
hightechrequirements
A selection of typical requirements documents.
Some musings on requirements:
Product requirements can be thought of as a rather unique kind of shopping list; a shopping list written by (more often on behalf of) the user, and written for (usually by) the developer to deliver. Taking the analogy further; the requirements shopping list is for a shop where the shelves are initially empty because the things the user wants haven’t been made yet. Alternatively there may be something on the shelf that approximates what the user wants but it’s not quite right and needs to be customized. To compound this seemingly odd situation we may also find that product requirements may be written (created) by someone who is neither the customer (user) nor the designer (developer). In this situation those charged with requirements capture have a lot of responsibility and power to influence the design process. Product requirements lie between the user and the designer and act as a communication device between the two. The requirements document is merely a representation of a potentially unbounded set of product requirements therefore the process used to create the representation is perhaps more significant that the document itself.

Links of interest?
https://svpg.com/the-end-of-requirements/

Supporting Exercise?
Share a file or post a link to an example of an actual product requirements page or document. Note. Examples out there might be titled 'pitch' or 'design' (e.g. a game design document), rather than 'requirements' but the substance of the subject matter described in the document will be features, needs, constraints etc.

Friday 13 October 2023

Product (inc. Service) Design Resources

The Service Design Tools site is a wonderfully detailed collection of resources suited to evaluating user contexts, for helping you adopt a `design attitude'. The resource is supported by an on-going project aimed at bridging education, academic research and professional practices.

The design methods finder offers another possible source of inspiration for identifying research (and design) methods to apply to your own design research project.

The Nielsen Norman Group (Jakob Nielsen, Donald A. Norman, Bruce "Tog" Tognazzini) has been behind a sustained drive to professionalise high tech design by defining a new kind of occupation; Interaction Design.

This is Jakob Nielsen's site for sharing thoughts on the principles of interaction design, events and ID community material.

Bruce Tognazzini's site and his take on design principles.

Wednesday 11 October 2023

The Guindon Design Experiment

This experiment is an adaptation of the Spaghetti Cantilever Teambuilding Exercise. Organise into large and small groups (from 4 or 5 people to 8 or 9 people).
• Each group will employ a ‘thinking aloud’ protocol as they run the experiment.
• The cantilever designers should highlight key transitions or changes in their thinking about the problem.
One person will act as the researcher, capturing a time-record of the designers’ abstraction level and time at any moment. The researcher will make judgements about the abstraction level. The researcher is not allowed to take part in the design and construction.
• Change the person in the researcher role every 5 minutes to give all team members an opportunity to contribute to the cantilever design and construction.

Resources for 10 groups


Include the following observations on the ‘Design Activity Graph.’
• Scenario thinking
• Requirement thinking
• High level solution thinking/building
• Medium level solution thinking/building
• Low level solution thinking/building
• Key ideas.
• Testing or Review.

guindonActivityChart
Example of one group's design-construction activity chart

Spaghetti Cantilever Exercise
An exercise in design and coordination (adapted from Patrick Stacey’s boundary object seminar). This exercise resonates with Peter Skillman's 'Marshmallow Challenge.'

Allocate at approximately 1 hour to run this exercise. 10" setup and briefing. 30" experiment. 5" extra time. 15" debriefing.

You will need a large space with scattered desks to accommodate the exercise. Tiered lecture theaters are not suitable environments for this activity.

Aims
Practical Aim: Construct a cantilever extending from a surface, such as a table top.
Knowledge Aim: To assess the different activities people engage in open-ended problem solving.

Material
For construction each group is given a pack of spaghetti, a roll of tape, 2 sheets of A4 paper. Pens are for writing and not to be used in the structure!
Each group to be given a sheet of graph paper to capture the team's Guindon graph.
The tutor will need a timer and tape measure.

Competitive dimension/evaluation: Which group will construct the longest cantilever, - it must not touch the floor!
The tutor will need a measuring tape to measure and compare the length of the cantilevers.

Reflection
Ask each group to classify the activities they underwent (perhaps over 4 or 6 distinct kinds of activity)
Ask each group to estimate how much time they spent on each activity.
Ask the groups to reflect on how they won (or lost!) and to reflect on the contributions their different experience, backgrounds, disciplines made to the solution.
Were there collaboration problems? What boundary objects used to make sense of the challenge?
What evidence of design work is available (diagrams, prototypes, experimental trials)?

Class of 2019/20
Group IDTest 1Final Span (cm)
NinjaTurtlesOK86cm
Rogue1OK51cm
Rogue2OK43cm
DontDriveOK78cm
TeamTapeOK109cm
WaterslideOK75cm
FishingRodOK108cm


Class of 2013/14

Group IDTest 1Final Span (cm)
aOK72cm
bOK44cm
cOK64cm
eOK91cm
fOK64cm
gOK20cm
hOK52cm
xOK71cm




Class of 2013/14 FT

Group IDTest 1Final Span (cm)
aOK13cm
bOK10cm
cOK70cm
eOK46cm
fOK58cm
gOK67cm
hOK59cm
iOK62cm
jOK18cm, 18cm


Class of 2012/13 

Group IDTest 1Final Height
a3/456cm
bOK71cm
c1/2nil
e1/252cm
f1/481cm
g3/446cm (74cm)
hOK83cm
i1/483cm
j3/451cm

Guindon Design Experiment

Based on designing and building a cantilever beam using spaghetti and sticky tape.
Detailed protocol available at:
https://managingdesignanddevelopment.blogspot.com/2010/09/guindon-design-activities.html

Goal:

Develop an understanding of empirical design and development work as it unfolds over time.

Method:

The experiment will run for ~30 minutes.
At 1 minute marks check one or more activities you underwent in the last period from the following list:
5. "Scenario level"
4. "Requirement level"
3. "High level solution"
2. "Medium level solution"
1. "Low level solution"
0. "Key ideas (lightbulb moments)"

 Results:

At the end of the experiment take a photo of your cantilever experiment and post it to your socials. Potential tags...
"#designing #designprocess #designcollaboration #softwaredesign #digitalinnovation #guindondesignchallenge #thinking-aloud #researchmethods"

Discussion:

Reflect on your graph. Can you relate your findings to Raccoon's Chaos Model?

Guindon Design Notes:

In the late 1980s Raymonde Guindon designed an experiment to observe software designers at work while they were engaged in the process of creating a solution to a set problem. The software engineers, working individually, adopted a ‘thinking-aloud’ protocol and were observed directly by the researcher and videotaped for analysis.
As a consequence of these studies Guindon developed an understanding of design and development work as it unfolds over time; it is in fact a chaotic process of learning and reflection through trial and error. In essence the process of creating a solution to an ill-structured problem is itself un-structured, at least in the simplistic sense of being a planned, logical process moving from high level design to low level implementation in a smooth orderly manner. In fact the observations lead Guindon to the conclusion that software design work is largely underdetermined (Guindon, 1990).
“opportunistic decomposition is better suited to handle the ill-structuredness of design problems… top-down decomposition appears to be a special case for well-structured problems when the designer already knows the correct decomposition. .” (Guindon, 1990)

Guindon’s study demonstrated empirically that top-down design doesn’t occur as such in design work, or at least it doesn’t occur in a linear sequence from top to bottom. This has implications for lifecycles and frameworks that impose linear or staged phase structures based on the concept of top-down design-to-development processes.

Reference: Guindon, R. (1990) Designing the Design Process: Exploiting Opportunistic Thoughts. Human-Computer Interaction, 5, 305-344.