Class Schedule App – Iteration V3

Over the last five weeks, in our Rapid Ideation and Creative Problem Solving class, we have been working on a making a web app that helps students sign up and schedule classes for college.

First we start with a general design & layout, then user-test it, then go back and integrate that user feedback into the next iteration. And repeat.

This is the third iteration, and definitely my favorite so far. But that makes sense, right?

You can view the annotated slideshow here.

You can see the entirety of the wireframe here.

Wireframes: Iteration #3

For the 3rd set of wireframes I worked through a lot of methods for the search system. Some of the feedback I received said that the elements seemed to float about the screen, so I made a sorted effort to make them feel more embedded into the frames. There were a few questions about how to get information on the actual class so I added a few elements to make it easier to get quick access to class synopsis’s.

Click HERE to view the full set of Wireframes.


Course Registration – 3 steps forward, one step back

In this last iteration of wireframes, I implemented a revised course filtration system that eased what was previously a pretty daunting and crowded ‘starting point’ screen. It’s a totally new way of discovering classes, enough so that it was ‘back to the drawing board’ for me. Though it hurt to do so on a third iteration (and impacted the ‘polishedness of the result’), it happened. I found a lot of value in actually laying out the flow in individual pieces before jumping back into the tool.

These screens were built in Adobe Proto and, while systematically more sophisticated, are not as clear to read as the last version. Next time around, I’ll venture into InDesign to fully realize the hopes and dreams of these wireframes.


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.

Natural Habitats

This evening I went out for food in a recently reinvented sushi restaurant on South Congress. I asked the host about some of the design decisions as while he brought me to a seat. “It’s really much better for everyone involved,” he explained as I slid my chair under the table, “the servers, the customers, and the kitchen all have less work to do and we all like it better.” “Wow,” I thought to myself, “what an interesting metric for a job as dull as serving tables already is.” In my experience other places, waitressing had mostly been hours filled of scavenger hunts for something to do, the jackpot of discovering the sugar packets needed to be refilled could fight off the beast of desperate existence-questioning boredom for at least ten more minutes of the shift. I pressed the server to explain himself, “Now we just do work when it’s needed. See? If a customer wants their server, they just press the ‘Server’ button right here. It’s just more natural.” He points to the screen of the iPad on my table, the same as the one on every table in the restaurant.
This restaurant used to be called “Zen;” a quiet, take-out oriented, sushi-fusion, low-cost establishment on the medium-high end of the lowbrow food scale. It was not an ambitious place. Customers ordered at a register, the same person who they ordered from set their food on the counter when it was ready while hollering out their name, and that same person wiped off tables occasionally. Half the food was pre-made and all of it came in take-out containers for convenience. Though the business has not changed hands, it appears the owner has had a change of heart. Now renamed “Lucky Robot,” the atmosphere is at once upgraded by the large liquor bar and futuristic hanging lighting fixtures; Asian-urbanized by the rice-maker-as-Godzilla mural that wallpapers a majority of the restaurant, and of course, the iPads. If the names of the incarnations of the restaurant can be taken as literally as I think they can, then the Lucky Robot signifies a new era in the ecology of dining in Austin. As if to illustrate this, the host just described the process of ordering for oneself, including paying, from an iPad at the restaurant table as more natural.”
In his essay “Design in the Age of Biology: Shifting from a mechanical-object ethos to an organic-systems ethos,” Hugh Dubberly argues, “Where once we described computers as mechanical minds, increasingly we describe computer networks with more biological terms.” The impact of this phenomenon is perhaps unparalleled in modern society. We have moved well beyond anthropomorphizing our technology to take care of tasks that humans used to, and even those are still shocking to upon first discovery. Remember the first time you saw Pay at the Pump? It wasn’t that long ago, but not only is it no longer novel, it’s assumed. Gas stations without it are now throwbacks to a slower era and the inconvenience of being forced to walk inside the (“convenience”) store and interact with a person behind the counter is reflective of a value system that is being trained out of us by using anthropomorphic technology.
Lucky Robot is taking advantage of the improved experience of online ordering and placing it inside their restaurant. They’ve managed to maintain employing an extremely small staff while now giving the impression of table service. And so I wonder about the future of dining out. Will this catch on like Pay at the Pump? Will it become an option, like the self-checkout aisle? Will we start seeing it at drive-thru’s?
Why not? Why shouldn’t the customers take their own orders? After all, what is more natural than using your own hands to find your dinner?

