Scheduling & Harmony

“What’s your schedule look like this week?”

I ask Jesse this question as least once a week as we build Kites & Ladders, a business to amplify the voices of people with autism through tools that support self-expression and communication.

Why do I constantly pester Jesse about his availability? (And spend too much time in Google calendar?)

Our first Kites & Ladders product is the Harmony wristband, which uses biofeedback to help people on the autism spectrum become aware of their emotional state and express it to others. Getting to that point where people can purchase the Harmony wristband, though, requires collecting a bunch of biometric data, testing various wristband form factors, and validating the concept with kids on the autism spectrum, their parents, and experts in the field. Not to mention drawing on the wisdom of a number of engineers and industrial designers.

This means our calendars have been quite full over the last 6 weeks.

Early on, we discovered that we couldn’t find the right combination of sensors or get access to raw data using commercial fitness trackers. So Jesse soldered and sewed and hammered and coded and tinkered to create our own prototype. We can now collect data about the wearer’s heart rate and stress level and process it in a number of ways. Meanwhile, I sketched shapes, interfaces, and buttons to figure out what the device could look like in a more polished form down the road.

On top of building, we’ve had weekly meetings with at least two or three engineers, industrial designers, and leaders in autism or educational organizations to continue learning more about autism as well as hardware development.

Then there’s the testing…

Testing the Harmony wristband prototype.

So far, we’ve visited 9 homes and worked with 11 kids (both autistic and not) who tried out the wristband. As the device captured biometric data, we hung out and watched Annoying Orange videos (you’ve been warned–they’re annoying!), went to the library, observed piano lessons, paged through countless photos of ventilation systems, sat through frustrating homework assignments, and witnessed everyday life while taking notes about the child’s emotional state and environmental changes.

Heart rate and stress level data captured during a test session.

Through this process, we’ve become incredibly passionate about and committed to working in the autism space. One expert we spoke with said an autism diagnosis is often treated like a lid, not a ladder. Through Kites & Ladders work, we’ve met incredible individuals with autism who have a lot to offer the world. The challenge is how Kites & Ladders can support these people in reaching their potential.

So we carry that into the final weeks in our program. Our calendars are still filling up as we reach out to new people, test and refine our prototype, develop our business pitch, and figure out how to produce the Harmony wristband.

But those blocks of time encourage us, propel us forward, and remind us that we’re doing meaningful work.

Innovation happens in hindsight

Our class recently read a series of articles that dealt with the relationship between creativity, knowledge, sensemaking, and strategy in design. As I went through the articles, a theme kept jumping out at me: Innovation happens in hindsight.

More accurately, I should say we recognize innovation and consider the design solution to be logical and straightforward (or as an obscure failure) when we look back. In Serious Creativity, deBono writes that if an idea does not appear logical in hindsight, we won’t appreciate it. However, he argues that this post-hoc reasoning means we place too much emphasis on logic and not enough on lateral thinking and creativity as the way to develop new design solutions.

In Discovering Design, Nigel Cross writes that, in contrast to fields like logic and science, “design initiates novel forms” through abductive leaps. The “solutions” a designer proposes don’t necessarily answer the “problem” in an expected, straightforward way. Good design is often surprising.

I wanted to create a simple visualization to process my thoughts around the place of hindsight, surprise, and logic when it comes to designing product ecosystems. I’ve mapped out the current state of a number of products and services in Google’s ecosystem in the current state, but many of these products have moved down the Y-axis since their initial launch as the surprise factor wears off. I could see using this kind of tool on my own projects in the future to evaluate components of a product system–and to remind myself that time judges innovation.

Innovative design solutions often come through surprising leaps of reason and make logical sense only in hindsight. Over time, the surprise factor drops as solutions either fade into obscurity or become more ubiquitous and utilitarian.

 

Wireframes, round 5 (done but never finished)

In our final Rapid Ideation and Creative Problem Solving class, we presented our fifth (and final!) iterations of wireframes for class scheduling and registration.

