Design research and design-driven best practices can help your application development get an edge.
By Knut Graf. Knut is a Principal Designer at frog design, a global innovation firm.
The Mobile Internet Device (MID) platform has to establish a following of users and a set of high quality applications, which presents a kind of chicken and egg challenge. The lack of a track record to refer to, along with other factors that are common to emerging platforms, makes application development on MIDs challenging. Yet, high-quality applications are critical to the platform's success. Design, as expertise and as a set of practices, can address many of the risk factors that characterize this situation.
Design ensures that the product vision is relevant to the user by gathering knowledge about the user and the application's usage environment through informal discovery activities and through formal research. Based on the knowledge gained in this discovery phase, a crisp feature definition lays the groundwork for a great user experience, which is built out through a compelling look and feel. A prototype confirms the product vision amongst team members and guides implementation and testing, thereby reducing the need for lengthy and tedious traditional requirements documentation.
The guidance and streamlining that design brings to an application development process allows the core development team members to devote proper amounts of attention to technical challenges and quality, greatly improving the odds that the project will be completed and successful.
The software industry has established a track record over the last few decades of slowly making its development practices more efficient and effective. Even so, software projects are still burdened with high failure risks. The quality of projects that make it to market is hard to predict. For example, in consumer-facing applications, for every well-rounded product, there is another one full of bugs and quirks. Properly introducing "design" into a software project is one way to increase its odds of success.
Many processes and best practices address risk and quality concerns in software projects. In practice however, such practices compete with established habits and the temptation to take shortcuts.
Design has a variety of effects. Approached naively, design can raise expectations and then confuse and complicate the actual process, inundating unprepared developers with distractions and implicit requirements. On the other hand, a proper approach to harnessing design for software development can ensure that the end product is both relevant and beautiful. Along the way, the collaborative aspects of design process can align stakeholder's expectations and even save development time by using prototypes to communicate project goals.
Design - whether it be "Interaction Design," "User Interface Design," or "Experience Design" - is not retrofitting a screen with pretty graphics. Applying design to an existing project provides limited value. Design in software development is much more valuable when applied as a way to discover, refine, and execute proper success criteria.
Addressing the MID Form Factor
The Mobile Internet Device, or MID, is a low-power mobile device with many of the capabilities of a full PC. It employs a small, high-resolution touch screen and a reduced keypad. The MID platform provides unique new usage opportunities and advantages that translate into an exciting new market opportunity. MIDs offers new capabilities in terms of computing power, display quality, touch-input quality, and connectivity, along with a high amount of energy invested in the software tools.
The way the platform's promise translates into value to the end user is through the software running on it. Software turns abstract capabilities into user-facing features. Software applications will decide the fate of the platform: Compelling usefulness will give mobile internet devices a place in our everyday lives, bringing success to the platform. Falling short, MIDs will join our Palm* Pilots in the gadgets drawer, awaiting their fate at the next garage sale.
The platform's promise does not guarantee success. MIDs faces some specific challenges in terms of application development - challenges that design can help address.
With or without all the power delivered by a MID, the small device form factor limits the gamut of interactions that people will want to engage in. Comparing the same task on a small device and a large device, the small device requires more dexterity and concentration from the user. Simplifying tasks for small devices means challenging the user's habits and expectations.
The limited out-of-the-gate user base constrains the economically sensible investment to be made. Development teams will be lean and schedules will be short, even as the application development community is still familiarizing itself with the MID development environment.
Many projects are ported from existing implementations on other platforms. Considerable updates to such projects are often required to allow them to take full advantage of the specific conditions offered by MIDs.
Smart phones, with ever-growing capabilities, and the booming netbook contest the space for the MID platform. Acceptance for MIDs depends on unique value which neither of these other device classes can offer.
Establishing a Target Design
In software application development, challenges are not unusual. Any software development project, regardless of the platform, comes with challenges. The way to mitigate the risk associated with these challenges is to decide upon a focused, valuable target, and to stay on this target.
At the heart of a software application is the basic idea, "does it do something useful?" For the application to be successful, the answer must be "yes." A software project starts with existing ideas for specific features, or with general goals. These existing goals are formalized, to arrive at an implementable specification. During this process of formalization, the goals are examined, refined and adjusted.
The first step towards the feature definition is learning who the end user is, what the end user likes, and what the end user does.
A certain amount of general knowledge about users can be derived from the MID platform goals as a whole, as well as from interpreting the usage opportunities offered by target devices appearing on the market. Beyond this common sense approach, design provides a set of tools to get a clear picture of the end user and of the opportunities for application usage afforded to the user.
A user persona provides a description of an imaginary, but specific person who would use the application. A user persona is meant to be realistic and robust. A user persona describes the habits, preferences and environment of the target character, to provide a framework from which the character would make judgments and decisions. The user persona is a conceptual simulator for the practical value of new features.
The practical use of an application is not the only question to consider. An application can be an enabler to the user, providing functionality that is socially attractive and desirable, regardless of its usefulness in a traditional sense. Idealized personas provide a handle on defining this type of functionality. Idealized personas are traditionally used in the discipline of marketing, not in the more "down to earth" context of usability. Actual people aspire to the attributes the idealized persona embodies. The idealized persona is more sophisticated then a real person, bound by fewer constraints. Some stereotypes might be used to define this persona. The idealized persona provides a sounding board for empowering, uncommon feature possibilities.
A scenario describes a situation, and a sequence of events, in which the device and the software application running on it are used. The scenario is meant to be realistic, to provide a background to judge the value of the planned application and its features. The more detailed the scenario is, the more it can serve as a source and validation point for specific ideas.
Other, less standardized forms of documentation can be used as a basis for feature definition. The assumptions and conclusions in any feature documentation can be tested and strengthened by personas and scenarios as verification points.
Personas and scenarios are speculative in nature: they are based on assumptions. To add a grounding in realism to these assets, we recommend that design research activities be performed.
Mining Reality for Knowledge: Research
Design research mines real life for project-relevant information. Common methods include surveys, user interviews, and contextual inquiry, in which the researcher engages with a user one-on-one to observe activities. Ranging from simple to very involved, the value of the research results grows with the depth of user-engagement.
Design research requires preparation time and careful analysis of data. The schedule impact must be weighed against the benefits to the project. Consider that often the benefit is a drastic reduction of risk.
For applications that provide narrow specialized feature sets for vertical markets, the value of research is fairly obvious: it provides knowledge of the problem domain to the team. For common applications with mass-market, mainstream functionality, the value proposition is more subtle: while the team is familiar with the domain, the deeper examination can provide insights into key differentiators that escape the naked eye.
Generating the Design
Equipped with a picture of a target user, and solid knowledge of the real-world context, designers unearth feature opportunities for the application. Some opportunities will be obvious from looking at a scenario. Interpreting research data and applying abductive reasoning to the problem space knowledge uncovers further opportunities.
Designers define features by mapping the opportunities and constraints to an actual software structure. To arrive at valid results, design principles are applied to guide this exercise. In absence of specific native design principles for MID devices, proven design principles from other small platforms can be used.
The actual feature definition is expressed as a vision of the resulting program, and this is done in the form of diagrams, wireframes, and visual mock-ups. Abstract features are given a concrete expression. This documentation provides a moment of truth for project stakeholders. It serves as the first concrete shared picture of "the design" and a glance at the project outcome. As the project continues, collaborative discussions will adjust this picture.
The design addresses core features first, and then it takes on secondary features such as peripheral details. One after another, parts of the application get addressed, designed, documented, designed and adjusted.
Design Principles for Mobile Platforms
For relevance to the MID form factor, Table 1 lists a set of design principles that are relevant and apply to mobile platforms.
|Mobile Platforms Design Principal||Description|
|Immediate Results||Small, mobile devices offer themselves to be used spontaneously, whenever opportunity beckons. Such an opportunity for using the device, especially when occurring in a mobile situation, may not last long, as other things compete for the user's attention. To ensure a successful user experience, the application accessed by the user must waste no time in providing results. The tasks offered by the application must be straightforward, leading to immediate results. Long sessions that require continuous user attention are better suited for a full-size PC.
The home screen application of the HP* Mini 1000 MI (Mobile Internet) Edition netbook is an example for focus on immediate results. The HP MI Edition is the Linux* version of this product. Its home screen accumulates recent e-mail, web shortcuts and thumbnails for favorite music and photos. The traditional "launch and dig" sequence to get to content is eliminated. In contrast to this approach, most other netbooks just offer collections of program icons on their home screen.
|Adequate Feature Density||Besides being short, the path to results must also be obvious. Few users will tolerate forced way-finding exercises. Given the constrained screen real-estate, this principle is applied by carefully designing decision trees to present clear decision points, and by limiting the amount of inputs asked of the user. Full-size PC applications have more leeway for less-clear structure. Feature density is an important consideration especially when porting existing full-size applications to a MID.|
|Adequate Information Density||While the small, high-resolution screen is a brilliant display, it is still, and foremost, simply small. The number of concurrently displayed content items should be more limited, to avoid intolerably microscopic text and graphics|
|Flow||Since not every interaction can be reduced to a few buttons on a few screens, the user will inevitably spend time completing non-trivial tasks. Those tasks may be necessary sequences, such as forms that must be filled, or voluntary sequences, such as meandering through a media library. In either case, the immersion that is achieved by presenting a steady stream of simple choices, creates a level of comfort. The immersion must not be interrupted trivially by modal alerts or dead-end flows. This is a general design principle, but on a small form factor platform, the temptation to present such interruptions is higher then on full-size PC applications, because fewer opportunities are available to communicate secondary information in more subtle ways.|
|Interruptability||It is a common full-size PC experience ritual to launch an application, and then to open a document, or to perform some other initiation procedure, before getting to the actual task at hand, and to save and quit the application when done. On a MID device, where application state management is not on the user's mind, and usage session durations are short, this ritual gets in the way. Dealing with any sort of sequential task becomes more feasible, even attractive, once it is possible to effortlessly "Pick up where you left off".|
|Progressive Disclosure||Progressive disclosure, the hiding of secondary information on secondary screens, is a well-known, valuable design principle. Applied to a MID, it can be read slightly differently: high density of information, as encountered in an existing PC application, can be preserved, behind lower-density summary screens, when the application is ported to a MID. Such summary screens, presented as the initial entry points of an application, provide the right small-device scale and satisfy many scenarios. More traditional, higher-density screens underneath, can provide unexpected horsepower for full-featured PC functionality. Handled with care, progressive disclosure is a valuable principle for porting existing applications to MIDs.|
Table1: Design Principals for Mobile Platforms
Look and Feel
Expressing features as parts of a software application is not a mechanical procedure. It’s a subjective process, in which the designer makes personal decisions. As a result, the application gains a unique personality. This personality is expressed in the “look and feel,” which has a great impact on shaping the user experience. The user experience - literally the string of moments the user lives through while interacting with the product - determines the user's memory and judgment about the device.
Look and feel ensures usability through design patterns that string user-facing objects together in ways that make sense. These patterns are reused across the application, providing comfort and predictability.
Look and feel is concerned with the details of the experience: the central moments when the user pays detailed attention, and those less important moments that lie in between and help string the important ones together. All these moments benefit from the beauty of well-executed emphasis and guidance, through visual means like composition, contrasts and harmonies on a pixel level.
The user’s experience of an application is shaped over time, as the application changes state during use, bringing up one screen after another, or updating the content that is shown on the screen. This temporal aspect of the experience is part of look and feel too. It can be shaped to provide a good flow, actively help the user with tracking the application’s state, through meaningful transitions.
Iconic examples of strong, experience-shaping look and feel are the “Fluent” interface of Microsoft* Office 2007, or the category-defining appearance of the Adobe* Lightroom application. Such strong statements can be controversial at first, as they force users to jettison old habits. But they usually establish a following and invite imitations.
Implementation Complexity as a Concern
While working on the ‘look and feel’, the designer must be aware of the implementation platform, and its constraints and opportunities as they relate to the user interface. For MIDs, Hildon* is the primary choice platform, and it has some very specific characteristics. It cannot be emphasized enough that the design must be implementable on the given platform, by the developers tasked with the job, in the timeframe available.
To avoid surprises, it is essential that the actual development team members who are responsible for the UI execution provide their perspective to the designer during the look and feel work. A professional designer is prepared to listen.
With a design team on board, there usually is a temptation to go for a totally custom UI, to maximize usability, beauty, flow, and branding. These are noble intentions, but must be checked against the realities of schedule- and resource constraints. A simpler look and feel that is actually executable might be a better way to go. After all, the measure of success is the real product that makes it to market.
To ensure that the project is on track, the design must be truly understood by all stakeholders. A particular asset can communicate the design much better then any combination of diagrams, wireframes and specification documents: the prototype.
Expressing Living Features: A Prototype
As the regular implementation preparation proceeds, a design team can provide a valuable contribution typical project constituents can’t - a prototype. A developer, sometimes called a design technologist, puts the prototype together. This prototype shows core moments and aspects of the application. The ideas shown are those of the project team as a whole, as captured from the stakeholders. The design team shapes these ideas, infusing them with a user-facing structure that eventually evolves into a coherent look and feel. The main value of a prototype is its ability to play out concurrent changes from multiple separate angles of the project. Valuable time can be saved this way, and the project team can cover a lot of ground in the process.
The prototype is an antidote to analysis paralysis. Application structure, functionality, and look and feel come together as a unit and are refined together. The in-progress result is visible to the entire team, serving as a validation point. The aspect of validation can be taken further, by presenting the prototype to users, who provide both usability feedback and emotional responses, without the need for preparation of additional test assets.
The prototype neither has to be perfect nor complete, as long as it provides meaningful insights. Bugs and dead ends are allowed and expected, so the developer can focus on relevant details.
As the prototype is built out, it takes on the role of a living specification, replacing much of the traditional specification documentation that otherwise must be written and maintained. Traditional specifications still play a supporting role, filling in detail for areas that the prototype doesn’t cover. The application developers refer directly to the prototype as a reference for the implementation. The QA team can do the same, informing a traditional QA process by referencing the prototype, bringing efficiencies to the testing process.
To Do This, Do You Need a Designer?
The answer to the above question is, “it depends.” Do you have enough knowledge of your problem space to perform a well-grounded feature definition? Do you have the time to take care of the details for a good follow-through? Will your stakeholders take care of this for you?
It is evident that not every good piece of software is produced with the involvement of a dedicated designer or design team. Much useful work, in terms of crisp feature definition and high execution quality, can be done by “simply” assuming a design perspective.
This reliance on common sense thrives when a self-motivated developer is driving the work and making her own decisions, within a manageable scope of work. But the efficiency of this approach does drop off, experience suggests, as the complexity of the challenge grows and more stakeholders come to the table. This is not at all a matter of malevolence by any stakeholder: all parties do want the best outcome. It is more a matter of entropy: as more perspectives and opinions come into play, more forces are at work. In such a situation, any perspective that is not formally represented will not be heard. Ask yourself: who is representing the end user?
…And Addressing Complexity
As project size increases, the complexity of the design-addressable challenges also grows, quickly reaching a point where common sense falls short. Here, the benefits of a professional perspective become obvious. Just as the development team should not be handling accounting on the side, it is not in a position to be handling design. The design team’s role is not meant to weaken other project contributors design ideas. On the contrary, the design team synthesizes everyone’s contributions, amplifying the good ones. This synthesis is essential when many different perspectives need to be heard. On large projects without formal design participation, design will go wrong.
Engaging a design team can bring otherwise unattainable results to a software project: a unique execution, with an outstanding look and feel. This can turn out to be the single, critical differentiator in the marketplace.
Change the Odds
Full-size desktops and laptops have long given up their position as the only form factors for personal computing. After small form factors had been pioneered by the PDA, the mobile phone matured to provide ad-hoc information access and media consumption. The laptop as sole choice for mobile content creation and productivity has made room for the netbook, its smaller, less powerful sibling. Each of these form factors thrives on useful, attractive software. That’s evident when you consider the variety of software being used on near-identical hardware.
The MID form factor is in a position to be the next step in this march of personal computing to ubiquity. New form factors start as an underdog. To fuel their possible success, great applications first have to be created, under developmental conditions that are more challenging than those on established platforms. As the software industry comes to terms with the platform, design can make a contribution to the quality of individual software experience offerings, which is what counts most at the current moment in the lifecycle of the platform.
About the Author
Knut Graf is a Principal Designer at frog design, a global innovation firm. Frog Design* works with the world’s leading companies, helping them create and bring to market meaningful products, services, and experiences. Knut joined frog in 1997 and has since served as Developer, as Content Architect and as Senior Design Analyst before assuming the role of Principal Designer. Knut has worked with clients such as SAP*, Microsoft*, and HP*. His recent work includes contributing to the well-received HP Mini 1000 MI edition user interface as a design lead on the project.
Knut's work focuses on software user interfaces, from idea development to implementation. He guides software designs through the time and resource constraints that real-world software projects bring, ensuring that the user experience of the end product is of the highest quality possible.
In his work, Knut brings a programmer’s view of software development to a German design education background, to create innovative solutions that empower both the end user and the development team that has to meet shipping deadlines. In Knut’s opinion, design work must be judged by the quality of the end product. It is the actual result that matters, not the unrealized potential.