A Paper Prototyping Workshop

Recently, I had a chance to sit in on a Paper Prototyping Workshop presented to a group of high school kids.  Here's the workshop description:

"We'll learn about design thinking and prototyping and then guest speaker Daniel Wood, UX Designer at Liquid Agency, will give us tips on designing a user interface.  For the rest of the session we'll launch into a series of hands-on exercises that will guide us from brainstorming app ideas through creating paper prototypes to testing our user interfaces with real users."

I had two reasons for attending the workshop.  A secondary goal was to see if I could get any tips for improving the way we use paper prototypes at work, but my primary goal was to see how to conduct a full-day workshop. Previously, I had conducted one-hour exercises at work but I was about to help with a full-day workshop at PNSQC in the fall of 2016, and I wanted to understand the arc of a multi-hour session.  This blog post documents the workshop, and adds some observations about the paper prototyping process I plan to document the workshop, but also to make some observations about 

Step 1 - Understand the problem space

The kids heard heard a short 15-minute lecture from a UX design expert, then spent the rest of the hour generating ideas for apps. The kids were asked to list sets of users (such as "gamers," "pet owners," or "elderly people"), various industries ("medicine," "entertainment") and technologies ("mobile," "VR," "IoT"). They wrote these ideas on sticky nodes and then combined the notes to create ideas for apps.

Often software systems are generically called "solutions" because they are built to solve a problem.  Identifying and understanding the problem early is core to developing a good solution. The lecturer pointed out that to provide a good solution, the designer must understand the audience. He suggested the kids use empathy to put themselves into different viewpoints -- seeing from the point of view of the user.  He also suggested that design concepts should be kept small, digestible -- easily understood.  At this phase of design, don't try to invent new concepts.

Steps 2 & 3 - Generate and share ideas

Next, the kids listened to a talk about storytelling, then broke into small groups where they could agree on a set of ideas they wanted to work on. Storytelling and sharing ideas is a fairly simple process with a large benefits.  First, you have a story to tell, and by telling the story it helps shape your ideas into fully-formed concepts that others can understand. Also, you can see how other react to those stories and whether there is a common concept that excites interest in the solution.  Others on the team will have different viewpoints and may have suggestions that strengthen the story, or ideas that will push the story into a new realm.  This storytelling phase is key to forming a complete vision of the solution.

Although it was fairly free-form, kids liked this portion of the workshop. The open-ended space allowed them to imagine and follow odd tangents.  During their discussion, some of the stories evolved. But the limited time (1 hour) helped frame the session and to eventually focus them on a single solution for their groups.

Step 4 - Develop disposable paper prototypes

Finally it was time to create the paper prototypes. The kids grabbed paper, crayons and markers, scissors and string to create the UI for their app prototypes.  The adult coaches ranged around the room providing advice about standard UI components and suggestions for how to work as a team.  The kids innovated in all sorts of ways: folding paper, gluing together "buttons" and literal drop-down pick lists.

This segment reminded me that a successful workshop needs to have all the materials on-hand and ready.  If you're going to use sticky notes, make not to run out.  Not everyone brings writing implements, so have plenty of pens and markers on hand.  Try to predict the needs of the students in the workshop.

This session left lots of space, so the kids were free to take breaks or use the restrooms.  Remember: breaks are important.

Step 5 - Test and iterate the design

The final leg of the workshop was the rapid iteration session. Kids shared their "apps" with each other and the experts.  Sometimes the workflows didn't work as expected, so they revised the prototypes and retested them.  The key was to get a large set of tests and opinions in a small amount of time for relatively little investment.  The kids were encouraged to discard solutions that did not work, or were potentially problematic.  After this session the kids gathered to reflect on the day's work and share their thoughts and insights.


From this workshop, I gathered several key takeaways:

• Lecture is good for a basic understanding, but hands-on learning seals the deal.
• Provide space for ideas. Don't expect participants to be 100% efficient as they learn.
• Don't expect to do more than one exercise per hour, unless the second exercise builds on the results of the first.
• Provide any supplies that might be needed. You don't want to interrupt the session to track down paper and pencils.
• A full-day workshop can be intense and possibly fatiguing. Breaks and food help keep the energy going and keep everyone happy.
• If possible, ask people to help document the workshop by tweeting or taking photos

Thanks to Gage Choat for allowing me to sit in and observe the workshop.

PNSQC 2016: Day 2

Here are my sketchnotes for the second day of the Pacific Northwest Software Quality Conference (PNSQC) 2016 held in Portland, Oregon in October.   Click on an image to see the larger version.

For the opening keynote on the second day, Rex Black not only spoke about "Stupid Metrics Tricks – and How to Avoid Them" but decided to stage a live recreation of Dr. Edward Deming's Red Bead Experiment.  If you have never heard of this experiment in tracking quality metrics, check out the video of Rex's presentation.  The participants failed to manage quality, which meant the experiment had some interesting outcomes. Then he attempted to answer the questions "What are the most common metrics mistakes?  Why are they mistakes?  Why do people make these mistakes?"