IDSE202 – Systems Thinking, Then and Now

Traditional systems thinking developed as an effect of World War II sense making, and was rationalized soon after by early computer programmers.  Systems thinking has come far, from the stuffy halls of academia and military planning into many contemporary spheres, including design.  Current systems thinking has evolved these tenets to apply to current trends in software, service, and sustainability design, as well as artificial intelligence.  In the next few paragraphs, I offer up my understanding how early systems thinking applies in current thinking.

The two traditional systems thinking reads, both from Thinking In Systems, offer up broad definitions of systems that are still useful today.  Systems are interconnected sets of elements and interconnections that have function or purpose.  The author cites the difficulty in identify the interconnections, which tend to be information flows, as well as identifying system purpose.

In today’s world, the interconnectedness of information flow is less obstructed from view than in times previous.  We are all connected virtually through the internet, and with better tracking of digital information, we can often see cause and effect much quicker than in times’ past.  The idea of feedback loops in systems is true and holds; the difference between then and now is their instantaneous nature.

We can now have discussions in real time across the world.  In Design in the Age of Biology, Dubberly cites this trend as a reason for the changing nature of design.  While not stated directly, I believe Dubberly is speaking to the democratization of design that this dialogue has created.  Users are no longer meant to be “designed for”; the real time connection and ubiquitous flow of information will have regular people demand more from the products and services that are created.  People, particularly empathetic designers, are also painfully aware of their effect on  culture and the environment.  Dubberly speaks to the idea of sustainable design’s inspiration in biological systems; I think it is more a side effect of this empathy.

Thinking in Systems also speaks to difficulty humans have in judging systems.  We tend to think in elements instead of connections, as they are more visceral or tangible.  The problem with understanding these connections (or flows), is their temporal nature and effects on a larger system.  This on the whole has not changed – ie  human tendencies towards understanding cause and effect has not changed.  This has led to the proliferation of problems in our society.  As the article states “if you have a sense of the rate of change of stocks, you don’t expect things to happen faster than they can happen.  You don’t give up too soon.”  Poverty, disease, lack of education – I believe these all have developed fundamentally due to a lack of awareness of these flows.  Sure, racism and ignorance have played their part; but many efforts to help resolve or remedy these issues have failed because of a fundamental misunderstanding of the systems, elements, stocks, and flows related to them.

As someone brought up in the digital age, as well as having traveled much in my early twenties, I feel the connections I have to the world in perhaps a clearer sense than from someone in previous generations would have.  The systems thinking articles to me seemed quite relatable to my existing knowledge, both tacit and learned from the last quarter.  Practically, I know that what I end up designing must fit sustainably and fairly into any system, whether it is in Austin or much larger.  I also know that the old way of creating – hand-craft – is not something that I can beat out other companies or skilled designers with.  Nor is that something I need.  Where I can, I hope to accelerate as an interaction “designer-facilitator” and as a systems thinker.


Wire frames 2.0

In this second iteration of wire frames for a student scheduler I reconstructed the site in Indesign. This took a considerable amount of time but makes the navigation cleaner and much easier to apply rules within. I took the feedback that I’d received in the class critique and tried to make everything simpler and more deliberate. I haven’t finished Indesigning the new hero path yet, and as the next pages are where the challenging decisions kicked in, I predict much more time on it. I also have not resolved most of the secondary path issues. Nonetheless, in effort to resolve the hanging chads of unfinished assignments, I’ll post as is and look forward to improvements in the future. Happy Thanksgiving. Login Page

