Experience Design Reactor was founded in 2002 by Kevin Mullet to provide a full range of usability engineering and design services to the software industry. His consulting practice draws on sixteen years of industry experience as a user interface designer, architect, and manager at Sun, Macromedia, Netscape, Propel, and a series of Internet start-up companies. See resume of work experience (short version | long version) as a full-time employee for details. Recent consulting clients have included industry-leading software companies like Macromedia, Yahoo!, Synopsys, and HP/Snapfish.

Kevin is trained as a product designer and human factors specialist with a specialization in visual representation and animated displays for data analysis. He holds the B.S. and M.A. degrees in Industrial Design from The Ohio State University. He has worked on the full range of interactive products from platform and system level software to development environments for software engineers and hardware logic designers to web-based enterprise software for mission-critical applications to consumer-oriented products addressing e-commerce, information retrieval, and online photo sharing.

While he has maintained a strong focus and active research agenda on visual design and representation issues, Kevin has extensive experience in all aspects of product design and is best known for his ability to produce coherent large scale systems.. He has lectured and presented tutorials to conferences, professional groups, universities, and corporations throughout the U.S., as well as in Canada, Finland, Denmark, Italy, Germany, and the Netherlands. He has written extensively on user interface design and is coauthor of Designing Visual Interfaces: Communication-Oriented Techniques (1995), which was ranked third in a CHI 2000 survey of the books most useful to practitioners working on real-world problems.

E D Reactor has delivered solid solutions in all of the areas listed below for multiple employers and consulting clients. If we don't have the ability to solve your problem ourselves we can tap into an extensive professional network to help you find the best resource for your specific needs.








Product Management

Much of what experience designers do is more properly described as product management than as product design and indeed, the debate over the best place, organizationally speaking (Marketing or Engineering?), for the design team has never been definitively established. Either can work in a sound organization with appropriate management support. Designers need to work closely with both product managers and software developers, with the emphasis shifting from the former to the latter over the course of the release cycle. The value we can add in the early stages comes largely from our expertise on human performance in general and our experience in conducting the research needed to identify needs unique to a particular set of users and tasks.

  Design Reviews  

Design reviews provide a good way to get a quick assessment of the effectiveness of your current design at the level of its visual and verbal syntax and mechanics of interaction. This type of analysis uncovers things that are almost always mistakes, regardless of the users and tasks involved, and accounts for a significant portion of the potential improvements and virtually all of the easy ones. Deeper analysis, of course, depends on a certain level of domain expertise. Studies have shown that heuristic analysis (a fancy technical term for expert design reviews) can be even more effective than usability testing in identifying design issues, provided there are multiple reviewers who have domain expertise as well as general design expertise. At Reactor we have access to a large pool of reviewers with extensive experience with the full spectrum of user types and work/task regimes. When necessary, a design review can be combined with explicit user and task analysis (see below) to ensure that the relevant factors are weighed appropriately in the review.

  User Analysis  

User-centered design takes account of the specific needs, abilities, and preferences of anticipated users to produce an interface that is as easy to learn and use as possible. To the extent that specific relevant characteristics of the user population (or more commonly, the several distinct user populations) can be reliably identified, the product should be optimized to support and exploit those characteristics. At the very least, anticipated sub-populations that might be expected to become heavy users should be explicitly identified and characterized to determine their impact on product design. Each specific user population identified should be characterized in terms of their motivation, interests, and priorities (working from existing user profiles or personas where available) before the design work begins. If you don't already have this information we can help you get it quickly and easily through anthropometric, archival, and survey research.

  Task Analysis  

