Abductive inference and sense-making

In our latest batch of readings for our theory class, I was particular interested in deconstructing a lecture from Charles Pierce. He is considered “the father of pragmatism.” Given that he is a philosopher and logician, his lecture, “The Three Cotary Positions,” is particularly thick, and I found difficult to parse: which made it a great candidate for using diagrams to make sense of it! This brought to mind another reading, “Organizing and the Process of Sensemaking,” by Karl E. Weick, Kathleen M. Sutcliffe, and David Obstfeld. So in this diagram, I’ve woven together both concepts to describe a process and relationship between abductive inference, synthesis, hypothesis testing, and sensemaking.

Click to download a PDF version

Designing for Emotion

In IDSE302: Theory of Interaction Design and Entrepreneurship, professor Chris Risdon asked for a position diagram on the role and importance of technology in the world based on the last few weeks of readings. I used that theme as a jumping off point. In fact, technology, especially computing, is practically inescapable now. In the past, traditional HCI was approached from a positivist, rationalist way. But we now understand how important designing for emotion is, especially if you are trying to create products and services that can create and impact social change. What are some approaches that we can use as designers to account for emotion when building for impact? (Download as PDF)

Designing for Emotion

Course Scheduler: A Fond Farewell

This is the last iteration of our course scheduler wireframes for IDSE201, in which we bid a fond farewell—or good riddance—depending on how the process went. I must admit that this iteration and the last one were a complete struggle. The last iteration didn’t change much, but this time I found a little bit more inspiration and landed on something that I felt balanced the simplicity required for the user experience and that degree planning is pretty complex no matter how you slice it.

Once you cut through standard degree requirements, there’s not a lot of room for variation. The most room one has for adding courses is in a major, and that’s pretty much constrained by department. So this version of the scheduler organizes the classes you need to take in buckets wherein the range of choices is not particularly huge. I’m not totally satisfied with the handling of required classes versus pick one (or at least n) of the following courses.

During testing, all my participants were able to easily work their way through the flow, going from an empty schedule to a completed semester. Only the print and export buttons were somewhat hard to find, and surely there is a better way to say export, like “send to calendar,” but that fits in a button!

Jon Kolko says we go through the pain and frustration of interaction design so that our users don’t have to. Point proven.

The latest iteration of the course scheduler is available in PDF or Flash formats. Note the Flash version is manually controlled with forward and back buttons in the upper-right.

Course Scheduling: Incremental Iterations

The gap between the second and third iterations of my course scheduling system was pretty big. That was necessary to fill in major pieces of missing functionality and fix some very broken interface elements. But the last iteration worked very well in testing, so this round has more minor revisions to it.

Things to look for are a cleaner schedule view with more legible typography. Changing sections brings up a modal dialog which puts the focus  on finding a new section. This dialog also identifies sections that are in conflict with the existing schedule and prevents a student from adding them.

In the degree view, added courses were appended underneath the individual requirements tabs. This didn’t work for a couple of reasons. First, when courses were added, the user had no indication that they were added or where they went. Once many classes were added, there was way too much scrolling involved to find them. Secondly, the tabs imply that the courses are filtered by core, major, or minor which is true for the requirements, but all scheduled classes were shown regardless. In this version, there is now a default “my degree plan”  tab which shows the scheduled classes. This alleviates the scrolling and inconsistency.

Looking to the next iteration, I’m considering ditching the entire degree view, sticking only with the schedule view, and moving the requirements tabs into a modal course selection flow.

Course Scheduling: Reducing Steps

After the last iteration of the course scheduler wireframes, I was given the feedback to be boring: focus on “simple, clean, and easy to use.” This is the latest result, both in an interactive Flash prototype, and in PDF format.

At the beginning of this iteration, I went in search of college degree plans mainly for content to use (since one goal of wireframes is to use real content, not just lorem ipsum). What I found is that in traditional undergraduate degree programs, students don’t actually have a lot of choice. At least half of a typical program is satisfying fairly specific requirements, and once you factor in prerequisites for electives, there’s a fairly prescribed path.

The process of figuring out a degree usually involves checklists from advisors, and in my experience, managing your plan in Excel. So in this round of wireframes, I’ve flipped the problem around. Rather than giving someone a blank schedule and letting them figure out what they need to do, they are given that degree requirement checklist. Picking a requirements brings up a list of related courses. Even in a large university with a ton of classes, most requirements aren’t going to have a huge list of options within a specific semester. For example, this is a degree checklist for a BA in Comp Sci at UT. The largest set of course options will be upper-division electives for computer science, but this is not a huge list and certainly doesn’t require lots of filtering or search options.

