Supporting the Process of Innovation – The Maryland Way

Introduction

Innovation is a mysterious process. As a university research community we have been repeatedly, but not consistently, successful in research and practical design. However, I still don't know how to predict when and where innovation will appear. Even when I see a bright spark of an idea, I have a hard time predicting how others will perceive our innovations, and where they will take them. My fantasy is to have a crystal ball to tell me which of our prototypes or papers will be applied, disseminated, referenced, and extended. This highly social process of innovation within our community and the reception or rejection of novel ideas is fascinating, surprising, sometimes satisfying, and sometimes disturbing.

Our basic approach has been to keep our communities small, personal, flexible, and open. Rather than a rigid hierarchy, I see our organization as a family of cooperating laboratories with commitments to their own university units. Large budgets and bureaucracies are necessary for some projects, especially product development, but innovation seems to be very personal and driven by an individual's passion. We also keep our process open, avoiding proprietary agreements, sharing ideas internally and externally, and avidly learning about the work of others. When there are external stakeholders, we produce our deliverables and meet our deadlines, but the novelty often emerges when individuals pursue an intuition, respond to a hunch, or are provoked by a problem. If someone has an idea they wish to pursue, I encourage it, while making sure that commitments are met. Someone with a good idea will pursue it on their own, late at night and even if they have other papers to write or exams for which they must study. My novel ideas come when I have taken care of the daily requirements and can get away to think big thoughts. Skiing helps loosen my imagination, but beaches or forests with time for reflection are effective too.

When a new idea is raised, community discussion is a helpful reality check: Does it make sense? Has it been done before? Who would benefit? Since we have modest resources, we must work on projects that have high payoffs with realistic effort. I talk about finding projects that reach new destinations rapidly by 'tunneling through'. At the same time, we try to be practical rather than visionary. We try to build something that really works and then give it an honest empirical evaluation. Once an idea has passed our review, we may seek support to expand, refine, and develop it. In short, our strategy is to open ourselves to innovation, refine through discussion, build to test, and tell the story. Research has a serious side and it requires hard work, but when it is going well it is great fun.

From Sparks to Fire

The right team of people is vital to turning sparks into fire. Well-trained, brilliant, motivated, diligent, cooperative, and friendly people enhance the chance of success and make the process more enjoyable. You can measure some of these variables by looking at transcripts or standardized test scores (SAT, GRE), but personal judgments are more important. We ask those who want to join our group for reference letters and we conduct personal interviews. Personal judgment of how it would be to work with someone also counts (we envision having lunch with them). Capacity for laughter is a must and visible laugh lines are an asset. These hurdles apply to graduate students and staff, as well as for undergraduate assistants. They make it clear that we are serious about who we choose. New recruits realize that those who participate in the lab have survived similar scrutiny. The process helps us ensure that we are getting good people, and once they begin working, they are motivated to demonstrate that they really are that good.

Our screening methods work well, but imperfectly. On more than one occasion someone who interviewed well did not work out. I start new members on specific short-term tasks and then check in to make sure they deliver. When repeated requests are not satisfied and the excuses mount, I let students or staff know that their work does not match our needs and give them notice that they will not be renewed after the semester ends. This was hard to do the first time, but I discovered that such a clear message, when delivered gently, is appreciated because of its clarity and honesty. What surprised me is the powerful and positive impact of dismissing someone on those who remained. They recognized that the lab management knew the difference between good and poor work, and they took increased pride in their own work. I suppose they were also motivated to produce results to avoid a similar fate.

We begin by choosing excellent and pleasant people. Then the Maryland Way is to foster innovation through seven sparks:

1. Choose a good driving problem
2. Become immersed in related work
3. Clarify short-term and long-term goals
4. Balance individual and group interests
5. Work hard
6. Communicate with internal and external stakeholders
7. Get past failures. Celebrate success!

The Maryland Way

1. Choose a good driving problem

Fred Brooks has commented on the positive influence of choosing a 'good driving problem.' My experience supports his contention. A 'good driving problem' often has a clear goal, for example, build a museum kiosk that patrons can use with zero-trial learning or enable pathologists to operate a microscope remotely. In general, successful projects share these attributes:

• clear and novel challenge: hard enough to be interesting, but modest enough to be attained;
• realistic mechanisms to measure success: specific functionality, human performance goals, or subjective satisfaction;
• well-specified audience: build a system for specific users, clarify a theory for researchers, write a paper for a journal, or deliver reports or products to financial supporters;
• skills required match the researcher's background.

Finding good problems is like antique hunting: you are not quite sure what you want but when you see it, you know it! In the early stages of choosing a problem we brainstorm to come up with divergent possibilities. Then over a period of a few weeks we discard the extreme ideas, refine the remaining possibilities, and focus on one. Constraints can be helpful, such as the student must complete the work by a certain date, or our lab must deliver specified results to a supporter.

A good driving problem has a solution path that is reasonably clear at the beginning, but detours and new routes often appear. The path for our group is typically to identify a realistic need, design an interface, refine the design, build the software, refine the software, test the interface, refine it, and test it again. The need may spawn an application, such as information access by touchscreens for museum patrons, or a basic science quest, such as attempting to build a touchscreen that provides pixel level precision faster than a mouse. Applications lead to observations, field studies, interface critiques, usability studies, or data logging. Basic science leads to controlled experiments, with careful statistical analysis and replications.

Our greatest successes have come from steady commitments to a sequence of related projects over many years. Our quest for high precision pointing and also for hypertext design began in 1983 and continued to 1990. Now our quests include dynamic queries for filtering information from databases, hierarchical information visualization, novel widgets for extending User Interface Management Systems, automated metrics for evaluating screen designs, and methods to enable programming-in-the-user-interface (PITUI). A continuing challenge is the one-in-a-million family of problems. This includes some understanding and guidelines for selecting an item from a menu of 10 items, 100 items, 1000 items, 10,000 items, 100,000 items, and 1,000,000 items. We are often called upon to help design interfaces that include some piece of the one-in-a-million problem, but the constraints vary greatly and we have yet to have a completely specified set of guidelines. Other problems for researchers can be found in my 1986 SIGCHI Keynote Address in Boston: Seven plus or minus two central issues in human-computer interaction (Proc. CHI '86: Human Factors in Computing Systems, ACM, 343-350).

2. Become immersed in related work

I tell my students that I expect them to become the 'world's leading expert' on the problem they are investigating. They must become knowledgeable with academic research papers on related studies, commercial products as examples, and personal contact with active researchers. These requirements may seem obvious, but as a journal editor and reader, I am often disturbed to see inadequate knowledge of related and previous work. I expect my students to educate me about related work.

My students must go to the library or the Internet and chase down every reference on their topic. This process has the dual benefits of compelling them to work on something narrow enough that they can become the world's leading expert, and forcing them to clarify what exactly they are working on. It won't be acceptable to say 'I'm working on menu design' or 'virtual reality sounds like fun.'

Trying out commercial products brings a sense of practical reality. The students come to understand the parts in the context of the whole, and see the tradeoffs that designers must make.

Getting in touch with current researchers or developers is a novel and threatening task for many of my students. E-mail helps facilitate the process, but phone calls, letters, and visits are also important. Shy students overcome their awkwardness and are often rewarded by a helpful contact with a respected researcher or an invitation to present their work at a major company.

The diligence required to produce a bibliography of 5-25 items, review and critique commercial products, and contact people helps prepare them for their own creative work. I do not accept the belief that they don't want to be influenced by what others have done - this is a naive excuse. I also find that contacts with current researchers can lead to unexpected and productive collaborations.

3. Clarify short-term and long-term goals

When we start a new project we usually spend a few weeks thinking broadly, brainstorming and coming up with diverse alternatives. As we sort out and reject some directions our understanding of what is important sharpens. Then we plan some long-term goals and establish some short-term goals to get started. If the short-term goals are accomplished we can move along; if not, then we can redirect with only a modest loss of time and energy.

For example, one long-term goal was to develop specification methods for dynamic explorations in a large three-dimensional display space. The short-term goal was to specify something smaller and more specific, such as the window management in a familiar geographic information system. In another case, we contributed to designing a museum exhibit involving a 2500-article electronic encyclopedia. Our initial prototype used 106 articles on a narrower topic, and then we went to 400 articles plus photos and videos. I find scaling up from small prototypes to be the most realistic path, even if you wind up throwing out early prototypes. In fact, throwing out a prototype and starting over is often a shortcut to progress. Similarly, every experiment gets tested out in a pilot study with small numbers of subjects.

The benefit of long-term goals is that they provide a destination, and a shared set of expectations that focuses effort. The benefit of short-term goals is that they provide immediate feedback about progress and a chance to make mid-course corrections with low cost.

4. Balance individual and group interests

I try to give each student or staff person a role that is clear and one that serves their individual goals (getting a Master's degree within 18 months, doing an independent study summer project, or building a resume to get a desired job). These goals need to be in harmony with the overall goals and directions of the lab. Proposed projects have to fit in with their existing experience, skills, and directions. A student who wants to do a Masters thesis on a topic that is poorly related to our existing work will get a cool reception, and possibly a long lecture about alternate topics.

When visitors tour the lab, students and staff need to know that they will be given a chance to show their work, get feedback, and promote their idea. This works out well, and our visitors usually prefer chatting with the students who are doing the work to a private presentation by senior staff. When visitors are potential funders, direct student and staff involvement in the future of research projects increases motivation, participation, and work quality.

When individual and group goals are in harmony, fortuitous collaborations are likely. One of the ways we have been able to accomplish much with limited resources is that individuals know that they can get help from each other. When one PhD student needed a special routine on an unfamiliar hardware/software environment, another student stepped in and provided a few days of programming help. The favor was repaid by help in reviewing paper drafts and assistance in preparing subjects for an experiment. Since our lab operates with a diverse hardware and software environment, hardly an hour goes by without someone calling out for help on some system.

5. Work hard

Thomas Edison remarked that innovation requires 1% inspiration and 99% perspiration. An exciting and novel idea is just the starting point. Most ideas have a cascade of smaller ideas behind them and the details do have to be worked out. Special cases, exceptions, and extreme conditions have to be investigated carefully to reveal the limitations of a new idea. Then converting an idea to a piece of functioning software, a set of screen designs in a prototype, or the materials, tasks, and statistics in an experiment takes devoted effort. Polishing, refining, and cleaning up can take ten or a hundred times more effort than the original innovation. This has proven to be the case with:

• developing new interfaces (first designs are mocked up in hours, but prototype testing, full implementation, and revisions can take months)
• creating software (pseudo-code is followed by extensive coding, testing, and refinement)
• conducting experiments (design takes a day, but developing materials, pilot testing, administration, and statistical analysis takes months)
• writing papers (initial draft might be 10 hours, but revisions based on local and external reviews may require 100 hours)

A sustained effort is necessary to achieve excellence, and we encourage realistic expectations. One reason that I have less trouble writing than many colleagues is that I grew up watching my journalist parents revising, cutting and pasting (the old- fashioned way with scissors and glue), and retyping many times. Simply expecting things to take a great deal of effort removes some of the anxiety or expectation of perfection.

There is also a definite improvement in quality when you can revise and improve after reflection or comments from colleagues. The second time through with almost any process or path is smoother and faster, but the second time through means that there is less joyful novelty. Second times are safer but less thrilling.

6. Communicate with internal and external stakeholders

Our group operates with a high degree of internal communication and external reporting. Internally, we have weekly or less frequent meetings of research teams that work on related topics. We also hold a weekly seminar to discuss a journal or conference paper or to hear a formal presentation of results. However, these traditional business-like meetings tend to be less fun and provocative than the spontaneous demos, informal pre-experiment reviews, participation in pilot studies, pleas for help with statistics, and personal requests for reading of draft papers.

While internal communication helps form and guide our work, the external communications play a vital role by raising the level of importance or anticipation. I am constantly struck by the beneficial influence of preparation for:

• demonstrations to visitors,
• presentations at our annual Open House & Symposium,
• writing term reports, theses, or journal articles,
• production of videotape reports,
• lectures at companies or universities, and
• papers and sessions at conferences.

Preparing something for a friend, staff person, or professor may encourage some diligent effort, but it seems that preparation for a conference talk, a lecture to supporting companies, or important visitors raises the stakes considerably. Telling the story and listening for feedback are often unfamiliar skills for technically oriented people, so we try to practice often and help each other polish our papers, slides, talks, videos, etc.

7. Get past failures. Celebrate successes!

Some days are exciting, but many days seem filled with hundreds of responsibilities such as reviewing journal papers, showing visitors around, responding to requests for technical reports, writing proposals, or reading a draft of a thesis chapter. Sometimes we are burdened with tedious tasks such as filling out travel vouchers, repairing computers, or preparing budgets. However, when it comes around to writing our annual report or preparing for our Open House & Symposium, I am struck by how much we have accomplished during the previous year. The really good days are when students proudly invite me to see a demonstration of their latest design, improvement, or experiment. As lab members gather around a computer display, we are off and running with cheers, comments, and criticisms. Other memorable days included working intensely to finish a paper, resolving a problem with statistics, brainstorming on designs, rehearsing for a videotape, and fantasizing future user interfaces.

The intense 'flow' experience that comes with deep engagement in a problem is rewarding in itself. On one occasion I worked closely with a student to revise a journal paper for almost three hours. We sat at adjacent Macintoshes and while I dug out a reference from one file, he added the relevant paragraph. Then while he combined several graphs as requested by a reviewer, I revised the text to refer to the new diagram. We smoothly picked up pieces from each other across the network and came out with a substantially improved paper that wove together the high-level theory with the practical results. Our concentration was intense and as clock-time vanished we were driven by the rhythm of cooperation to complete in a morning what might have taken either of us alone a week.

Other good days are when a student passes a dissertation defense or has a paper accepted for a journal. While we don't have a party for each event, we are well-known for having celebrations in our labs (champagne and strawberries are a favorite), going out for lunch or dinner, or organizing picnics, ice skating, and theater parties. Occasionally we take a 'field trip' to a local museum, company, or government agency that is using computers in a novel way. A more whimsical summer field trip was to a shopping mall to try a virtual reality game, followed by a picnic on the Potomac.

Bad days are very much a part of our life too. Even after 25 years of writing, it is still a great disappointment to get turned down by a conference program committee or journal editorial board. Each new idea seems special and its rejection is felt personally. After the upset, we try to figure out why we failed to convince the reader of the importance of our ideas. Requests from journal editors for major revisions are also painful, but I must admit that some of our most successful papers have had the longest gestation period and endured the most revisions. Rejected grant applications, students who chose to go elsewhere, and funders who decide not to renew are also unpleasant experiences. Even a successful research group must deal with many disappointments.

We discuss authorship expectations of papers early and often. Participants are entitled to know who will receive credit and in which order. We have had disagreements, occasionally serious, but have always found creative ways to resolve such conflicts. We are also devoted to careful acknowledgement of contributors, reviewers, and helpers of all kinds.

Our annual Open House & Symposium, held in June, is another major celebration in which students, staff, and faculty get to present their work. It is a lot of hard work to prepare but it is an effective way to disseminate our research to several hundred attendees. In the morning we make carefully polished formal presentations and respond to the spirited questions. Lunch is for informal chatting and birthday cake (decorations have included lab logos, Macintosh windows, pie menus, and treemaps). The afternoon is given over to tours, demonstrations, and personal discussions. At the end of the day, senior staff and faculty go out to dinner with our Advisory Board to reflect on the day and make suggestions for future work.

Once a year, in December, we hold an all day retreat at some 'bucolic' (our favorite term) location within an hour's drive. We talk about where we are going in our research, try to see the big picture, have lunch, take pictures of each other, and then hike in the forest before going out to a nice dinner. Since everyone speaks about their plans, there is never enough time, but long lists get carried away for further contemplation. It is a time for making resolutions and visualizing the future in a safe supportive community.

à propos

• Codex - Memex - Genex, Ben Shneiderman at CHI ’98
• Resources in the idea of Innovation

Feedback – please leave a message