After four previous versions, I wasn’t totally sure what to do next. So I printed and hung each wire from Iteration 4 on the wall and I stepped back to look at the whole system. Though I kept multiple paths for people to add, browse/search, and drop courses, I stripped out many of the extra features. No more setting time preferences. Fewer filters. Only the catalog view to see course listings or descriptions (instead of an alternative view when starting from the schedule section).

Which brought me to Iteration 5. (Click image to download PDF.)

To test my wireframes, I set up a hyperlinked Keynote presentation so users could click through the prototype on a computer. While I discovered a couple issues where links weren’t set up properly (or where people tried to use the keyboard rather than click the “glass” keyboard on screen), I think the digital wireframes created a smoother testing process. Instead of trying to sort through and lay down one of 35-40 sheets of paper, I was able to pay more attention to user behavior.

Of the five strangers who tested the application for me, several finished and had a sense of, “That’s it?” As in, “Cool—I’m done? That wasn’t bad at all!” And the snags users did experience were mostly issues related to iPad conventions or elements better addressed by visual design.

So what did I learn from this class? I appreciate the process of iterating and incremental improvement on behalf of a user’s experience. I understand the value of Think-Aloud user testing (and approaching random people in coffee shops to get perspectives I likely wouldn’t get from people who know me). I learned the challenge of designing a comprehensive system as well as considering detailed interactions. I messed around with prototyping tools and templates ranging from markers and paper to print-outs to interactive digital mock-ups. I moved from a set of requirements to a rough thing to a more polished version to something that testers wanted to see made into a real application.

Finally, I learned the difference between done and finished. I could create 82 more iterations if I wanted. I could continue testing and tweaking. These wires aren’t finished. But I learned a lot about incremental problem solving, and I’m perfectly happy putting away these wires and being done with this project.

Iterate, Iterate, Iterate

We’re into our third iteration of wireframes to create an application that facilitates class scheduling and registration for our Rapid Ideation and Creative Problem Solving class (iteration 1, iteration 2).

This week, I took another pass at a feature that allows students to set their schedule preferences before searching for classes, since my initial scenario depicted a woman who is trying to maximize her time working toward a nursing degree while also working full time and being a wife and mother. I also continued to refine some details around editing/dropping courses and considered animations/transitions that commonly appear in iPad apps.

Here is the third iteration of the wireframes. (Click image to download a full PDF.)

My other focus with this round was conducting Think-Aloud user testing with five people I didn’t know. I spoke with students from UT-Austin as well as a man in a nearby coffee shop whose wife is a nursing student. As they tapped through paper printouts of the screens, they told me what they were doing, which helped me understand where some of my changes didn’t fit their mental models of how scheduling happens. (I also learned that it’s much harder to test with people I don’t know. They tended to get quiet when confused or frustrated, so I had to keep prompting them to “please, keep talking,” so I could understand what they were trying to do.)

So what did I learn in this round?

  1. Semester selection. Users frequently got stuck trying to plan Fall 2012 rather than switching to the Spring 2013 semester. I should just take them to the semester open for registration instead of the current term.
  2. Course suggestion. I added a feature that suggests courses based on the student’s degree requirements and schedule preferences. The slider interaction to add classes was used only by one tester—and that’s because he couldn’t figure out another way to add classes. I need to figure out whether to rework or drop the suggested course concept.
  3. Registration workflow. In this test, two users wanted to go through the schedule and registration process for one course at a time, rather than create a whole schedule and then submit the registration. I need to figure out how to support that workflow so they aren’t locked out of changing their schedule if they sign up for one class and then want to modify the schedule after submitting the registration.
  4. Create a digital, interactive prototype. There’s a disconnect between paper and digital prototypes. Where users might try tapping an iPad screen to see what happens, it feels more awkward in paper format. I want to create a hyperlinked prototype that users can interact with on an iPad or computer screen to see how that changes the experience.

This week, my big realization was around testing. While the iterations are important, I have a lot of room to grow in recruiting testers, developing scenarios for them to try out key features, and considering environmental factors that will lead to successful testing (noise/distraction levels, paper versus digital prototypes, testing at a table instead of an open seating area, etc.).

