People Do Matter

People ask me why I've stayed at MAYA for almost 10 years and part of the reason is that we're treated well. For instance, we had a woman at MAYA that, after giving birth to her first baby, wasn't ready to come back to work and put her son in daycare after our six week paid leave (and yes, that's for moms and dads!). We looked at the problem like any other that we'd work on for one of our clients – what creative solution could we come up with to get her back to work, give her some transition time with her son, keeping in mind that we had 4 more moms and dads that were expecting new babies over the next year? The Babies In The Workplace Policy was born (pun intended!). I worked with the mom to write a policy whereby she could bring her child into work with her up to the age of 6 months. She'd have to provide the equipment and care – didn't want her dumping the child off on one of our administrative staff when she had a meeting. She sent an email to the people that sit in her neighborhood (we don't have cubicles, but more neighborhoods where human scientists, engineers and visual designers collaborate), and we did get a few complaints before the baby was here – mostly worries about crying. Mom came back to work on what we call a Fractional MAYAn schedule (part time with prorated benefits) and baby was in the office 4 days per week in the beginning. We found that the baby had a calming influence on the group, and when he finally did transition to being at the daycare fulltime, he was missed. This gave mom a chance to get used to the idea of daycare, weaning her off of being with her son fulltime, to having him in the office one day a week, until he was in daycare fulltime. The cool thing for MAYA is that this baby is an amazing baby – doesn't cry much, is a happy baby, and a good sleeper. He was the perfect baby to try this policy out on, and so was mom as she's one of our interaction designers, and is involved in user testing. Over the past 18 months, we've had two dads bring their newborns in occasionally, and a married couple that works for MAYA bring their new daughter in on a regular basis. It has worked really well.

On April 11, 2007, the Pittsburgh Human Resources Association (PHRA) held their banquet for the People Do Matter Awards. The People Do Matter initiative recognizes southwestern Pennsylvania employers whose human resource practices best demonstrate the importance of providing workers a positive return on their contributions of time, attention, ideas, knowledge, passion, energy, and social networks to ensure productivity, efficiency, and business results. Awards are presented in three areas: People; Learning and Development; and Work Structures and Processes. A group of MAYAns attended the banquet – had a great time! - and MAYA was awarded the People Do Matter Award in the People category for this policy and our benefits package in total. The People category recognizes strategies to attract and retain a diverse, high caliber workforce. The focus is on approaches to recruitment, compensation, recognition, or work-life balance. Other finalists in this category were MARC USA and California University's Career Center.

I continue to be excited and interested in staying with MAYA because we try to be innovative in our benefits design and our approach to how we treat our people. To me, this policy shows that MAYA is interested and willing to support us on what's happening in our personal lives – and expects us to have personal lives!

The Vision of MAYA

When I joined MAYA in November of 1997, I was excited by the ideas of new challenges, working on all types of user interfaces. I had found myself in previous jobs building user interfaces (a voice response application, an interface to compile large mainframe applications and run regression tests). During my first week I had a meeting with Peter Lucas, one of the founders of MAYA, to gain some insight into what MAYA is and what they were doing with Visage and Interstacks. After a couple of hours of Pete diagramming things on a whiteboard, talking in what seemed like a foreign language (it sounded like English, but with a bunch of odd words like ‘uforms’, ‘repositories’, ‘transducers’, etc.) I went home that night and wondered if I was in over my head.

It takes a little while to comprehend the larger vision of what MAYA is trying to accomplish: designing devices and user interfaces for the age of information liquidity and pervasive computing. During my first three years at MAYA, I was immersed in our VisageLink research project. The goals included experimenting with direct manipulation of data elements (cells in a table, items on a map, etc.) and the ability for two human beings to collaborate by sharing their views of the information in whatever way they each wanted to present it. We also experimented with a visual programming paradigm that made the code segments that could be easily reused and recomposed to perform different functions. We then experimented with taking the PC and breaking it into functional parts: a repository (something that stores information), an executor (something that processes that information), and transducers (something that allows the user to interact with the information). These projects, when taken separately, seem totally unrelated. But if you have the time to talk to Pete about his grand vision, you will soon understand (or at least nod your head and pretend that you understand for a while) that they are all little forays into the various aspects of the pervasive computing arena. And they focus on the challenges that will be present in this new world where computers are all around.

Now I’m in my 9th year of working for MAYA. There are still some things that I don’t fully understand and some things with which I don’t fully agree. There’s a lot of it that make perfect sense, and I can’t understand why people continue using tools that place so many constraints on their ability to visualize and analyze information. Things like uforms infotrons and transducers all make perfect sense now. Working at MAYA has affected the way I think about problems and how I attempt to solve them. The principles and ideas are infectious to all who work at MAYA—especially those of us who have been around for more than a few years. The problem is, it’s not easy. This is why we tackle a little bit at a time, drilling down on a particular problem, hoping to find an answer, and typically ending up with a few more questions.