After picking the course, then the student is given a list of sections and some key factors through which to compare them: date and time, professor, and location. At any time, the student can switch from the degree plan view to the weekly schedule to see how it’s all shaking out.

By making the key starting point of the interface the degree plan, the application complexity is significantly reduced. That said, user testing revealed two main flaws: the schedule view is small and hard to read. The schedule view is where you can currently drop a course or change sections, but several users wanted to do this from the degree plan area. Also, the planned courses in the degree plan should move into another area, as currently the user must scroll a lot to get to it, and may not see newly added classes. Overall though, I feel this is a much stronger direction than the first two iterations.

Course Scheduling: A Simpler Approach

Revised Prototype

After the first iteration of our wireframes for a hypothetical course scheduler, I felt the results were fairly complete. Unfortunately, the “information density” was extremely high. (See the previous iteration here.) Fair criticism.

So on for this second iteration, rather than finish out the functionality, I decided to start with a new concept. I tried to ruthlessly cut as much functionality as possible. But as a result, I had to use techniques like progressive disclosure, wherein the interface shows a low level of detail at first, but as you interact with it, details are revealed only when relevant. For this to work, the user needs to have extra clues to interact with areas of the interface. In this case, these affordances take the form of gradients and shadows which help communicate which areas are clickable by giving them the look of buttons.

Tools like Keynote, Omnigraffle, and InDesign didn’t quite have the functionality I needed to demonstrate or test the interface. My options were HTML/Javascript or Flash. HTML/Javascript would have taken too long, so I chose Flash. Only one hitch: I didn’t know Flash. So thanks to a few helpful classmates and faculty, I learned Flash as best I could in a week. That experience is a whole other story, but for now, check out the interactive prototype I built with it.

It’s not perfect; think-aloud testing revealed some obvious gaps where users weren’t quite connecting which areas they should explore. The question is do I need to create more detailed visuals to communicate the affordances, try different techniques, or scrap the idea altogether. I haven’t decided yet, but the time allotted for our remaining iterations will be less than it has been, so it won’t be long for you to see the results!

Wicked Systems

As designers ready to work on wicked problems, we face a dilemma. Wicked problems are inherently unsolvable; we must break them down into pieces, into more well-structured problems. At the same time though, we must seek to understand how our products, services, and businesses fit into a bigger system and scheme.

This big picture view is called systems thinking. You’ve probably heard “the whole is greater than the sum of its parts.” In which case, you understand the principle of systems thinking at its most reductive sense. More correctly, the whole is the sum of its parts plus the interactions between all of its parts. That may seem obvious to us now, but it wasn’t til the 1930’s that general systems theory began to be codified by people like biologist Ludwig van Bertalanffy.

“It is necessary to study not only parts and processes in isolation, but also to solve the decisive problems found in organization and order unifying them, resulting from dynamic interaction of parts, and making the the behavior of the parts different when studied in isolation or within the whole.”
—Ludwig van Bertalanffy

Systems thinking was brought to the design field by design theorist Horst Rittel who had a background in phyics and math. His interest in cybernetics and feedback systems helped him apply science to design. Later, he revised his approach to “second generation design methods” and coined the term “wicked problems.” One defining characteristic of a wicked problem is that stakeholders disagree on the nature of the problem and solution. Therefore, design is a dialogue, an argument, and inherently political. In these methods, Rittel called for user involvement and participation in solving design problems

Last quarter, we read Herb Simon’s “The Structure of Ill-Structured Problems.” Although he was discussing its application to artificial intelligence, we understood that wicked problems are a type of ill-structured problem. Designers break these down into more solvable issues, often by adding constraints. As part of the service design class this quarter, we read an excerpt from the book Out of Control in which Rodney Brooks’ approach building microbots is described. It follows a similar pattern–break a complex problem down by adding constraints.

Brooks initially tried to build robots with a central computer, or brain, to handle “simple” tasks like walking. Yet this was a type of ill-structured problem, and the robot named Ambler coud “barely walk without tripping.” So Brooks changed his approach and started building microbots that were closer to insects: autonomous with simple reflexive actions. He applied this concept to a new robot named Ghengis. Each leg was contained an autonomous system, all loosely coupled together. Even if one leg failed, the others could keep working, so the system was resilient.

In information technology, there is a similar approach called a federated architecture. Small software components are given as much autonomy as possible and loosely coupled. The systems talk via syndication, in which information is passed via a standard protocol to all systems, and it’s up to the individual components to do what they will with it. Usually these components are known as agents, and groups of similar agents have a “facilitator” that’s responsibile for handling their communication with the greater system. This builds resiliency and flexibility into the system.