Wireframes, take 2

A couple weeks ago, I created my first wireframes for our Rapid Ideation and Creative Problem Solving class. This week, I developed a revised set of frames for an iPad application that facilitates class scheduling and registration.

I integrated feedback from testing and presenting the previous wires–especially problems with navigation and usability around registration and pop-up descriptions to compensate for interface decisions that weren’t self-evident. Since this is an iPad app, I also wanted to change the navigation so the app would work regardless of orientation.

Here is the second iteration of the wireframes. (Click image to download a full PDF.)

I tested these wires with three users using a Think-Aloud Test, where testers explained what they’re doing as they tapped through paper prototypes. Their descriptions helped me understand where the process didn’t flow as expected–as did the “Uhhs…” and pauses when they needed to reorient themselves to the screen presented before them.

So what did I learn in this round?

  1. Experiment with the schedule view. No one tried tapping the schedule to add classes based on time. Similarly, in my first iteration, users didn’t immediately know how to set time preferences on their schedule. I need to determine if this is a valuable part of the app, and if so, offer affordances so users understand what they can do.
  2. Streamline the “hero flow.” In testing, all my users defaulted to searching for classes through the course catalog rather than entering the process through the schedule view. Several screens were entirely unused in the tests, so I want to reevaluate the process to make sure it isn’t too complex.
  3. Refine details. I added some visual cues in this round–like showing the most recently added course as darker on the schedule, making the registration button an obvious option, and adding a status bar to indicate number of credits on the schedule. However, others features were not obvious enough; no one used the filter options for course searches, and one user wanted to slide the credit status bar like he does when he unlocks him phone. In my next iteration, I want to continue refining these details so they’re useful.
  4. Test with more users. I only tested with 3 users, and while I saw trends in the usability issues with my frames in this round, I know I would have had a better sense of the problems and opportunities if I tested with more people. I’m planning to retest this current set of wireframes with 3-4 more people before I dig into work on iteration 3.

I’m enjoying this process more and more–though I do think it gets harder with each iteration because the “easy” usability decisions have already been made.

The internet is more than a series of tubes

Before going on vacation a couple years ago, my husband and I bought a Kindle reader. Since then, I’ve also installed the Kindle app on my phone, iPad, and laptop. My Amazon shopping habits have changed, too. Unless I’m looking for a highly-designed book or a reference text that I’ll refer back to frequently, I always check to see whether the latest novel or business book that attracts my attention is available on Kindle before deciding whether to buy.

This coming from someone who works in publishing, holds a library card, and hates to see small bookstores close.

But I turn to Amazon repeatedly because the Kindle is one part of an incredibly effective ecosystem. I don’t always love the Kindle device itself; taking notes can be tedious, and I rarely return to the passages I’ve highlighted. I have a love-hate relationship with Amazon’s one-click solution that simplifies the checkout process at the same time it decreases the amount of money in my bank account. Despite my complaints, Amazon has a huge selection of books it can deliver to any of my devices in less than a minute. Their attention to delivering value across an entire system outweighs the shortcomings of individual parts and keeps me coming back to use their services.

This personal experience with a cultural shift toward digital publishing kept popping into my head as our class explored the changes in traditional systems thinking to contemporary uses in design applications today.

Several decades ago, discoveries in physics and the industrial, mass-manufacturing model defined the language of how we thought and spoke about systems. Systems were mechanical, contained, ordered efforts. Some systems were complex, but they still had inputs and outputs, logical hierarchies and central controls. (See Hugh Dubberly.)

I remember a few years ago when Senator Ted Stevens used rudimentary, mechanical language when he referred to the Internet as a “series of tubes.” Ultimately, he spawned an Internet meme, teased by people who had a sense of the complex, networked, and dynamic structures that enable people to go online and communicate across the globe.

Today, there’s a shift toward organic, biological language when we’re talking about systems. The Internet is a web. Software has bugs. Computers get viruses. Products have ecosystems and lifecycles. Information flows like streams or rivers. Designers consider sustainability. Networks have become less centralized and more “organic.” (Interestingly enough, even the notion of a “meme” grew out of concepts in evolutionary biology.)