All user-centered interface designs are organized around tasks that represent the various levels of goal-directed operations in a user's work domain. While there will be generally be some overlap, the task sets for different types of users often vary substantially in their scope and emphasis. Note that tasks are units of work, not features or anything that depends on the operational details of a particular user interface. Tasks are described without reference to any characteristics of the UI because we want the task structure and usage pattern to drive the design of the UI rather than the other way around. We can help you identify the typical tasks that need to be optimized for efficiency as well as the critical tasks that need to be optimized for safety and reversibility, before you start locking in the product design.

  Product Definition  
  Many product managers are hampered by a lack of design training when it comes to defining the scope and content of a new product or release. It is quite common in the software industry to work bottom-up by reviewing the feature sets of similar or competing products and compiling long lists of features to be included and technologies to be supported that are prioritized by expected competitive needs and implementation capabilities rather than actual value to the intended user. The designer brings a top-down orientation toward the problem - as defined by the users and tasks to be supported - and a generative approach to problem solving that consciously explores an entire solution space rather than latching onto a particular idea or (even worse) directly copying a pet product or (worst of all) a mix of favorite products. We can help you make sure your basic product idea makes sense and help you pare it down to the minimum necessary for success.  
  Requirements Engineering  
  The term "requirements" is used in many different and often conflicting ways in the software industry. What's described as a "functional requirements" document in one organization may be known as an "engineering specification" in another. The key distinction has to do with whether the focus is on requirements for implementation or for design. When viewed this way it makes more sense to define functional requirements as the input to the design process, and completed designs as the input to the implementation process. Functional requirements should describe what users will be able to do with the product, without describing how they will do it. (There may be market requirements that dictate the ability to do certain things in certain ways for competitive reasons.) Stating the requirement in strictly functional terms is difficult if you start from existing designs (competing designs, prior versions of the current product, favorite features in other products) rather than from the targeted user tasks. We can help ensure that requirements are stated clearly,concisely, and in a manner that informs, but does not unduly constrain the design.  

Product Design

Design for interactive software takes place on three levels, each with its own focus, timeframe, and specialized expertise. After the initial analysis phase sets the stage, design proceeds in roughly sequential order to resolve conceptual, interaction, and presentation design issues. Within each stage, a similar process is followed: generation of a wide variety of alternatives is followed by selection of the most promising direction and refinement to produce a solution that satisfies the functional requirements as elegantly as possible.

  Conceptual Design  

Conceptual design addresses the understandability of the product and allows users to make sense of the things they perceive in its controls and displays. A good conceptual design helps users remain oriented based on simple perceptual cues as they move through the product and allows them to diagnose problems as they arise. Its focus is on the naming and organization of user-visible objects in both the content and the user interface. These need to be internally coherent and appropriate for the audience (ideally based on relationships that are already familiar from the real world) . Product design begins with conceptual design because the decisions made at this level impose few constraints on the interaction and presentation design. The same conceptual design, for example, can support several very different interface styles (GUI, command line, web, etc.) The implications for implementation architecture, on the other hand, are often profound, so it's important to establish a design direction as quickly as possible so that back-end work can proceed.

    Interaction Design  
    Interaction design addresses the user's ability to efficiently exert fine-grained control over the application in order to make it do what they want. This phase of design covers topics like choice of interaction style (e.g., menu-driven, direct manipulation, command language) along with the specific controls, mappings and protocols relating commands and controls. All product design decisions involving the mechanics of user interaction fall into this category. What types of controls to use, how to connect them together to correctly represent the underlying data model, how to respond to various expected and unexpected user inputs. The key to successful interaction design is to match the style of interaction to the task structure and anticipated usage pattern so as to optimize the trade-off between efficiency and approachability for a particular user population.  
    Presentation Design  
    Presentation design addresses the clarity with which the underlying conceptual model and the interactive state of the system are communicated to the user. Central topics include all of the traditional areas of graphic design (color, layout, typography, images) as well as dynamic effects and intangibles such as phrasing and tone of voice. Much of the visual tuning involved in presentation design can be described as syntax adjustment which is relatively independent of the underlying semantics of the associated objects and operations. This generally takes place within a broader visual schema designed to reinforce branding or corporate identity goals across the full set of displays provided by any given product.  
  System Design and Branding  
  Designs for interactive software rarely exist in isolation. Every element in an application or web site is part of a larger set of interactive elements that work together as a system to provide the intended functionality. In fact, most elements are part of multiple systems corresponding to at least the three levels of design activity. A button, for example, is part of a conceptual design system when considering the GUI metaphor in general. It is also part of an interaction design system when considering the variations in state and behavior (e.g., rollovers, toggling, interconstraints), an part of a presentation design system from the standpoint of a particular standard GUI. Understanding how to design large-scale systems in which the necessary trade-offs are optimized globally rather than locally is not a skill that comes naturally to people.  

Design Development

Design is an iterative process that builds on past successes and corrects for past failures when viewed in the harsh light of real-world experience. Ideally there should be time to iterate within a given release cycle so that each release can be as sound as possible. Given the realities of modern product organizations, however, the iterations must take place in abbreviated form by focusing on specific opportunities and preliminary assessment techniques based on simulations or sketch prototypes. As soon as a basic direction emerges it should be validated by increasingly detailed design work and continuous assessment.

  Rapid Prototyping  