Few months back, Pete gave a general overview of how the research that MAYA has done for the last 17 years is bearing fruit in various ways, and why MAYA will continue to do research and experiment in the future. The entire content of the talk is now up here on the Foundry, and it is much easier to understand than that first meeting I had with him. It reminded me of all the things that I had forgotten that I didn’t know or believed before I came to MAYA. For me, this was a nostalgic glimpse back at my early days at MAYA. It caused me to remember how much I wondered about what MAYA was trying to do, and I realized again how important it is to continue making progress on our research agendas, regardless of the challenges from the business perspective. We hope this is only the first of many such talks that we will be sharing with you.

MAYA Design is in this month's Inc Magazine

"Brave New Office" July, 2006 Francine Gemperle, a relatively new mom, and a talented Human Scientist, at MAYA is interviewed, along with a photo shot of her and her son, Milo, at our Pittsburgh office. They both look fabulous. A couple of points related to the article -- we are pro Mom and pro Dad, not just pro Mom. We are gender insensitive. MAYA spelling incorrect. This was and is not easy for the parent. Easier on some of the employees who love babies. More on that later.....

Ad Hoc Usability Testing

We at MAYA have been interested for a while about the differences between usability tests where the tasks are well-defined beforehand and those that use a looser structure; where the user has greater autonomy to explore the interface or the product.

Observing the user while they're allowed to explore a system on their own has merit -- after all, they won't have a usability test moderator telling them what task to do next when they're using the system in earnest. On the other hand, if there's no structure to the test, a participant may not encounter many areas of the user interface, or it may take more users to get complete coverage of a system. It's also hard to make objective measurements (error rates, time-on-task) if the tasks are generated in an ad-hoc fashion -- not only will the tasks not be known by the moderator, but each participant will have a different task set.

Mark Hurst at Creative Good insists that what he calls Listening Labs are superior to usability tests where the tasks are defined beforehand. Jared Spool suggests that we let the users define their own tasks. Of course, one can't go into a test unprepared. Even if you don't define tasks beforehand you have to be well-prepared, as a proficient interviewer will be before an interview. In fact, there might be more preparation needed for an ad-hoc style user test than for one that has tasks defined.

The truth is probably that there's a continuum from ad-hoc to well-defined, that neither extreme on the continuum is well-suited to getting the best results, that the proper compromise between the extremes differs from product to product, and that the best test must be designed on a case-by-case basis depending on the thing being tested, the goals of the test, and the users.

Here are a couple of links that help frame the debate:
» Mark Hurst's "4 Words to Improve User Research" post
» Joshua Kaufman's description of a canonical usability test, including generation of task scenarios
» Jared Spool's article where he refers to task-based tests as "scavener hunts"
» DialogDesign (Rolf Molich)'s Comparative Usability Evaluations, where they tested systems using different methods then compared the results.

Although the results of the 5 CUEs are interesting and instructive, none of them allows comparison of results between ad-hoc and a task-based usability testing methods. Some allow comparison between usability testing and expert evaluation, but most of the conclusions reached after the CUE exercises centered around the issue that usability professionals need to improve communication of recommendations to engineering teams.

Users, how they make my day!

As a Design Anthropologist there is nothing more rewarding and invigorating than getting to observe and/or engage users on a personal level. Don't get me wrong, I love the design aspects of what I do; translating research into design decisions, innovation and ideation, designing and building concepts and prototypes, or exposing the underlying information architecture of complex systems. All of that design work is rewarding, but there is something that is so viscerally appealing about engaging real users. Sure, it's not the same as being involved in protest marches that help over-through a South American government, or skinny dipping in the Napo Valley River Basin, but damn, it can be just as exciting.

What is bringing all this to the surface? Why am I talking about this?

In truth, its been a while since I've been able to make it out into the field, for more than an hour or so, and that's been eating at my being on an existential level as well as professionally. Well, until recently anyway. We just finished a round of usability testing on a great new product that is expected to hit the market within the next year.*

As we typically do, we conducted an expert analysis and usability audit on the product and its documentation, packaging and out-of-box experience before we ever put it in front of users. During those early phases, based on our expert opinions and years of experience, we reworked both the user documentation and product packaging. We thought we did a pretty good job and made vast improvements over the previous designs. Its been challenging because the product essentially creates a new class of products, so there aren't familiar metaphors to build the user experience around **

But wow, it never fails, get the product in front of the users and you will always be amazed by what they do (and try to do) with your designs. I can't help myself, but I get so giddy when I get a chance to watch people do whatever it is that they do.*** One of the incredible things that happened were that two of the pilot test we ran had catastrophic failures, which meant some quick re-engineering of the user documentation and the quick-start guide to correct the problem. As a result none of the actual participants experienced the same problem as our pilot participants.

one say to me during one of the down times, "You must be bored out of your mind having to watch me do this on a Saturday morning." I could only think to myself, "Are you kidding me? No, this is exactly what I've been yearning for. thank you. thank you. thank you."