In parallel, the field of design has increasingly moved toward user-centered and participatory design methods in order to address large, messy, “wicked problems” like hunger, climate change, and poverty. Which brings me to the work we’re doing at AC4D this year—trying to tackle wicked problems in education.

When I look at the current state of education in the United States, I see a parallel with the changes happening broadly in the field of design and systems thinking. Schools and districts and states and national standards are parts of a complex web that make up our educational system. Just as systems thinkers are moving from mechanical to biological language, I think our educational system should move away from traditional industrial approaches (like funding schools based on which bubbles students fill in on standardized tests) and instead consider what other methods might prepare students to work in fields that are just starting to grow or haven’t developed yet. (Again, more organic language.) Doing this may mean the teacher’s role changes as well, much like the designer is becoming a facilitator within a system rather than an author creating something for others.

Much like Amazon and the Kindle, not every component of the education system will work flawlessly. However, using systems thinking, especially with biological language, may offer a better starting point to address problems in design and in education.

If at first you don't succeed…(with wireframes)

“So you made a thing…”

We’re only three months into our program, and many of the things we’re making right now are not very good. Jon Kolko frequently uses the above phrase to preface a longer statement about how it’s important for designers to externalize concepts, design ideas, and propositions. Sketching, building, and prototyping ideas make it possible to poke and stretch them in ways that make the resulting product or service much stronger.

Which brings me to our Methods class for quarter two: Rapid Ideation and Creative Problem Solving. For our first assignment, we were tasked with developing wireframes* for an interface that helps students to plan their class schedules online.

To tackle the project, I started with a scenario about a student who wanted to plan her schedule on the go from her iPhone, but I quickly realized how challenging it is to design a system for such a tiny screen. (Especially with very limited wireframing experience!) So I shifted to developing for an iPad version.

Here are the wireframes I developed after multiple iterations. (Click link or image to download a full PDF with annotated wireframes.)

My process started on paper with scenarios, storyboards, and rough sketches. Through Sharpie drawings on copy paper and conversations with classmates, I tried out different configurations and got feedback on what was confusing. After sketching over 30 or 40 screens by hand, I started turning my hand-drawn interfaces into digital ones (using Keynote Kung-Fu) and added links so my five users who tested using the a think-aloud method were able to click through like they were operating a real app.

So what have I learned so far?

  1. Start with fewer details. I tried to draw in a lot of detail in my storyboards and the first round of iterations, which made it harder to throw out some of the pieces that weren’t working well.
  2. Play with more iPad apps. Through my testing, I discovered some of my layout choices didn’t fit with iPad conventions or users’ mental models for how the interface should work. I’m going to adjust these in the next round of iterations, but I also need to spend more time exploring apps to see how other developers handle similar issues.
  3. Don’t make people read. I had some messages on screen to help users know the next step, but the testers tended to experiment rather than read. My future iterations need to make the steps more obvious without the explanatory text.
  4. Provide feedback. “Am I done?” was asked by more than one tester. I need to think through how to offer visual indicators so users know where they are in the process and understand the outcomes of their taps and swipes.
  5. Make decisions so the users don’t have to. My first iteration allowed users to choose class by setting their preferred times on a schedule. But they can also browse the full course catalog. This was unclear for most of the testers, so I need to resolve the conflict in approaches so the user isn’t confused. And more broadly, the designer should make intentional decisions that make the experience better for the majority of users rather than building in “flexibility” that just leads to confusion because the designer didn’t want to take responsibility for focusing the interface.

While this process felt overwhelming and tedious at first, it became more fun the further I got into the wireframes and testing. I guess that’s a good thing because we’ll be iterating this same series of frames five more times!

And maybe by the end of the quarter, Kolko will end his, “So you made a thing…” phrase with, “and that’s actually something someone might want to use.”

(Wireframes are sort of like rough blueprints for a digital interface–using real content but stripped of design elements so the focus stays on designing the controls, navigation, and relationships between content and features, rather than emotion or design elements.)

Deconstructing Difficult Problems