One thing (perhaps the only thing) that all UI professionals agree on is the importance of iterative design for developing usable software. In order to achieve high quality designs with a high level of confidence it is necessary to iterate within the development cycle. This is hardly a novel idea. It arises in the implementation arena as well, where as long ago as the mid-Seventies Fred Brooks was advising developers that they should "plan to throw one away" in making the case for prototyping before proceeding with final implementation. Potential solutions can best be evaluated by creating interactive prototypes or demonstrations at varying levels of fidelity that capture the essential qualities of a particular design alternative. These can be tested personally by the design and development teams and, where appropriate, on representative outside users to determine which design strategies provide the most powerful and general solutions to the problem.

  Usability Testing  

Usability testing and evaluation take place throughout the product lifecycle, even when there seems to be no time for it. The need for testing is directly proportional to the novelty or unfamiliarity of the problem and the proposed design direction. For issues arising early in the design process a rough or semi-finished prototype is often the only means of obtaining user feedback on the design, since time and resource practicalities generally preclude the use of actual working implementations. When the fluidity of complex interaction is the primary concern, testing must generally wait for a preliminary implementation with full functionality in the areas of interest before an adequate assessment can be made. This may well be the case for assessing workflow or data management issues, for example, since realistic content or complex interaction may be needed to determine if the desired behavior has been obtained.

  Design Specification  
  Ultimately what is delivered by the design team or consultant is a specification of some sort. The specification captures and describes the design at a level of detail that is sufficient for the development team to implement the designer's vision. A relatively simple and high level document may be sufficient for applications that target a well-defined platform with a mature design language and a rich component library, since information available in platform-level usage rules and style guides can govern many decisions without being included in the spec. In other situations, such as when communication bandwidth is limited by offshore development arrangements, the specification must be sufficiently detailed to clarify every potential uncertainty.We use a combination of written documents, annotated flow diagrams, wireframe prototypes, and formal drawings to specify the design. But ultimately it is the needs of the development organization that determine the form our deliverables take.  

Implementation and Follow-up

Product design work should ideally be about a third of a release cycle out of phase with the implementation side of the product team. Designers need to monitor progress and check implementations against designs, but most of the design work needs to be completed by the time the final implementation push begins, if for no other reaon than that design team needs to start working with product management to lay the groundwork for the next release. In the time that remains they can focus on these activities.

  Production and Implementation Support  
  Final detail design work and production of media assets as well as data such as final CSS contents should ideally be handled by the designer (or subcontracted under their direct supervision) as well. Although they can sometimes be taken on by a motivated developer the outcome will almost always be better when it is the designer sweating the details and, if necessary, adjusting the design slightly to make implementation easier or more complete. While we have no desire to influence the implementation architecture, we are quite happy to tweak away once the page structure has stabilized. Whenever we can, we prefer to work with resource editors, layout tools, or application frameworks to adjust the implementation directly ourselves. This not only saves us time and effort in the long run (it's faster and more efficient than writing a spec and then checking a developer's work against it); it generally produces a better result.  
  Design Pattern Writing  
  Design patterns capture the essence of a "good" solution to a recurring problem in design. They describe - in their own unique format - the fundamental invariants that can be used to generate thousands of effective solutions, no two of which need be exactly the same. It has been twenty years since the concept was successfully transplanted from architecture to software engineering, where it now forms a core part of several leading development methodologies. More recently the concept has been applied to user interface design where, if anything, the fit should be even better than in software engineering. We have developed extensive pattern libraries for e-commerce, multimedia interaction, and web publications for Propel, Macromedia, and Yahoo!, respectively. We can create a pattern language for your application that will get your designers, developers, product management, publications, and support staff on the same page..  
  Corporate Training  
  Much of the value we offer takes the from of "technology transfer" of our tools, methodology, and philosophy of interactive design to existing product development organizations. We can do this over the long run by collaborating with your design team on project work. We can do it for a larger group, in a shorter period of time, by utilizing a more traditional workshop or classroom training format. All of the topics above are available, or can easily be created, in the form of 1- and 2-day courses that can be tuned to match the specific needs of your products and development organization. Over the years we've presented over 100 days of instruction to corporate, academic, and professional audiences around the world. See the Courses section for details on our current offerings.  
    Copyright 2006 Experience Design Reactor, All rights reserved.