This document summarizes an approach for streamlining the design process called "Racing with the Clock". It involves forming teams, setting a design task, doing a 5-minute design session, and then showing and testing designs within strict time limits over two hours. Participants found value in seeing other designs, having artifacts to refer to later, and the collaborative nature. Developers were surprised by the number of ideas generated. The approach works best with facilitation, time pressure, and structured activities to provide feedback at different stages of the design process within a limited time frame.
The document describes an experiment called the "4-hour Tester Experiment" which aimed to teach testing skills to beginners in a short time period. The experiment involved selecting key testing skills and developing brief exercises to teach each skill in 30 minutes or less. Four beginners participated in five exercises over 50 minutes total. Feedback indicated the exercises were challenging yet achievable in the time given and helped illuminate the targeted skills. However, the experiment confirmed that one cannot become a full tester in only four hours and highlighted the need for continuous learning.
The document discusses how to fit user research, sketching, wireframing, mockups, prototyping, specification, and usability testing into a two-week sprint using agile UX practices. It recommends three tools: design workshops that get users, developers, QA, and product managers sketching and discussing ideas together; agile usability testing every six weeks where the whole team watches and provides feedback; and incorporating user feedback into the process. Using these techniques allows a team to do just enough UX work to have great results within tight sprint timelines.
The document provides guidance on tackling dissertation writer's block in 3 main points:
1) It outlines an 8 month writing plan structured in 2 week cycles where each cycle focuses on a section, analysis, draft, review, and rewrite.
2) It emphasizes the importance of reviewing what others have done to avoid wasting time and ensure expectations are met. Peer review and feedback is a key part of the process.
3) The last two months are focused on completing the remaining sections of the chapter such as definitions, limitations, significance, and summary. Regular writing and review cycles are recommended.
Featherweight Design Sprints: How to tame a feature-sized problem in 4 hoursNathalie Baudrand
This is a poster I presented at UXPA International 2017. It articulates a modified design sprint method that I have used successfully at Veracode. The method allows for cross-functional collaboration in both the discovery and design phases but is lower cost than a traditional design sprint.
A presentation on design thinking and the design process. Design thinking is generally defined as an analytic and creative process that engages a person or group in opportunities to experiment, create and prototype, gather feedback, and redesign. The process is fluid and can go back and forward many times. Redefining of the problem, redesigning the solution(s) throughout the process will happen numerous times.
This document provides instructions for teams to complete various tasks as part of a group project. It outlines the materials needed, encourages positive participation from all members, and details the steps to construct and test a tool. The teams are instructed to illustrate their final product, conduct analysis, and create a presentation documenting their process and results. Tasks are divided among group members and remaining supplies must be returned by the deadline.
This document discusses different aspects of the design process. It describes both the traditional engineering design (TED) process and concurrent engineering design (CED) process. The TED process is linear with individual designers passing the product between stages. The CED process uses a team approach where all members work together throughout ideation, refinement, and implementation phases accessing a shared computer database. CED allows for continuous improvements and overlaps the different stages, reducing time and costs compared to the traditional sequential approach.
The document describes an experiment called the "4-hour Tester Experiment" which aimed to teach testing skills to beginners in a short time period. The experiment involved selecting key testing skills and developing brief exercises to teach each skill in 30 minutes or less. Four beginners participated in five exercises over 50 minutes total. Feedback indicated the exercises were challenging yet achievable in the time given and helped illuminate the targeted skills. However, the experiment confirmed that one cannot become a full tester in only four hours and highlighted the need for continuous learning.
The document discusses how to fit user research, sketching, wireframing, mockups, prototyping, specification, and usability testing into a two-week sprint using agile UX practices. It recommends three tools: design workshops that get users, developers, QA, and product managers sketching and discussing ideas together; agile usability testing every six weeks where the whole team watches and provides feedback; and incorporating user feedback into the process. Using these techniques allows a team to do just enough UX work to have great results within tight sprint timelines.
The document provides guidance on tackling dissertation writer's block in 3 main points:
1) It outlines an 8 month writing plan structured in 2 week cycles where each cycle focuses on a section, analysis, draft, review, and rewrite.
2) It emphasizes the importance of reviewing what others have done to avoid wasting time and ensure expectations are met. Peer review and feedback is a key part of the process.
3) The last two months are focused on completing the remaining sections of the chapter such as definitions, limitations, significance, and summary. Regular writing and review cycles are recommended.
Featherweight Design Sprints: How to tame a feature-sized problem in 4 hoursNathalie Baudrand
This is a poster I presented at UXPA International 2017. It articulates a modified design sprint method that I have used successfully at Veracode. The method allows for cross-functional collaboration in both the discovery and design phases but is lower cost than a traditional design sprint.
A presentation on design thinking and the design process. Design thinking is generally defined as an analytic and creative process that engages a person or group in opportunities to experiment, create and prototype, gather feedback, and redesign. The process is fluid and can go back and forward many times. Redefining of the problem, redesigning the solution(s) throughout the process will happen numerous times.
This document provides instructions for teams to complete various tasks as part of a group project. It outlines the materials needed, encourages positive participation from all members, and details the steps to construct and test a tool. The teams are instructed to illustrate their final product, conduct analysis, and create a presentation documenting their process and results. Tasks are divided among group members and remaining supplies must be returned by the deadline.
This document discusses different aspects of the design process. It describes both the traditional engineering design (TED) process and concurrent engineering design (CED) process. The TED process is linear with individual designers passing the product between stages. The CED process uses a team approach where all members work together throughout ideation, refinement, and implementation phases accessing a shared computer database. CED allows for continuous improvements and overlaps the different stages, reducing time and costs compared to the traditional sequential approach.
MeCC: Memory Comparison-based Code Clone Detector영범 정
The document describes MeCC, a memory comparison-based code clone detector. MeCC estimates program semantics by analyzing programs statically to produce abstract memories. Abstract memories map abstract addresses to abstract values. MeCC detects clones by comparing abstract memories and identifying similarities. This allows MeCC to find semantic clones that are syntactically different but have identical behaviors, such as clones involving control replacements, capturing procedural effects, or more complex transformations.
The document discusses Bret Lockett's claims of having a five-month affair with Kim Kardashian while she was engaged to Kris Humphries. It summarizes the person's search on Radaris to find out more about Bret Lockett, finding photos of him, his relatives and residences, as well as comprehensive news stories about the scandal with Kardashian. The person concludes that Radaris provides more comprehensive information on one page than multiple Google searches.
Player owns and guides a small town near a railroad through building construction, transportation development, and hosting festivals and events to please the town's residents, or townies, who provide quests and hints to further expand the town.
This document discusses Turkish meals and cultural events. It mentions breakfast foods and avoiding refusing second helpings to not insult hosts. Several religious and secular holidays and festivals are noted including Muharrem, Ramadan, and SekerBayrami.
Changing the nature of nature in policy and decision making ruralfringe
This document outlines challenges in current nature policy and decision-making. It argues that nature is often seen as a constraint rather than an asset, and economic models do not adequately value ecosystem services. Evidence used in policymaking focuses too narrowly, and nature is associated only with iconic places and species. The speaker advocates revaluing nature by integrating it into development and assessing impacts using tools like ecosystem services analysis. This can help move nature from being a disconnected afterthought to an integrated asset that maximizes benefits for both environment and humans. Key is measuring nature's intrinsic value, overcoming silos, and recognizing growth and nature can work together rather than opposition.
Critique is a type of structured feedback that examines what works and doesn't work in a design from the perspective of the audience and goals. It should provide specific, actionable feedback. Incorporating critique into the design process provides benefits like new ideas, improved communication skills, and collaboration. Critiques can be done internally at different stages of a project or with clients. They work best with 3-6 diverse participants and last 30-60 minutes. Ground rules and clear goals help critiques run effectively. With practice, critique is a skill that can improve design work.
This document outlines a presentation on design and the design process. It includes:
- An agenda covering design, UI/UX, and a 5-step design process
- Exercises walking through each step of the process using a hypothetical synthesizer redesign as an example
- Recaps summarizing the key points about kickoff, research, design brief, ideation, evaluation, and presentation.
In the fall of 2018, I was asked to present a guest lecture to first year students enrolled in the Business Technology Management program at Ryerson University.
A design sprint is a five-phase framework that helps answer critical business questions through rapid prototyping and user testing. Sprints let your team reach clearly defined goals and deliverables and gain key learnings, quickly. The process helps spark innovation, encourage user-centered thinking, align your team under a shared vision, and get you to product launch faster.
Explaining design critiques, their importance and outlining our approach at incorporating them into everyday work for a distributed team working across different projects in different sectors.
Why Can't We All Just Get Along? Improving Designer/Developer CollaborationAllison Corbett
This document discusses improving collaboration between designers and developers on agile teams. It begins by debunking common myths that designers and developers have about each other. It then provides tips for improving the collaboration process, such as getting design work done before development starts and using tools like sketching, paper prototypes, and wireframes. The document concludes with tips for designers, developers, product owners, and scrum masters to foster collaboration, such as involving all roles in requirements gathering, providing constructive feedback, and maintaining respect.
Research Proposal B06 Cognitive Conflicts 4269861David J Mooney
The document reports on a study that analyzed how design teams cope with different types of conflicts (cognitive, affective, process) throughout the different phases of the design process. Five teams of five students each were asked to complete a small design task going through the phases of analysis, synthesis, simulation, evaluation, and decision. They reported conflicts during each phase. The results showed that the amount and type of conflicts varied significantly depending on the design phase, with cognitive conflicts dominating in later phases as the importance of the group increased. The study provides evidence that conflicts develop differently in each phase of the design process.
Crystal Clear is an agile software development methodology created by Alistair Cockburn. It focuses on 7 properties: frequent delivery, reflective improvement, osmotic communication, personal safety, focus, easy access to expert users, and an automated testing environment. The development process in Crystal Clear involves several cycles including the project cycle, delivery cycle, iteration cycle, daily cycle, integration cycle, and development episode. It emphasizes frequent delivery to users, reflection and improvement, collaboration through open communication, and an environment that allows developers to focus on their work.
The document outlines seven "deadly sins" that can undermine the effectiveness of software reviews: lack of understanding of the review process, personal criticism rather than focusing on the product, lack of planning for reviews, problem-solving during reviews rather than finding defects, inadequate preparation by reviewers, involvement of the wrong people in reviews, and focus on style rather than substance. It provides symptoms of each problem and recommends solutions such as training, emphasizing peer review of the product not the author, explicit planning of reviews, moderating discussions, ensuring preparation time, appropriate composition of review teams, and establishing coding standards.
MeCC: Memory Comparison-based Code Clone Detector영범 정
The document describes MeCC, a memory comparison-based code clone detector. MeCC estimates program semantics by analyzing programs statically to produce abstract memories. Abstract memories map abstract addresses to abstract values. MeCC detects clones by comparing abstract memories and identifying similarities. This allows MeCC to find semantic clones that are syntactically different but have identical behaviors, such as clones involving control replacements, capturing procedural effects, or more complex transformations.
The document discusses Bret Lockett's claims of having a five-month affair with Kim Kardashian while she was engaged to Kris Humphries. It summarizes the person's search on Radaris to find out more about Bret Lockett, finding photos of him, his relatives and residences, as well as comprehensive news stories about the scandal with Kardashian. The person concludes that Radaris provides more comprehensive information on one page than multiple Google searches.
Player owns and guides a small town near a railroad through building construction, transportation development, and hosting festivals and events to please the town's residents, or townies, who provide quests and hints to further expand the town.
This document discusses Turkish meals and cultural events. It mentions breakfast foods and avoiding refusing second helpings to not insult hosts. Several religious and secular holidays and festivals are noted including Muharrem, Ramadan, and SekerBayrami.
Changing the nature of nature in policy and decision making ruralfringe
This document outlines challenges in current nature policy and decision-making. It argues that nature is often seen as a constraint rather than an asset, and economic models do not adequately value ecosystem services. Evidence used in policymaking focuses too narrowly, and nature is associated only with iconic places and species. The speaker advocates revaluing nature by integrating it into development and assessing impacts using tools like ecosystem services analysis. This can help move nature from being a disconnected afterthought to an integrated asset that maximizes benefits for both environment and humans. Key is measuring nature's intrinsic value, overcoming silos, and recognizing growth and nature can work together rather than opposition.
Critique is a type of structured feedback that examines what works and doesn't work in a design from the perspective of the audience and goals. It should provide specific, actionable feedback. Incorporating critique into the design process provides benefits like new ideas, improved communication skills, and collaboration. Critiques can be done internally at different stages of a project or with clients. They work best with 3-6 diverse participants and last 30-60 minutes. Ground rules and clear goals help critiques run effectively. With practice, critique is a skill that can improve design work.
This document outlines a presentation on design and the design process. It includes:
- An agenda covering design, UI/UX, and a 5-step design process
- Exercises walking through each step of the process using a hypothetical synthesizer redesign as an example
- Recaps summarizing the key points about kickoff, research, design brief, ideation, evaluation, and presentation.
In the fall of 2018, I was asked to present a guest lecture to first year students enrolled in the Business Technology Management program at Ryerson University.
A design sprint is a five-phase framework that helps answer critical business questions through rapid prototyping and user testing. Sprints let your team reach clearly defined goals and deliverables and gain key learnings, quickly. The process helps spark innovation, encourage user-centered thinking, align your team under a shared vision, and get you to product launch faster.
Explaining design critiques, their importance and outlining our approach at incorporating them into everyday work for a distributed team working across different projects in different sectors.
Why Can't We All Just Get Along? Improving Designer/Developer CollaborationAllison Corbett
This document discusses improving collaboration between designers and developers on agile teams. It begins by debunking common myths that designers and developers have about each other. It then provides tips for improving the collaboration process, such as getting design work done before development starts and using tools like sketching, paper prototypes, and wireframes. The document concludes with tips for designers, developers, product owners, and scrum masters to foster collaboration, such as involving all roles in requirements gathering, providing constructive feedback, and maintaining respect.
Research Proposal B06 Cognitive Conflicts 4269861David J Mooney
The document reports on a study that analyzed how design teams cope with different types of conflicts (cognitive, affective, process) throughout the different phases of the design process. Five teams of five students each were asked to complete a small design task going through the phases of analysis, synthesis, simulation, evaluation, and decision. They reported conflicts during each phase. The results showed that the amount and type of conflicts varied significantly depending on the design phase, with cognitive conflicts dominating in later phases as the importance of the group increased. The study provides evidence that conflicts develop differently in each phase of the design process.
Crystal Clear is an agile software development methodology created by Alistair Cockburn. It focuses on 7 properties: frequent delivery, reflective improvement, osmotic communication, personal safety, focus, easy access to expert users, and an automated testing environment. The development process in Crystal Clear involves several cycles including the project cycle, delivery cycle, iteration cycle, daily cycle, integration cycle, and development episode. It emphasizes frequent delivery to users, reflection and improvement, collaboration through open communication, and an environment that allows developers to focus on their work.
The document outlines seven "deadly sins" that can undermine the effectiveness of software reviews: lack of understanding of the review process, personal criticism rather than focusing on the product, lack of planning for reviews, problem-solving during reviews rather than finding defects, inadequate preparation by reviewers, involvement of the wrong people in reviews, and focus on style rather than substance. It provides symptoms of each problem and recommends solutions such as training, emphasizing peer review of the product not the author, explicit planning of reviews, moderating discussions, ensuring preparation time, appropriate composition of review teams, and establishing coding standards.
1. The document outlines a Lean UX workshop process involving 4 steps: developing hypothesis statements, collaborative design, developing minimum viable products (MVPs) to test hypotheses, and continuous feedback and research.
2. In step 1, participants form groups to identify problems and write hypothesis statements to guide their work.
3. Step 2 involves collaborative design activities like brainstorming ideas and designing prototypes based on feedback.
4. In step 3, groups create low-fidelity MVPs to test with users and stakeholders.
5. Step 4 has groups conduct user interviews and research to iterate their MVPs based on continuous feedback.
Speed Design Studio is a variant of Will Evan’s Design Studio Process and was designed collaboratively by Jabe Bloom and Will Evan’s at TLCLabs
Speed Design Studio was modified from the original based on insights from Cognitive Edge methods and is focused on extremely rapid iterations in an attempt to emerge team level understandings of design problems and solution language.
Due to efforts applied to tighten cycle times, Speed Design Studio can be taught in a 1-2 hr workshop.
User-centered design (UCD) is a design philosophy that focuses on the needs of users throughout the design process. The document discusses the key steps in UCD, which include defining the project and users, creating concepts, designing visual solutions, development, and deployment. It emphasizes early and continuous user research methods like interviews and usability testing to help ensure designs meet user needs.
Group Exercise_Best Practices for Meetingsdaniel_hart
I developed this exercise for a technical writing class. It helped students work together and was an excellent introduction to best practices for meetings.
Incorporating a UX Mindset Early in Product DevelopmentCorey Dulimba
The learnings and best practices gained from a 5 week engagement between a product manager and UX. The interesting twist is that the UX was part time so we took a lean approach and was still able to validate customer segments and solution assumptions.
To document or not to document? An exploratory study on developers' motivatio...Hayim Makabee
This document summarizes a study on developers' motivation to document code. Through interviews and surveys, researchers identified hindering and motivating factors for code documentation. Hindering factors included documentation being tedious, difficult, time-consuming, and interrupting coding work. Motivating factors included documentation improving code comprehensibility, order, and quality. The researchers propose designing a solution to encourage documentation by emphasizing motivating factors and mitigating hindering ones. They plan to further validate findings through a quantitative questionnaire. The goal is to increase developers' internal motivation to document code.
Agile-Friendly User Research. Nina Belk, UX People, 2013Nina Belk
“It takes too long." "We don’t have the budget." "We don’t really need it, we can just optimise once we’ve gone live.” Sound familiar?
As UX embraces agile as a project delivery approach, research seems get left out in the cold. Rather than shivering and complaining about it though maybe we just need to stick two fingers up to these assumptions and dare to do things a little differently!
In her workshop at UX People, Nina helped delegates explore how to bring research in from the cold on agile projects. There were tips on getting the research basics right (effective participant recruitment and facilitation techniques), and delegates were given the opportunity to road-test their facilitation and analysis skills in an agile-friendly framework (full exercises not available in this presentation).
If you're looking to arm yourself with some practical skills, and a research approach that will blow those assumptions about speed, cost and the lack of value out of the water then this workshop would have been for you, but you'll have to make do with this SlideShare presentation instead!
This document outlines the 9 main steps of the engineering design process:
1. Define the problem
2. Do background research on existing solutions and users
3. Specify requirements for a successful solution
4. Brainstorm possible solutions
5. Choose the best solution based on requirements
6. Develop the chosen solution in more detail
7. Build a prototype to test the solution
8. Test and redesign the solution through multiple iterations
9. Communicate the final results
Introduction to Usability Testing for Digital MarketeersLennart Overkamp
These slides provide an introduction to usability testing for digital marketeers. This well-known method in user-centred design is used to improve products, by having participants interact with these products and by measuring their performances and responses.
I presented this topic as a guest lecturer to students attending the Minor Digital Marketing at the Fontys ICT Eindhoven at April 5th, 2017. Providing examples and best practices from Dutch digital design agency Mirabeau, I explained to them the required steps for the preparation, the moderation, and the analysis of usability tests.
Similar to Will schroeder racing with the clock 5 25 11 (20)
International Upcycling Research Network advisory board meeting 4Kyungeun Sung
Slides used for the International Upcycling Research Network advisory board 4 (last one). The project is based at De Montfort University in Leicester, UK, and funded by the Arts and Humanities Research Council.
Discovering the Best Indian Architects A Spotlight on Design Forum Internatio...Designforuminternational
India’s architectural landscape is a vibrant tapestry that weaves together the country's rich cultural heritage and its modern aspirations. From majestic historical structures to cutting-edge contemporary designs, the work of Indian architects is celebrated worldwide. Among the many firms shaping this dynamic field, Design Forum International stands out as a leader in innovative and sustainable architecture. This blog explores some of the best Indian architects, highlighting their contributions and showcasing the most famous architects in India.
Explore the essential graphic design tools and software that can elevate your creative projects. Discover industry favorites and innovative solutions for stunning design results.
15. In the second hour: Prototypes polished for testing 3 usability tests – for each design Users gave comparative feedback Developers, observing, absorbed all this Hour #2
16. Feedback was good ... Participants: “Having artifacts [designs and supporting materials] to go back to was very valuable.” “Seeing designs is better than simply recording them in a spec.” “I like including users in collaborative design.” “No time to over-think solutions.” “… the opportunity to view the ideas of other groups and borrow ‘guilt free’ was a good thing.” Developers: “… we had done quite a bit of design work on this feature” “… pleasantly surprised with the designs.” “… validated our design (there were many similarities), came up with new ideas, and exposed a design issue ….” “… created and explored more design ideas in minutes than we had come up with in a month.”
20. Nature abhors a vacuum People LOVE their own ideas So they add unnecessary requirements The facilitator describes a problem Each team makes its own list of specific instances of the problem Then they chose one to seed their design Later some teams chose to cover more cases Giving pre-work failed Stern speeches failed Handing out lists failed 2X Starting a design task is very difficult
21. 2X Design always works out fine – 5 minutes is plenty
23. Not getting the full benefit Could go on longer (under control) Participants give notes – even draw ideas Facilitator prompts the explanation, orchestrates the design critique ... and keeps up the tempo 2X
24.
25. Tests work fine with minimal or no preparation2X Wastes time, dilutes effort
27. No scouting, no show and tell, not enough revision Participants did not see all tests ... And they did not take notes ... So there was not enough feedback And there was no “fixing” between tests One user testing all designs is about the useful limit Multiple rounds of testing requires more than two hours 2X
28. Make recording part of the process - List of pains - Keep and number sketches Take notes in show-and-tell Facilitate debriefing 2X No formal process
29. IN A NUTSHELL PIECES Players chose goals Blitz design sessions Show and tell Parallel testing Iteration No breaks GLUE Facilitation Time Pressure Structured activities For timing For feedback Levels of design
30. Getting the right design and the design right, MaryamTohidi, William Buxton, Ronald Baecker, Abigail Sellen- April 2006CHI '06: Proceedings of the SIGCHI conference on Human Factors in computing systems Questions? Will.Schroeder@MATHWORKS.COM
Editor's Notes
Good afternoon - I’m Will Schroeder of the MathWorksI’m going to talk about combining brainstorming, rapid prototyping, and usability testing into a process that takes a small feature from design exploration all the way to where it is ready for wireframes Why bring all of these techniques together? Information transfer between processes is inefficient and wasteful Stopping and starting consumes time and energy better used for design Scheduling constraints make it difficult to march a team through three separate activities together – or even to keep a team together for that longWhen I put it that way, I’m hoping you will ask: “Why not put them all in a room, lock the door, and not let them out till they are done?”Well ... Why not?It’s pretty clear that two things need to be added if there is any hope of making this idea work:Structure. The participants need to know at every moment what to do – and what to do next. And reminded of this as frequently as necessaryA timekeeper to keep the process moving.Which means that this idea for streamlining the design process hasn’t a prayer without a facilitatorBut why are we racing with the clock?Two reasons: (besides, of course “Time is Money”)First, managers tend to measure value by time spent. For any new process to make headway against what seems to work fine already, it not only has to be better, it has to be quicker.Second, deadlines and imposed time management have beneficial effects all in themselvesAs Samuel Johnson said, "Depend upon it, sir, when a man knows he is to be hanged in a fortnight, it concentrates his mind wonderfully." So let’s talk about time compression a moment(SLIDE)
The idea here is that the patient spends 45 out of 50 minutes fidgeting, fussing, denying, evading, and going off subject, and finally “gets it” in the last five minutesSurely some of that 45 minutes could be eliminated, but we don’t know how muchSo how much could we compress the design process?(SLIDE)
I presented this scheme here a year ago, and we have been working with it and improving it since.I’m going to run through the original scheme quickly to give you the basic ideasThen I'll go back and tell you about what we have learned since.
I chose teams, of course – we haven’t time for democracy.Teams of 4 worked well –so we stuck with that.We spread developers, quality engineers and usability specialists across the teamsI brought a lot of different prototyping materials, not knowing which ones people would want,Hoping that the variety would be inspiring – but they mostly sketched on 5” x 8” index cards
We gave them two tasks (use cases) to guide their design, and screen shots of the existing GUI to work inHere’s an example of the scale of project we began with - for reference.Imagine a widget added to the Outlook GUI whose purpose was to control the announcement of arriving emails. It could be turned off and on, filter messages by type (rule), and control the noise (threat) level of what was announced.There would be a level-setting task and a filtering task, and the widget would need to find a place in the copies of the Outlook GUI we handed out
Each team prototyped a concept– IN FIVE MINUTESThis is the part that ALWAYS works - it has always worked from the beginning.When they get ten minutes, they waste the first fiveAnd teams always produce something that bakes well in Show and TellThis is the core of the process – the remaining steps serve to firm up the concepts and match better them to the task goals
Show and tell was the big surprise (for me, anyway) in the first sessionsTELL WHAT THEY DOIt’s amazing to watch people DISCOVERING how their design works (or doesn’t work) as they describe it to othersThis phase always produces lots of great feedbackShow and Tell requires structuring to ensure that All ideas are heard The session doesn’t lose momentumStructuring was one comment per person, picking the next person to talk (if necessary) and bringing show and tell to a close at the right time.
Then they take what they have learned back into design, Fixing was enthusiastic: Holes in the design were patched Ideas were “borrowed”– and the first hour ended on a high note with a second show and tellWith each team eager to explain how they had improved their design, or resolved problems
Why did we break?For two reasons:1) this was (at first) a kind of skunk works project – we did it at lunchtime so as not to appear frivolous with company resources.2) I was also concerned as to how long such a group could perform at top level, driven constantly by a facilitator.
We began the second hour by preparing prototypes for testingThe clever ones among you will note that the teams are actually repeating work that they did – or should have done – and the end of the first hour – but they were also working out how they would test
We ran three tests in parallel, with just three users who rotated through the designs
If you’ve never heard the kind of user feedback you get after testing three designs aimed at the same tasks, you have a treat coming.I have always had my reservations about the think-aloud process in a single-user, single-design test, but when users compare different designs as they test them in sequence, the quality and value of the feedback reaches a whole new level.
I got this idea from a paper given at CHI Montreal by MaryamTohidi – a student of Bill Buxton’s.I had been itching to try it ever since, and have learned that this is just about the only way to bring it offI have never been able to organize/schedule conventional testing this tightly.
This left us with five minutes to debrief – which was not enough. Participants had to report design feedback after the sessionAlthough we were very excited at first about how much we were getting ...We realized that we were also leaving a lot on the table
And so that was it – real time about 100 minutes from beginning to endSo how did it work?
(Take a moment, let them read, take a drink of water)So this all sounds pretty good, doesn’t it?Time for a thought experiment
Well, suppose you meet up – for the first time - with a dog that talks Not only does this dog talk, he talks really fast – like an auctioneerAlthough you have seen plenty of fast-talking people, because you have never seen a fast-talking dog beforeYou are probably blown away by this suave canineIt may be quite a while before you ask yourself whether what the dog said made sense or notThe process worked – it did not crash and burn – but was that beginner’s luck?How good was it REALLY?(SLIDE)
For the past year, we have been paying close attention to what the dog is saying..We have done three successful real-time projects (not lunch-time) and We are wiser. I’m going to go through the process again step by step and:Talk about problems we encountered (and mostly circumvented or made go away)Improvements and new ideas which worked betterAnd a few ideas we haven’t tried yet.
Four still seems to be the ideal team size. Smaller teams work, but are a bit lean on ideas and don’t revise as eagerly.Larger teams almost invariably leave one person sitting on the sidelines.There are “natural” roles for a team doing this kind of work, if the task is set properlySometimes people just fall into these roles (time pressure works wonders)Other times the facilitator must nudge them
Getting everyone started from the same place is hardWhat’s supposed to happen in this (brief) time is that the team agrees to and focuses on a design objective which they all understand equally well, and which they proceed to solve together.(CLICK)What actually happens all too often is that instead of solving the set design problem, people will try to drive the design by imposing additional requirements. Does this sound familiar? Don’t think because the time is short that this kind of thing can’t happen.(CLICK)This is a tough problem. I tried a number of things that didn’t work. Everything top-down failed. Against my will I was forced to institute democracy.In the time I had originally given myself to speak, I had the team describe problem/solution scenarios using the widget, such as “”Working on an important letter, screen out everything that’s not vital.” or “Messages from sales are not getting through.”
Design is fascinatingly effective again. If you can get them all to start from the same place, people do this REALLY WELL. There is a bounty of good ideas, just as in brainstorming. Now we must make the most we can from these ideas
Show and tell is a natural way to develop conceptswhen the ideas are explained to someone who is not one of the originators.The implicit part of the design (the team’s assumptions) becomes explicit
Show and tell brings immediate refinement to concepts with the requirement that they be explained to a third party.Things implicit in the design become explicit.(CLICK)It works immensely better when the facilitator orchestrates it. Set examples with positive comments, encourage people to give critiques in sequence, one idea at a time, prompt individuals to fill empty spaces, move things along(CLICK)It’s hard to forecast when the last really great idea is going to surfaceParticipants don’t digest fully what is going on (the group is now too big)(SLIDE)
Breaks really don’t work(CLICK)Also, “Preparing for test” is just a waste of time. (CLICK) Testing works fine with little or no preparation.
Interactive testing fleshes out the next level of detail – the details of interactionComparative testing generates a tremendous amount of valuable information about the details of the three designs(SLIDE)
And that’s another problemWe are producing feedback a lot faster than we can consume it(CLICK)We tried to do too much – we wasted effort and missed too muchThe data we produced did not get ploughed back into the design work “while the iron was hot”(CLICK)To make full use of iterative parallel testing we need more time(Two hours should just about do it)
A relaxed debriefing session afterwards might be pleasant, but recording data from memory is not efficient, and can be misleading.We have begun to build more debriefing into the process, and sequence the process to support better note-taking.