After the keynote, I switched over to the Developer track to catch Justin Wolf from Cisco systems talking about "Automated Testing for Continuous Delivery Pipelines."   As the blurb said, "In our product, we use Gerrit, Jenkins, Gulp, Protractor, Jasmine, Docker, and Kubernetes...to perform automated testing on every release, execute long running soak tests, and support rapid iterations on deep performance tuning activities with complex cluster configurations."  Justin's presentation was a little daunting, but mostly inspiring: His team is showing the direction for managing automated regression testing during releases in an Agile environment.

I also wanted to catch "Don’t Forget Security When Delivering Software," presented by Kiriakos Kontostathis from the Software Engineering Institute (SEI).  "We are starting to see a new set of security testing tools that offer easy integration into existing delivery optimization tools."  I had helped review the presentation, and was eager to see how the audience received it.  Kirie did a great job, and covered all aspects of security in the software development pipeline.

The closing keynote was delivered by Darlene Bennett Greene, a retired US Navy Commander and former VP at McAffee. Similar to Peter Khoury's opening keynote, her presentation emphasized communication and leadership as key skills for anyone who works developing software systems.  Because the talk was so broad, I found it difficult to fully sketchnote "Cultivating a Champion Mindset and Skills to Dramatically Improve Your Life."  Instead I let myself listen to her words, and then captured a few key points. The most surprising? Only about 20% of US workers are engaged in their daily work.  She urged leaders in companies to open two-way communication with employees and really learn to listen to their needs.  As she said, "the top factors that bring success to people and companies are rooted in communication and leadership."

The theme of the 2016 PNSQC was "Cultivating Quality Software," so did I have any inspiration during the conference to cultivate anything? Yes.

I resolve to to read or listen to at least one of the speakers that I don't recognize _before_ the conference starts. This year I managed to read one of Rex Black's books conference. He is such a prolific author I was surprised I had not ever read a single of his books. Reading is a good way to get to know the speaker and have some relevant questions, or at least, have something to discuss during coffee breaks.  

If you don't have time for reading, try a podcast.  I only got a couple chances to speak with Brian Okken, but he was interesting enough that I decided to check out his podcast on Python Testing.

By engaging with authors and speakers before meeting them, I will have the chance to cultivate my ideas and also create better connections. Personally, during the year, my resolution is to also work on growing my communication skills: written, verbal and drawn (mostly verbal).

Thanks again PNSQC for an energizing and inspiring conference.

Click here to see Day 1 of PNSQC 2016.

PNSQC 2016: Day 1

The theme of the 2016 Pacific NW Software Quality Conference (PNSQC) was "Cultivating Quality Software."  This theme alludes to how each phase of software develop necessarily contributes to quality, much like digging, hoeing, watering and weeding all contribute to the quality of the plants and vegetables in a garden. It can also refer to the NW software quality community: how presenters and attendees can work together to cultivate future thought leaders and innovators while tending our own "garden."

I tried to document through sketchnotes some of the keynote speeches and invited speakers, as well as a few selected technical paper sessions. For any of the sketchnotes, click on an image to see the larger version.

Peter Khoury from Magnetic Speaking opened the the conference with a presentation called "From Software Tester to Leader: How to Take a Radical Leap Forward at Work." Key to the idea of cultivating leadership at the conference, Peter's talk pointed out that "public speaking skills represent an essential element in the career of any engineer who aspires to rise high within the corporation," so in order to become a leader one must learn to communicate in a way that demands to be noticed.

Next up was Invited Speaker Johanna Rothman spoke how to "Deliver Quality with Agile & Lean." Johanna is an influential speaker on project management and the author of many books. Years ago I took a workshhop from her, and was curious to see what he had to say about integrating Lean concepts with Agile project management. Her talk was billed as "how agile and lean limit the batch size by either limiting scope or work in progress, and how each can help." She covered some of the nuances of Agile+Lean, but the key takeaway for me: keep tasks small - nothing larger than a day, preferably a 1/2 day.

Unfortunately I missed Brian Okken who was the afternoon invited speaker. He discussed "How Testing Strategy can Increase Developer Efficiency and Effectiveness."

Instead, I was drawn to a couple talks in the Developer track.  Ruchir Garg of Intel Security presented "Third-party Library Mismanagement: How it Can Derail Your Plans." Bottom line is that when third-party libraries are not managed in an organized manner, developers use and include numerous external libraries, without giving attention to their maintenance customers end up running third party libraries that are obsolete or possibly vulnerable. Ruchir presented a number of considerations for managing third party libraries.

I was looking forward to the talked "Innersource: Open Source for Test Automation" by James Knowlton of NAVEX Global.  Prior to the conference I had the opportunity to work with James and review an early version of his presentation.  I had never heard of the concept of Innersourcing based on the book “Getting Started with Innersource” by O'reilly, (hint: think of Opensourcing, but using company employees as the code community) and it seemed like an clever innovation for a tough problem. Read the paper, it's an interesting story.

I ended the first day listening to Eric Thompson from Puppet Labs answering the question "how do we retain top quality talent in QA? In software engineering there are many studies that support “three pillars” of motivation: Autonomy, Mastery, and Purpose."  His talk, titled "The Three Tenets of Engineering Motivation," gave some good ideas on engaging employees.  Interestingly enough, Darlene Bennet Greene, who gave the closing keynote on Day 2, also touched on the subject of engaging and keeping employees in highly technical work environments.

Click here to continue to Day 2 of PNSQC 2016.