For our final position diagram of the quarter, we were challenged to show the difficulties in solving complex problems. I drew inspiration from readings by Herbert A. Simon, Amos Tversky/Daniel Kahneman, and Philip Johnson-Laird and put together this visual, in which I argue that designers can employ constraints and bias to make ill-structured problems easier to address. Then through iteration and inverting bias, designers can generate insights to address portions of the problem. All this while still keeping in mind how those solutions contribute to the whole system.

I realize most ill-structured problems may never become well-structured enough to solve with brute force or computing. However, a process of refinement and iteration can make it easier to start tackling complex, amorphous problems.

Moving from Exposure to Experience

For our theory class this past week, we read a number of pieces oriented around (a) human experiences and technology, (b) society, community, and privacy, and (c) design in developing countries. Our challenge for our third position diagram was to “show the changing nature of designed culture, based on the increased presence and ubiquity — and acceptance — of technology in our lives; show the differences between applying this technology in the US, as compared to in a developing country.” I synthesized several of the readings into a proposition for moving from exposure to experience:

[slideshare id=14590010&doc=exposuretoexperiencev2-121004103245-phpapp01]

The Power of the Participatory Interview

A couple weeks ago, our class learned first-hand how to conduct a form of research called Contextual Inquiry. In this approach, the researchers partner with a participant to see them in action as they work. The goal is to observe and ask questions to understand why people do what they do–all within the context of their working environment.

Contextual Inquiry is a great way to notice workflows and breakdowns, but it’s not necessarily as helpful in revealing the participant’s hopes and wishes for what their work could look like.

That’s where another research method, the Participatory Interview, can come in. Participatory Interviews go beyond a typical interview by inviting the participant into a creative process. The interviewer offers tools and stimuli that grounds the participant in their current experience while helping them dream about what the ideal one could look like.

For our Participatory Interviews, Eli and I refined our research focus. When we visited Special Education classrooms for our Contextual Inquiry, we heard from at least one teacher that incorporating assistive technology at home could make a big difference in the classroom. We also observed technology used for education and communication with a student diagnosed on the Autism Spectrum. We also thought parents likely have high hopes for their children and would be very vested in seeing them learn and develop. On top of this, we discovered a network of organizations in the Austin area that offer support services for families of people diagnosed with Autism, so we decided to focus on interviewing parents of people diagnosed on the Autism Spectrum who use assistive technology to communicate.

The Participatory Interview process itself was exciting, fun, and pretty natural. We spent time preparing some activities, words, and images to help facilitate the conversation. As anticipated, the interviewees had a lot to say, and the main task was guiding the conversation to go deeper into understanding not only what the person wished for, but why.

Here are a few things we learned along the way:

  1. Participatory Interviews are fun. We thought it might seem uncomfortable to ask someone to talk through images or words (or have another person type out copious notes), but the conversation felt natural. We learned a lot, and the interview was an enjoyable and energizing way to better understand our focus.
  2. This method takes time, preparation, and flexibility. We spent quite a bit of time revising our focus, lining up interviews, developing a journaling “homework” assignment, developing key questions, finding additional image and word stimuli, and practicing the interview. Plus a couple hours with each participant. And even with all the preparation, the conversation sometimes took a different direction than we anticipated. (Which is probably a sign that the method works!)
  3. Pictures are powerful. We were excited to see how an abstract, simple photograph provided a springboard for deep, thoughtful conversation about what the person wished and hoped for.

We still have a couple more interviews to complete and are considering reworking the journal a little bit to make sure the language and approach is understandable and it’s easy for the parents to return. We could also do a better job preparing the participant to know what to expect before the interview. During the interview, we can be more directive and interject with follow-up questions and summaries to make sure we understand what the participant is communicating. And finally, we continued to refine our focus as we started searching for participants, and having that established sooner probably would have made it easier and faster to line up the interviews.

Overall, though, we got a sense of the challenges and hopes that some parents have when it comes to technology helping their children communicate and learn. And I’m convinced that Participatory Interviews should become a regular part of my research as I’m working on new products or services.