Table of Contents
- You’re a Learner/Student
- You’re an Instructor
- Class Description
- Class Structure
- Session 1: How do you facilitate strong digital deliveries?
- Session 2: How do you anchor your design?
- Session 3: How did you anchor your design?
- Session 4: How do you coach for strong user stories?
- Session 5: How do you design UI’s?
- Session 6: How do you test UI concepts?
- Session 7: How do you run user testing?
- Session 8: How do you act on your learnings from user testing?
- Session 9: How do you build a better UI with four user tests?
- Session 10: How do you prototype with HTML?
- Session 11: How does CSS improve HTML?
- Session 12: How do you analytically debug HTML & CSS?
- Session 13: Final Contest I: What did you do? Where’s it headed?
- Session 14: Final Contest II: What did you do? Where’s it headed?
- Final Submission
- Speaker Footage
- Teaching Notes
- Footnotes
You’re a Learner/Student
This page describes a class about software design- surprise, surprise! You’ll find a bunch of things here you can use on a self-service basis, but it’s mainly designed for instructors. If you’re looking for a more put-together learning experience, a lot of this material is in my course ‘Agile Meets Design Thinking‘ on Coursera (part of the Agile Development specialization).
You’re an Instructor
This is a 14 session class on software product design that I currently teach it at UVA Darden (graduate school of business). The materials here are intended to be ready for use by instructors/facilitators. For more on setting up to use some or all of these modules (including stuff like grading and managing student teams), please see the section below ‘Teaching Notes‘.
The audience is for this class is a ‘businessperson’ who wants to engage on software-related projects (no prior software skills required). A design-driven approach is most likely to help the business person manage to a good outcome, and here we use a lot of material from Hypothesis-Driven Development. I’ve seen students successfully apply these skills against many cool jobs. Here are four of the most recurrent:
- Doing a startup (as primary job or side project)
- Working as a product manager (one of the world’s least defined jobs, but this skill set is critical to doing it well)
- Working as a consultant on solutions that involve software/applications
- Working in private equity/venture capital with active involvement in portfolio companies
I’d love to hear from you on how the materials worked for you and/or how to make them better (or anything else you think is pertinent). Please feel free to leave comments here or drop me a line. Also, there are a bunch of general resourced on the LEARN/TEACH page.
Class Description
While every year technology improvements make it easier to build more powerful software and systems, creating software that’s relevant to users and competitive in the marketplace is tougher than ever. By one measure, 64% of features are rarely or never used1, 50-70% of IT projects fail2, and 90% of new products are flop3.
That’s a lot of waste, expense, and missed opportunity.
Products usually fail because they:
- Solve a problem, do a job, or gratify a desire that few people find important
- Fail to deliver a proposition that’s better enough than the existing alternatives
- Have a weak execution and poor usability
In this course, we’re going to focus on #3 above. Particularly if you’re starting as a product manager or team lead for an existing product, this is a lot of what your day to day will require.
By the end of this course, will be able to:
- Facilitate the evolution of general ideas into testable, user-centric narrative
- Create development-friendly inputs with user stories and prototypes
- Systematically test the above
- Instrument observation and testability into your digital deliveries
- Go from idea to code with static prototypes in HTML & CSS
Class Structure
Your final team deliverable is a tested prototype for a particular user story.
The material we’ll cover in class is not intellectually difficult- you could spend a few hours and understanding (in concept) everything we’ll cover in class. However, it is challenging to practice. Bright, energetic professionals like you spend whole careers just practicing and sharpening their ability in a few of these topics. For this reason, our emphasis is on short introductions, time for practice and collaboration in class, and then review of example submissions in class.
Session 1: How do you facilitate strong digital deliveries?
Learning Objectives
After this session, students will be able to
1. Explain the role of a product manager or product lead in focusing digital deliveries
2. Explain how product usability relates to need-finding and proposition testing
Class Preparation (Individual)
1. Project Submissions (Optional)
Submit a student venture project if you have one.A
2. Read the following post and be prepared to discuss the questions below:
A) Paul Adams: Great PMs don’t spend their time on solutions
What do great PM’s spend their time doing? Why?
The author described a spectrum of time allocations across the product pipeline.
Why do you think tends to be so much more emphasis on the later (design & development) parts of the pipeline?
Session 2: How do you anchor your design?
Learning Objectives
After this session, students will be able to
1. Progress validated learning on personas, problem scenarios, and propositions to development-friendly narrative via user stories
2. Facilitate the creation of testable user stories by linking them to qualitative and quantitative observations and decisions
Case
Class Preparation (Individual)
1. Review The Testable Design. Be prepared to present your work and discuss the following questions:
A) Draft an ‘epic user story’ to summarize the interaction described by the storyboard.
What initiates or triggers this story?
When is it done and successful from the perspective of the user?
How would you test that with a prototype?
How would you observe it with metrics on a live delivery?
B) Detail individual ‘child user stories’ within the epic to detail the component interactions in more detail.
Do you think the storyboard is missing important details?
How would you drive to testability for the individual user stories?
2. Read the following post and be prepared to discuss the questions below:
How (and why) to write great User Stories
Why are user stories important?
How do they relate to the solution you implement?
Session 3: How did you anchor your design?
Learning Objectives
After this session, students will be able to
1. Progress validated learning on personas, problem scenarios, and propositions to development-friendly narrative via user stories
2. Facilitate the creation of testable user stories by linking them to qualitative and quantitative observations and decisions
Class Preparation (Group)
NOTE 1: The topic for the prep. below is your team’s selected venture concept.
NOTE 2: While I encourage you to find a group in time for this, it’s fine to do this on your own if you haven’t settled on a group. For groups, you should prepare jointly but all of you should be prepared to present and discuss the team’s work in class.
1. Agile Epic or Epics
WHAT? Create or choose a problem scenario + proposition pairing from your selected design brief and draft one or more epic user stories that describe the major user experiences.
Key things to remember:
1. Make sure you have a specific persona and problem scenario/JTBD in mind, though you can feel free to edit/refactor them (reminder: design is iterative!).
2. These have the same format as any other user story–they’re just broader in scope. Include all three clauses of the agile user story.
3. Pick specific interactions/tasks–epic sounds big, but this is not a description of the whole product. Check the examples from last week’s case for specific examples.
4. These are inputs for a very specific discussion with a developer about building something. A good litmus test is to ask yourself “From this user story, could I proceed to prototype this, put it in front of a user, ask them to complete some task, and specifically observe whether they were able to do that or not?”
WHERE? This is class preparation, so it doesn’t matter that much how you organize the material. However, there is a template available here to (hopefully) make it easier to hit the key elements: Instructions & Template for User Stories (Group).
Note: If you strongly prefer MS Word, you can download this template in that format.
EXAMPLE? You’ll find an example in the template above.
2. Storyboard one of Your Agile Epics
WHAT? Take your favorite epic and draft a storyboard for it. This is a great way to make sure you’re really putting yourself in the user’s shoes and thinking through the important details. Try for six or so panels on paper.
WHERE? I recommend sketching on paper. Following that, photograph your storyboard and drop the image into your whatever working doc you’re using (see above for a template)
EXAMPLE? You’ll find an example in the template above (the epic/item #1).
3. Draft Child User Stories & Analytical Questions
WHAT? Take the epic you storyboarded and detail out its specifics with individual user stories (same format as the epic). Pair these child stories with one or more simple analytical questions about how you’ll know if a given implementation of the story is performing well.
WHERE? Add these to whatever working doc you’re using (see above for a template).
EXAMPLE? You’ll find an example in the template above (the epic/item #1).
Session 4: How do you coach for strong user stories?
Learning Objectives
After this session, students will be able to
1. Provide actionable feedback on user stories
Assignment (Individual)
Peer review: user stories
WHAT? Review your assigned peer’s work (see peer pairings below), providing rubric-based feedback as well as qualitative observations and questions for you to discuss with your peer in-session. You’ll find spots for qualitative feedback and questions in the design review rubric.This is a chance both to practice your own understanding, help your fellow classmates, and be helped yourself.
(add peer pairings)
WHERE? The rubric is available here: Peer Review- Software Design/User Stories. In addition to submitting it, please be sure to share it with your peer.
Class Preparation
1. Read the following posts and be prepared to discuss the questions below:
A) Michael Straker: Web Design: The Case for Parallel Prototyping
What were the findings of the research the author cites?
Why do you think they found what they did?
2. Watch the videos below are be prepared to discuss the following in the context of your team’s project:
A) Usability with Donald Norman’s 7 Steps Model
B) The Importance of Comparables and Prototyping
What is the relationship between jobs-t0-be-done, user stories, comparables and the three levels of cognition in Donald Norman’s 7-step model?
How do comparables relate to achieving strong usability?
How will you approach the parallel prototyping process for your team project?
Session 5: How do you design UI’s?
Learning Objectives
After this session, students will be able to
1. Map user stories toward to relevant interface patterns with comparables
2. Facilitate collaborative, evidence-driven UI development through parallel prototyping
Assignment (Group)
1. Evaluate Comparable’s for a Selected User Story
WHAT? Based on your top epic user story (and its children), pull together a set of comparables, including screenshots, links, and notes. You should aim for at least two ‘families’ of comparables to push yourself to really think about different ways that you might deliver this experience.
Exactly what your notes should cover depends on the context but might answer questions like:
For which story or stories is this comparable relevant (if that’s not obvious)?
What’s applicable vs. less applicable about this comparable?
What do you specifically like/not like about it?
What general UI patterns are worth noting?
WHERE? There is a template available here: Design Notes Template- Software Design/Comparables. I would create one of these for your group and use it as your working doc for the balance of the class.
Note: If you strongly prefer MS Word, you can download this template in that format and use it on Office365, but please make sure your submission is in a synchronous web doc. That’s important so that your team, myself, and your peer reviews can collaborate on a single perspective on your project.
EXAMPLE? There is an example in Appendix 1 of the template above.
PRO TIPS This means looking at sites that do some of the same things you have going on in your project- but that’s functionally speaking, not topically speaking. For example, the HVAC in a Hurry team didn’t look at other HVAC companies- they looked at eCommerce sites that help users find what they want to buy, they looked at auto sites that do the same but with a more similar set of items, and they looked at photo sites that focus on visual search.
You should go through and think about different sites or applications that deliver some of the same functional experiences as your user stories. Make some notes about them. As you zero in on specific elements, sites that organize UI patterns are also very helpful:
UI Patterns
UI Garage
The idea is that you have multiple families, chunks, of comparables—so , that means different metaphors, or types of sites like a photo sharing site versus an e-commerce site versus a site for buying and selling used cars. That is an example of three families.
You should include screen shots and links of these. Then there are the questions above that you should make note of and to establish both for yourself, and for others. These questions help you determine what you think is and is not relevant about these comparables that you think you might take forward and use in your prototypes, and subsequently your testing.
2. Parallel Prototype (Min. Two Versions) of the Same User Story
WHAT? For your selected user story, use Balsamiq to wireframe two parallel user interface concepts that support the same story. For your key user stories, you should have two different prototypes that are substantially different. However, you do not need to make these interactive (clickable). Please use the Google Drive version of Balsamiq (for easy sharing and collaboration).
WHERE? Place the screenshots, notes, and Balsamiq mockup’s for each of your (min) 2 directions in of your working doc in the applicable section (Prototypes).
EXAMPLE? (see above example from comparables)
PRO TIPS You can either provide a link to your Balsamic file and then just make notes (there’s a place to make notes in Balsamiq on the right margin. Or, you can export images out of Balsamiq, put those in the link and make notes in your Google Doc or Microsoft Web Doc- whatever you are using.
You should have a couple of different frames, transitions. You don’t need to make them interactive, but you should have a couple of different views of how this interface is going to work. And, you should have notes on why these make sense. So, what user story does this or that frame relate to? In looking at the HVAC in a Hurry example, you can see some of the families of comparables that they pulled. Then if you scroll down you can see the parallel prototypes of concept 1 and concept 2.
Session 6: How do you test UI concepts?
Learning Objectives
After this session, students will be able to
1. Progress a set of user stories through to exploratory testing
2. Design and validate a usability test plan
Preparation (Group)
1. Prepare and dry run a usability test suite.
WHAT? For the epic(s) you storyboarded, pulled comparables for, and began to prototype, create a dry run a usability test suite. Please be prepared to run your test plan in class for a ‘live case’ session.
This includes two things: 1) a usability test plan and and 2) an interactive prototype that supports your testing.
1. The core of the test plan is in the subsection Test Items. Your user stories are the primary input into this section. You can see them en situ in the example in Appendix 1, but a typical ‘Research Objective’ for a given row might be:
“How are we doing on this user story:I know the part number and I want to find it on the system so I can figure out next steps on the repair.”
2. Once you have your test plan in order, update your prototype so it supports your test plan. The contents of the test plan should drive how the prototype works- not the other way around.
3. Dry run the test plan with a subject and record the result. The subsection “Pre-Session Checklist” is a good place to remind yourself of anything you find you need to make sure is set up in a certain way before the test begins.
WHERE? You’ll find a section for this in the template for your working doc (Usability Testing). Please provide a link to your interactive prototype on Google Drive in the subsection “Product Version”. Please link to the footage of your dry run in the section “Post-Test Debrief & Footage”. Please share those files to acowan@alexandercowan.com.
EXAMPLE? See the corresponding section in Appendix 1 of the working doc template. You can find an example prototype Balsamiq from the HVAC in a Hurry Example here: Interactive Prototype HVAC in a Hurry.
Supplemental Resources
1. Demo/Example: Running a Usability Test at HVAC in a Hurry
2. Recording Your Dry Run
3. Making Interactive Prototypes in Balsamiq
Session 7: How do you run user testing?
Learning Objectives
After this session, students will be able to
1. Run user tests with live subjects
2. Iterate on test design, design content, and interface concepts based on the results of user testing
Preparation (Group)
1. Complete (Min.) Two Subject Tests Using Your Test Plan
WHAT? Using the test suite you prepared, conduct and record at least two subject tests. As a reminder, you should feel free to update both the test plan and the prototype as you go along.
WHERE? Please duplicate the Takeaways tables. Please be sure to include your observations and any ideas for improvement. Please link to the footage in this table as well.
Session 8: How do you act on your learnings from user testing?
Learning Objectives
After this session, students will be able to
1. Facilitate iteration on both designs and test plans with peers
Assignment (Individual)
1. Peer review: Work to date
WHAT? Review your assigned peer’s work (see peer pairings below), providing rubric-based feedback as well as qualitative observations and questions for you to discuss with your peer in-session. You’ll find spots for qualitative feedback and questions in the design review rubric. This is a chance both to practice your own understanding, help your fellow classmates, and be helped yourself. Please share your work with your peer: a) working doc b) prototype, c) usability testing footage.
(add peer pairings)
WHERE? The rubric is available here: Final Peer Review- Software Design. In addition to submitting it, please be sure to share it with your peer.
Class Preparation
1. Read the following post and be prepared to discuss the questions below:
A) Erika Hall: Just Enough Research
What’s hard about doing things well?
If your current design is a series of decisions, what are those decisions?
Which are most critical to the success of the venture? How might you test them?
If questions determine results, what are the most important questions for this project?
Why is ‘How do we get Millenials to like us?’ a bad question?
Session 9: How do you build a better UI with four user tests?
Learning Objectives
After this session, students will be able to
1. Improve UI design with limited time and resources
2. Instrument the above for actionable observation and future iteration
Preparation (Group)
1. Complete (Min.) Two More Subject Tests (Four Total) Using Your Prototype
WHAT? Using the test suite you prepared, conduct and record at least two subject tests. As a reminder, you should feel free to update both the test plan and the prototype as you go along.
WHERE? Please create two new Takeaways tables. Please be sure to include your observations and any ideas for improvement. Please link to the footage in this table as well.
2. Iterate (as needed) on Metrics for Actionable Observation
WHAT? Using the existing working doc, update (as needed) your notes on key analytical questions and metrics for observation. Be prepared to discuss the following:
For your various user stories, what are the most important analytical questions? Why?
What metrics would you use to observe answers?
How would you iterate on your design based on those observations?
WHERE? As needed in the section with your user stories, etc.
Session 10: How do you prototype with HTML?
Objective
Achieve basic working proficiency with HTML.
Case
Class Preparation
1. Prepare the case: From Prototype to HTML
A) Fork the starter code on JS Fiddle (see note below on how), then review and update the code relative to the following questions:
Looking at the sample code on JS Fiddle, can you identify all the HTML tags (headings, div’s, etc.)?
Can you explain their roles?
How about their additional properties (like styling)?
Suppose you wanted to create rounded corners on the div elements with a solid border? How would you do that?
What else do you think is worth trying? Try it out!
B) Doing Google searches like ‘create round border on a div’ is a great way to learn and get comfortable working through code. It’s what we all do!
2. Read: You Don’t Need a Technical Co-Founder by Mahmoud Swehli
A) Is a technical co-founder necessary for a new venture or project?
Why or why not?
If not, what product-related skills does the founder need to have?
Notes:
In class, we’ll step through the elements of the page and edit them based on ideas for moving it forward. Doing Google searches like ‘create round border on a div’ is a great way to learn and get comfortable working through implementations.
Supporting Materials
1. Written Tutorial- HTML Introduction
This is a good introduction. If you want something more guided to ease you into the concepts, see the next item.
2. Online Course- Learn HTML
I would stick to just the first module ‘HTML Elements and Structure’ and (unless you’re interested) skip the module on tables, ‘HTML Tables’. The idea here isn’t to make sure you understand every little detail, but to make sure you have enough of a foundation to ask the right questions and answer them yourself to the greatest extent possible.
Session 11: How does CSS improve HTML?
Objective
Achieve basic working proficiency with CSS.
Case
Class Preparation
1. Read: Design principle: Consistency.
Why might consistency be important to a good user experience?
What’s an example (digital) experience where you thought consistency improved the experience?
Where inconsistency detracted from it?
Where you’re not really sure how important consistency actually is to an experience?
How does consistency of presentation and experience relate to CSS?
2. Prepare the case.
Looking at the sample code for Prototype 2, can you trace the CSS entries back to their application in the HTML? Try rounding the corners on the borders around the various HVAC parts. Does it work?
How would you tackle the items in Exhibit B? Reminder: log in to JS Fiddle to save your work.
What else do you think is worth trying? Try it out!
In order to have something you can show and discuss in class, you’ll need to fork the JS Fiddle and save your edits
Notes:
In class, we’ll step through the elements of the page and edit them based on ideas for moving it forward. Doing Google searches like ‘create round border on a div’ is a great way to learn and get comfortable working through implementations.
Session 12: How do you analytically debug HTML & CSS?
Objective
Achieve basic working fluency with analytical debugging of HTML & CSS.
Case
Class Preparation
1. Read: 5 Good Reasons Why Designers Should Code
If you’re acting in the role of designer, why might it be important to be able to code?
Is it?
2. Prepare: Debugging HTML & CSS
For each issue described in the case:
A) What is the HTML element concerned? How does it relate to the elements around it?
B) What are the applicable CSS selectors (classes, ID’s, etc.)? What CSS entries do you see for those?
C) There are notes on using the Chrome DEVTOOLS in the case. The Chrome DEVTOOLS will show you which CSS has precedence if there’s overlapping entries.
Notes:
In class, we’ll step through the analytical debugging process you used to resolve the issues. In this context, the process is much more important than the final answer or fix.
Session 13: Final Contest I: What did you do? Where’s it headed?
Learning Objectives
After this session, students will be able to
1. Integrate and practice the course learning objectives through continuous design and iteration
2. Effectively communicate the quality of your work as a designer and innovator
Class Preparation (Group)
1. Prepare a 5 Minute Presentation (Including HTML, CSS Prototype)
WHAT? Prepare a five minute presentation for your peers (not a pitch), which answers the following questions:
1. What problem scenario/JTBD did you focus on and what user experience did you design?
User stories and storyboards are a good fit for this, but be sure they tie back to an underlying PS/JTBD.
2. What did you learn in user testing?
There are a few ways to approach this and verbally is fine. Visually, you can show your progression across various prototypes and/or your working (HTML) prototype.
3. How did you approach the current UI?
The working software is an obvious fit for this- but be sure to focus on how the UI delivers on the target user stories.
4. How will you know if it’s working?
Here you should focus on your analytical questions and pivotal metrics relative to your user stories.
We’ll have voting (day 2) with one category for each of the questions above:
1. Design Focus and Clarity
2. Testing and Iteration
3. Relevance and Focus of Execution
4. Analytical Clarity and ActionabilityPRO TIPS Avoid Power Point and excessive formality. This should model a meeting with peers where you’re looking to inform and get advice vs. a pitch from a vendor or consultancy. Unless you had a very particular take, don’t spend much time re-introducing the subject company- your classmates will be familiar with it by now.
Supplemental Resources
1. Team Portfolio Entry (OPTIONAL)
While this is optional, I highly recommend it both as an element in your presentation as well as an asset for you as your recruit.
WHAT? Using the Google Docs portfolio template and the instructions on the tutorial on creating an interface design entry, draft a portfolio entry for your group’s project. Make sure everyone on your team has an account and is added to the entry. Note: This will serve as the primary input to our end of class contest!
WHERE? You’ll use the template above to create a portfolio entry on Behance (the free plan is fine). Submit the URL of the Behance entry.
EXAMPLE? See the example in the template above
Session 14: Final Contest II: What did you do? Where’s it headed?
Final Submission
While you’re highly encouraged to iterate on it post-presentation, this is essentially a final view on what you did, plus a short journal entry on how you got there. Please be sure to include all the enumerated elements below. All of this will fit in the Working Doc template.
Class Preparation (Group)
1. Notes on Subject Company & Problem Scenarios (Optional)
Feel free to include this in the Working Doc if you made substantial modifications to it (if you didn’t that’s fine).
2. User Stories & Metrics
Please include all of these, including your storyboard. Please be sure to include your analytical questions and metrics as well.
3. User Test Plan, Prototype, & Footage
Please include your test plan, prototype, and test footage, with the footage linked from the various ‘Takeaway’ notes and shared to ‘acowan@alexandercowan.com’.
4. Working (HTML, CSS) Prototype
Please link to your JS Fiddle or JS Fiddles in your submission.
5. Journal Entry
Please make notes on the questions answered below. It’s the overall depth of your entry that matters- if there’s a particular item that wasn’t particularly relevant to your execution, feel free to be brief there, focusing on the items that you think were most important to your execution.
6. Portfolio Entry (Optional)
If you did one, please include a link to it in your submission. (See notes on session 13 for more on this.)
Speaker Footage
Donald Norman (Author/Faculty UCSD)
Donald Norman is one of the most durable and influential voices in design today. At 77, he revised his seminal book ‘The Design of Everyday Things‘ and it’s better than ever. It was an honor to have him speak to the class.
Madison Mount (IDEO)
An entrepreneur and start-up founder himself, Madison Mount guides his clients to build and grow their businesses with an emphasis on agility, prototyping, and leaning into intuition.
For nearly 15 years, Madison has been committed to helping organizations better understand how to thrive and survive in the face of emerging technologies and industry disruption.
Tristan Kromer (Lean Startup Circle/Kromatic)
Tristan is heavily involved with advancing the practice of Lean Startup. Tristan runs the Lean Startup Circle, Lean Startup’s community organization with >80,000 members and chapters worldwide.
Tristan blogs about Lean Startup at GrasshopperHerder and is currently a consultant at TRIKRO.
Bill Wake (Author/Industrial Logic)
A computer scientist by training, Bill Wake is an active participant and key influencer in Extreme Programming (XP), agile, and lean. His seminal post on the INVEST checklist for agile user stories (2003) remains one of the most heavily referenced sources for writing quality user stories.
Bill continues to explore what works in agile software development and blogs about it at XP123. He’s currently a consultant at Industrial Logic.
SLIDES
Teaching Notes
Relationship to Existing Curriculum
The course will complement any existing offerings in entrepreneurship, product development/prototyping, product management, and design thinking, immersing students in hands-on application of these skills within an application development context. The ideal feeder class would help the students initially vet the basic product/market fit for their venture idea- Does this customer exist? Do they really have this problem? What alternatives are they using today?
I follow this course with ‘Software Development‘ where the students do initial coding against these concepts (learning about the relationship between design and implementation in the process).
Student Teams and Projects
I think the class works best with student-led venture ideas. That said, this is not an entrepreneurship/venture creation class. The perfect idea already has at least a) a notional product/market fit and b) a compelling ideas of how software will propel key value propositions. The minimum I usually require is first-hand knowledge/investigation of the customer and the problem area.
Here’s a list of vehicles for getting these projects into the class (not mutually exclusive):
- Classes in Entrepreneurship, Design Thinking
Curriculum in this area usually has student projects where the venture would arrive at something like an understanding of product/market fit.
Pro’s: In addition to qualified projects, the students will enter the class with extremely useful, applicable foundation skill sets. The Software Development class will deepen their skill sets in entrepreneurship and design thinking through application of those ideas.
Con’s: There are few. Possibly, the students may wonder if the material ‘overlaps’, but this question is unlikely do persist after a year or two of word-of-mouth about the class. - University Incubator
This is a program that assists student-led ventures.
Pro’s: The ideas are more organic since they’re student-generated. Since one or more students has invested time, you’re likely to have project sponsors that are paying close attention.
Con’s: You may find the quantity of available/qualified projects coming out of these programs varies a lot year to year. - Independent Student Preparation
Students can, of course, advance venture ideas on their own to a point where they’re a good fit for this class. I’ll be posting a checklist for this purpose.
Pro’s: I think the preparation material is pretty accessible and this is a good option for students who have ideas they want to pursue, but don’t have access to these other options.
Con’s: Going it alone is a good fit for some, less good for others. The Codeless Hackathon below is a good option for students who would prefer more student and/or instructor collaboration on idea preparation. - Codeless Hackathon
This year (’15/’16) is my first go at this, but the basic idea is to have a weekend event where students drive to a focal definition of their idea and a preliminary understanding of product/market fit. - Industry Projects
Corporate sponsors could supply current problem areas where they’d like to develop and/or deploy software. I’m working with my colleagues and collaborators to collect best practices on this (for this particular application) and will post them here.
Pro’s: This can be a great source of relevant real-world problems with existing customers/subjects whose needs are well understood.
Con’s: Strong structure for the student-sponsor collaboration and strong motivation on the part of the sponsor to participate is critical and a possible failure point.
Here is the text I use to describe the projects to students:
‘While the assignments are a mix of individual and team assignments, students will work in teams of 3 (min) to 5 (max) individuals. Students can organize around student-submitted or company sponsored projects. Student projects must be accepted in advance or by the first week of class.
The ideal project topic already has some validation regarding product/market or proposition/user fit, since this is a class where we’re learning to design software vs. vetting a new entrepreneurial idea from scratch. Students will receive a list of a available projects and submission criteria by email in the weeks leading up to class.
The list of available projects is available here: [your Google Doc or similar with projects- including team leads]. ‘
Classroom Environment
This is primarily an ‘experiential’ class- there is some instructor-led explanation (aka lecture) and no traditional cases. Taking this class from 26 to 55 students, the single most important thing I improved for both scalability and student experience is bringing examples of student work into the class sessions as the central learning vehicle. For example, in Session 11 we run ~5 of the teams’ user tests and have time for comments and questions after each. Approaching the class sessions this way certainly improved my own learning and practice. There are notes on this in the individual class sessions.
I highly recommend a no-laptops, no-phones rule unless the students are on deck to present work from their laptops. With all the distractions those devices offer us and the harried nature of student life, a lot of students find it hard to maintain focus in class. It’s particularly important that they listen to each others’ presentation to create an encouraging, collaborative environment.
Assignments & Grading
Student Workload: The assignments for this class run ~90 minutes per class session. I’m always looking for ways to lighten the load on students and get them an equivalent (or better) outcome, but these are applied skill sets and I think there’s a certain basic necessity for students to invest substantial time in practice.
Cadence: At Darden, we have consecutive class days and in that situation it’s probably better to batch the assignments up weekly or thereabouts.
It is particularly important to avoid cramming/doing all the work at the last minute. The material is easy to understand conceptually but hard to relate to if you haven’t gotten your hands dirty. The items are tightly related as well. The student that waits until late in the game to catch up on assignments risks a major downgrade in their experience.
Templates & Tools: Templates and examples play a key role in making the class workable-the class covers a lot of ground, most of which is almost completely new to students. The templates’ job is to avoid pointless ambiguity about what best practice output looks like and just about all of the assignments above come with them.
The final output and most of the assignments happen on a Google Docs template, a working doc that encapsulates product-centric material for a new venture. I’ve implemented the template in Google Doc’s and it’s available here: Hypothesis-Driven Development template. Students generally work in teams where they’ll first complete the assignments individually and then converge to a group result together (following a classic divergence-convergence pattern from product design/innovation).
If you’re not on Google App’s, you’ll need to collect and share student’s Gmail addresses to do this (make sure this is kosher with your university rules, etc.). It is possible to make the doc’s available (read and/or write) to anyone on the Internet but not have them indexed. I think this is dicey, but I’ve seen students go this route.
Preparation & Systems: If you have a system like Canvas, it’s a great idea to get all the assignments up on the board in advance. I’m planning to publish a file to help with that for systems with a batch import function. See below, but, if you can manage the time, I highly recommend reviewing and supplying notes (via Google Doc’s) on each of the individual student assignments as they arrive
Use of Readings
In principal, I’d love to do a full flipped classroom, but it’s not realistic to expect that most of the students will do the readings. Given the novelty of the material and the pace of the class, even a small portion of the students (say 20%) getting behind on the readings is likely to create a downward spiral in student experience and outcomes.
Given this, the class material is designed to provide a solid but basic introduction to the topics. The readings are designed to deepen that understanding and act as a reference for the situation where a student struggles with an assignment.
Divergence-Convergence Pattern
The group project is a mainstay of graduate business classes and the final deliverable here (a Product Design) is a group deliverable. That said, most assignments are completed individually, peer reviewed, and then converged with the rest of the group’s work.
This may be confusing, vexing for students who are used to classical ‘divide and conquer’ mentalities. They may wonder why everyone’s doing the same thing.
There are two primary reasons. First, this is an applied/experiential skill. You can’t learn how to write a persona just by watching someone else do it. Same thing with a user test, persona, etc. Secondly, the divergence-convergence pattern is a foundation practice of design thinking/innovation. Innovation involves a lot of ostensible waste- lots of ideas are generated and few are chosen. That’s just part of the grind of creativity and innovation in real life. It’s work- not so different from everything else in that regard.
Grading
The following is a reference breakdown on grading:
| Category | Due Date | Percent of Final Grade |
| 1. Attendance, Participation, & Peer Reviews | Every day/ongoing | 30 |
| 2. Completion of Individual Assignments | (as stated on Canvas) | 30 |
| 3. Product Design- Team Project | Exam period | 30 |
| 4. Team Portfolio Submission | Exam period | 10 |
1. Attendance, Participation, & Peer Reviews: 30%
My objective is to provide a stimulating classroom environment for you to learn the process of software design. As you know, such a classroom environment results from a blend of course material, visitors, instructor input, and most importantly, student input. I anticipate high quality student input into our discussions despite the pressures faced by many second-year students in finding the right career opportunity.
I plan to be prepared for every class and expect you to do the same. I will try very hard to use the class time effectively and request that you do also. This includes starting and ending the class on time.
I expect you to inform me before class if you will be missing. Absences for reasons other than illness for which I do not receive prior notice will count against your class participation grade.
Since this class is fundamentally experiential and about doing (vs. just discussing), your work in peer review is an important part of your learning experience and grade. You will each have an assigned peer from outside your team and your peer review notes (as comments in the applicable Google Doc)
2. Completion of Individual Assignments: 30%
Product design and innovation are contact sports. You can’t learn it by watching someone else and so your individual work is very important and a critical precursor to successful group deliverables.
3. Product Design- Team Project: 40%
See notes above on course structure for more on this.
Ultimately, you’ll get the best overall result from a combination of strong individual execution and well considered group collaboration. Your final Product Design document (in the form of the template below) is the final deliverable for the class. There is no exam. The deliverable is due at the end of the exam period.
Teaching Notes by Item
A. I use a Google Doc and a Google Form to manage the list of available projects and signup’s, respectively. The Google Doc is available here: Software Design Project List. That doc has a link to the signup form, which you can copy. I screen all the student projects, emailing before the first day of class to ask for project in the submission format.
The only requirement I have is that the students has validated that the customer/user really does exist and really does have the problem they describe (in a material way). Depending on when and how you teach this class, taking projects out of, for instance, an entrepreneurship class could be a great way to screen. That is what I do between this class and the Software Development class that follow this one. ↩
B.At Darden I typically teach on an ‘early week’ schedule, which is 85 minutes Monday and Tuesday. The assignments are calibrated to (very) roughly 90 minutes of student work. I make assignments (and all large ones) due on the Friday we have class. The only exception is smaller assignments, which I make due the next day so they’re ready for use in class. These are typically items we’ve mostly finished in class. ↩
C This is something that’s in the intro. slides, but as an instructor you’ll probably need to continue to explain and reinforce: the diverge-converge pattern is ostensibly wasteful but that’s just how good design works. If you want to produce something really good, you have to try a few things and do some discarding ↩
Footnotes
1. Standish Group study reported by their chairman Jim Johnson at XP2002↩
2. http://www.zdnet.com/article/crm-failure-rates-2001-2009/; http://www.techrepublic.com/blog/tech-decision-maker/study-68-percent-of-it-projects-fail/↩
3. http://www.gartner.com/newsroom/id/2648515; http://fortune.com/2014/09/25/why-startups-fail-according-to-their-founders/↩