Service Design In Healthcare

On Monday night, professor Jon Freach walked us through the way finding design project that he led at MD Anderson.  The project started as a signage, and quickly evolved to something much more complex and thorough – Jon’s crowning achievement in service design; a three year, multi-million dollar deal to redefine how patients interacted with MD Anderson.

To me, projects like Jon’s are key examples of the power of design to shape and mold healthcare innovation going forward.  Yes, we have the best medical technologies and doctors in the world; in and of themselves, they are powerful drivers of the economy and the health of millions.  Yet the areas of deep improvement plie in the interim – when patients are not in front of that provider, or aren’t using that device.  The problems lie in a lack of service design; a lack of communication and “syncing” up of the patient experience over time.  We need better, smarter systems that incorporate common sense ideas of social workers, caregivers, and the patients themselves in addition to the expertise of these providers and technology companies.

MD Anderson is a world renowned medical center in Houston, TX.  It is also massive and imposing, which tends to cause anxiety all along the way of the patient journey.  Jon’s goal was to counter these not only with clear signage and interactions throughout the actual hospital experience, but to think more holistically and systemically about the entire patient journey too and from Anderson.  Using combinations of design research techniques, such as participatory interviews and contextual inquiries, Jon was able to map back Anderson touch points to the initial patient PCP visit, discovering areas for opportunities to reduce patient anxiety all along the way.  These touch points manifested themselves in a service design blueprint – quite literally a blueprint – that was shared and modified over time by ALL key stakeholders.

What ensued was magical.  A redesign of signage and communication that removed the need to say “right or left” and that referenced unofficial landmarks of the hospital noted by patients.  A program to teach all hospital staff how to talk about directions.  A software program to help manage signage by showing what was linked to what if something needed changing.  New “paths” for patients to follow that didn’t have them walking by the morgue.  Unheard of collaboration across stakeholder groups to get things done based on the design research findings.

In the coming weeks, we will start to use the tools that Jon did, such as service design blueprinting, to map out our potential future services (while we most likely will include a service offering).  We will start with a field trip to Frog Design on Monday, 11/26, which will serve as home base as we explore local business services around the area.  I can see the benefits of this working document to keep our group on the same page, as well as to guide us through iterations of business model generation.  I can’t wait to begin!

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.

IDSE201 – Wires v2

Hi All,

The project for this quarter’s rapid prototyping class is to create a user interface where a student can plan their schedule of classes online.  Framed like a real client engagement, we’ve been given a required list of features and functions to incorporate.

I’ve started work on a scheduling interface for community colleges, which in my previous report I noted the low degree completion rates and the need for a more holistic solution towards planning and socializing the academic experience.

In v2, I made some steps forward with the overall layout and flow, but still need to work on developing a complete system.  Simply put, no excuses for next time.  With that being said, I got some good feedback from Willie – revisiting the need to lay out all proposed changes in paper particularly as I learn more about the prototyping tool Axure that I am currently working with.  There seems to be some anxiety still there lurking in the background about picking up a pen to flush things out; now that I think about it, most likely due back to a fear of failure even though the clear need for repetition (which I’ve already noted multiple times in the program! ahh, how slow habits change).  NO MORE.

I did do something this time that I didn’t really do last time: Talk Aloud Testing with randoms in a coffee shop.  As a quick reminder, Talk Aloud sessions ask that a user verbalize every step of the way through a scenario, without the ability to receive help from the designer.  This was a really educational experience, and quickly made a difference in the usability of my layouts.  Noting pauses, general confusion, and “undesired” click throughs made me aware of shading, placement choices, and lack of informational content where students would need guidance.  Using Axure, I was quickly able to modify the interface.

Without further ado, here are the frames!

Wires v2