What does this all mean for us when designing for wicked problems? We must see the big picture and understand the whole system, yet at the same time decompose our designs and solutions to smaller managable pieces. While we design systems, we ourselves, our users, and stakeholders are all also parts within a system. However, we cannot be conveniently federated into groups of agents and facilitators. To design for wicked problems, we must spend some of our time designing not just solutions to problems, but also how to collaborate and provide feedback to other designers, across displines, and between the communities for whom we design. Without coordination and communication, we are all just contributing to a system that blindly stumbles around like Ambler the robot.

Improving Course Selection and Degree Planning

(Click to download full version in PDF format)

In our Rapid Ideation and Prototyping class, our assignment this week, and for the next eight weeks, is to design an online application for planning and tracking school classes. In the initial pass, we develop personas (“fictional characters created to represent the different user types within a targeted demographic“), scenarios (written statements of a userflow), storyboards (a comic strip like approach to show a person using the product or service), and wireframes (pictured in the header image above) that describe the functionality of the product’s digital interfaces.

In developing the wireframes, we start with very low fidelity sketches, then re-sketch them several times, each time increasing the level of detail, eventually finishing up in a digital tool like Illustrator, Flash, Keynote, or Omnigraffle. During these iterations, we will start testing with potential users to get feedback and identify problems with the interfaces. The type of testing we do is called Think-Aloud Testing. The user is given a task or goal to complete, and they work through the paper or digital prototypes talking through what is going through their minds as they attempt the task. With just a few short sessions, most of the glaring problems with a product can be found.

After this initial first pass of wireframing and testing, we’ll iterate five more times over the course of the quarter. You can download my first pass as a PDF.

The good news is that my test users were able to search for and add classes. However, they discouraged by the messaging of “no results” when over-constraining a search, so the system needs to help users unconstrain the search either explicitly (by removing options) or implicitly (by showing related or similar matches, or correcting misspellings). Users did not understand the bookmarking icon and how it related to the functionality for comparing classes, so a more standard icon needs to be used and animation can add affordance to how the functionality works.

Users were also unclear if they were just planning classes or actually registering for them: in addition to clarifying this, the system will need to work differently depending if a registration period is open or closed. Finally, additional screens need to be created to articulate error or conflict states (for example, the user attempts to add a class where prerequisites are not met, or it does not fit their schedule). This opens another can of worms: should users still be allowed to add conflicting classes? Or should there be hard constraints? Should I just make a design decision? Or should I prototype both options and see what happens next in user testing? I don’t know the answers just yet, but stay tuned for the next post by November 20th to see the next round of results.


Subtle Progress

For our IDSE201 Rapid Ideation class, we’ve been tasked with really noticing digital user interface elements in fine-grained detail and discuss why it works—or doesn’t.

To the left is an icon in iTunes (if it’s not animated, click the image to open it in a new window). If you subscribe to iTunes Match, each time iTunes opens, it connects to Apple’s servers in order to synchronize your music collection. Naturally, when you start iTunes, you probably want to listen to music immediately rather than wait for this to complete, so iTunes connects in the background. But it’s still useful to know that the connection is being made. Normally, as an iTunes Match subscriber, you’ll see a white cloud just the right of the “Music” text. When the connection is being made and music is synchronized, the cloud changes from white to an animated set of diagonal lines to give you a visual indicator that something is occurring in the background. When synchronization completes, the icon restores to solid white (or may contain other icons inside the cloud to indicate error states).

To the right is a detailed blow up of the cloud icon when it’s in progress. One of the nice touches is that the diagonal progress lines appear in the background as if the cloud were a cutout revealing inner workings of a device. This reinforces the idea that the operation occurring is in the background and a maintenance operation. Again, it’s not important, but may be useful. It’s this level of attention to detail that gives a product polish. It’s unfortunate, though, that the icon jumps a few pixels to the left when restoring to the white cloud, and a few pixels to the right when it shows the in progress state.

Position Diagram 4: Experience, Bias, and Designing for Difficult Problems

This is the final diagram for Jon Kolko’s class, “Design, Society, and the Public Sector.” Like the last diagram, this artifact had to stand on its own with little explanation or exposition. Additional parameters were placed on it as well: “pithy, succinct, small.” Given that most of my previous diagrams relied on narratives spanning 6 to 16 panels, I was up for the challenge.

Diagram 4: Experience, Bias, and Designing for Difficult Problems