100 Ideas for Envisioning Powerful, Engaging, and Productive User Experiences in Knowledge Work
Download E-Book or Order Softcover Book In addition to this website, Working through Screens is available in several other formats: - Softcover print on demand books - Free letter size .pdf - Free large format .pdf - Free "Idea Cards" .pdf View all Working through Screens Formats |
| Email List Join our email list to receive updates about our publications: |
| Contact Our Consulting Studio Contact Flashbulb Interaction to find out how we can help your team to better conceptualize and deliver your next application design. E: info@FlashbulbInteraction.com P: 206.280.3135  |
| Latest Studio Updates From our FlashbulbUX Twitter feed:  |
| Feedback on Working through Screens? Email us your thoughts or Twitter @FlashbulbUX |
Introduction The Experience of Modern Knowledge Work In a growing number of contemporary workplaces, people are valued for their specialized intellectual skills and their ability to act on and with complex information in goal oriented ways. There is a general sense that many types of work are becoming more abstract, specialized, complex, improvisational, and cerebral. Peter Drucker called the people that engage in these types of work “Knowledge Workers.” Robert Reich, the former U.S. Labor Secretary, used the term “Symbolic Analysts” to describe a similar category within the workforce. More recently, Richard Florida has defined the characteristics of “the Creative Class.” All three of these terms fall within roughly the same frame, emphasizing the commonality of inventing, producing, interpreting, manipulating, transforming, applying, and communicating information as principle preoccupations of these workers. The current experience of this purportedly new work — what it feels like to practice a highly trained profession or to simply earn a paycheck — has a very different essential character than the type of work experiences that were available just a generation or two ago. A large part of that change in character is due to the extensive use of computing tools in these work practices. In essence, the expansion of “knowledge work” as a concept has been closely tied to the expansion of computing. Interactive applications have become woven into the fabric of vast territories of professional activity, and workers are continuously adopting new tools into previously “offline” areas. Although these tools are not the only focal point for knowledge workers, they are becoming a point of increasing gravity as cultures of practice continue to co-evolve with these technologies over time. Consider these example experiences, which are part of the working lives of three fictional knowledge workers who will appear throughout this book: An architect considers an alternate placement for an interior wall in order to improve the view corridors within a building that she is designing. As she interactively visualizes a certain wall placement within a 3D model of the building, she pauses to consider its implications for a number of the project’s requirements. She saves different versions of her design exploration, adding working notes on what she thinks of each design direction. Once she has created several different directions, she then uses the building modeling application to realistically render each possibility, compare them in sequence, and review a subset of design options with her colleagues.While these short descriptions are probably not representative of your own day to day activities, it may be easy enough for you to imagine how essential interactive applications could become in each of these cases. After long periods of accommodation, accomplishing many knowledge work goals involves turning to a screen, controlling a cursor, entering data, and interacting with well known and meaningful representations of information. Looking toward future technologies, it is likely that most knowledge workers will perform at least some of their efforts within the bounds of a similar framework for some time to come. The Impacts of Application Design The design of these computing tools has the potential to make massive impacts on working lives. Unless knowledge workers are highly motivated early adopters that are willing and able to make use of most anything, their experiences as users of interactive applications can vary drastically. These differences in experience can largely depend on the overall alignment of an individual’s intentions and understandings with the specifics of a tool’s design. Since the majority of the computing applications in use at the time of writing were not created by the workers that use them, this means that the product teams developing these applications contribute roughly half of this essential alignment between user and computing artifact. To restate this common premise, “outside” technologists (of the stripe that would likely be drawn to reading this book) often set the stage for initial success or failure in workers’ experiences of their onscreen tools. Direct alignment with an augmenting tool can cause surprising joy, or at least a sort of transparent, “on to the next thing” sense of success. Individuals and organizations can place a high value on useful and usable products that support workers’ limitations while at the same time enhancing their skills. Truly successful interactive applications can provide users with tailored functionality that, among other things, facilitates and enhances certain work practices, powerfully removes unwanted effort through automation, and generates dynamic displays that make complex relationships clear. In short, when interactive applications are at their thoughtfully envisioned best, they can become seemingly indispensable in knowledge work. At their most visionary, these tools can promote user experiences that provide a sense of mastery and direct engagement, the feeling of working through the screen on information and interactive objects that become the almost palpable subjects of users’ intentions. Issues in Contemporary Onscreen Tools Unfortunately, many knowledge work products present themselves as nowhere near their thoughtfully envisioned best. Workers too often find that many parts of their specialized computing tools are not useful or usable in the context of their own goals or the larger systems of cultural meaning and activity that surround them. Problematic applications can continuously present workers with confusing and frustrating barriers that they must traverse in order to generate useful outcomes. At their poorly envisioned worst, computing tools can — contrary to marketing claims of advanced utility — effectively deskill users by preventing them from acting in ways that even remotely resemble their preferred practices. Not exactly the brand promise that anyone has in mind when they start the ball rolling on a new technology. If one was to summarize the status quo, it might sound something like this: when it comes to interactive applications for knowledge work, products that are considered essential are not always satisfactory. In fact, they may be deeply flawed in ways that we commonly do not recognize given our current expectations of these tools. With our collective sights set low, we overlook many faults. Poorly envisioned knowledge work applications can: Attempt to drive types of work onto the screen that are not conducive to being mediated by interactive computing as we know it today. New applications and functionalities are not always the answer, and some work practices can be more effectively accomplished outside of the confines of a computer.These example points, which represent just a sampling of the many problems that can be found in poorly envisioned knowledge work applications, call attention to the fact that these potential issues in users’ experiences are not “soft” considerations. All of these points have implications for workers’ satisfaction with a computing tool, their discretionary use of it, the quantity and quality of their work outcomes, and their perceptions of a product’s brand. The sum of the above points can be viewed as a fundamental threat to the core goals of organizations that are seeking to adopt new technologies as a means of supporting their knowledge workforces. Making Do with the Status Quo Since many of today’s applications contain a mixture of both clear and direct functional options and functionality that is frustrating, obtuse, and effectively useless, knowledge workers often become skilled at identifying those portions of technologies that demonstrate benefits relevant to their challenges. Individuals tend to weed out problematic features from their practices, while at the same time salvaging tried and true methods. Over time, the plasticity of mind and culture can display a remarkable ability to overcome barriers and interweave “satisficed” benefits. After considerable effort, established work arounds and narrow, well worn paths of interaction can emerge. An uncompelling, difficult tool can become another necessary reality. The status quo continues, despite the ongoing promise of augmenting specialized, thinking work with computing. At the level of individual knowledge workers’ experiences, attempting to adopt and use poorly conceived applications can lead to frustration, anxiety and fatigue. These negative mental states are not conducive to people successfully accomplishing their goals or being satisfied in their working lives. Put another way, knowledge work applications have the capacity to detract from the pleasure and well being that people experience as part of working in their chosen professions. Knowledge workers often do not contribute their efforts solely for compensation in an economic sense; their actions are intertwined with personal purpose and identity. For this reason, a major deficiency in a knowledge work application can be said to have a different essential quality than a failure in, for example, an entertainment technology. When a knowledge work application becomes an obstruction in its users’ practices, vital time and effort is wasted. Beyond the obvious business implications of such obstructions, it is difficult to sufficiently underscore the potential importance of these losses to individual workers, especially when developing products for highly skilled individuals who are seeking to make their chosen contributions to society and the world. So how did we get here? Where did this status quo come from? Why are these tools not better designed? Why do the brand names of so many knowledge work products conjure disdain, or only a vague sense of comfort after having been extensively used — instead of something more extraordinary? We can assume that no product team sets out to deliver a poorly conceived tool to knowledge workers. And yet, even with good intentions, that is what many have done and continue to do. Ironically, even tools designed for niche, domain specific markets — which can represent the most concrete opportunities to create truly refined tools for specific work practices — are not immune to these problems. In fact, they may be especially susceptible to them. First Steps of Application Design Taking a step back, it can be useful to examine the early, initiating steps that lead to the creation of a knowledge work application. Plans for a new or revised computing tool can arise in a variety of ways, though there are some common patterns to their early gestations. In general, a small core of initiators defines a product’s principle mandates before a broader cross section of team members and disciplines are brought onto a project. These early conversations may take on very different forms depending on, for example, whether a product represents a disruptive technology or a competitive entry into an established category of knowledge work tools. In any case, teams’ invest some part of their formative discussions considering their offerings’ potential driving forces, brand positioning, and underlying technological characteristics. These efforts typically involve modeling ideas about potential opportunities in targeted market segments, which often correspond to a particular range of knowledge work specialties and organization types. During this early initiation, product strategy efforts for knowledge work applications often do not involve “design thinking” in any real sense. When faced with the complexities of scoping and conceiving a viable computing tool, design ideation, at the time of writing, seems to typically take a back seat role. This is in stark contrast to many other types of products, especially outside of computing, where design thinking is increasingly being used as a key approach in early, initiating conversations. One does not need to look very far to see how generative concepting of potential user experiences has become a central exercise in the development of many of today’s successful brands and product strategies. Yet in the much “younger” and relatively distant disciplines that develop complex onscreen applications, the potential for design’s strategic contributions has not been adequately recognized. Getting to Design Details Too Quickly At the end of a knowledge work product’s initiating conversations, when it appears that a project will become a funded and staffed reality, there is often a strong desire from all involved to see “something” other than high level abstraction and textual description. The common response to this desire is where foundational user experience problems begin to crystallize. In a characteristic straight to the details progression, teams quickly, instinctually move from high level consideration of product strategy into the smallest specifics of a product’s definition, design, and implementation. Their approach jumps abruptly from the global to the extremely granular, without the connective tissue of a holistic middle ground. Part of the reason for this jump in collective mindset is an increase in team size. Left to their own devices, newly added team members often gravitate toward the level of granularity that is their primary focus during the extended course of product development. To a specialist, this makes perfect sense. These detailed skills are what they are typically valued and promoted for, and their narrow expert perspectives are presumably why they are brought onto projects in the first place. The problem with these assumptions is that, when getting into details too soon and too narrowly, specialists’ decisions may be under informed and lacking a larger vector of creativity and guiding constraints. The commonly cited maxim of the influential designer Charles Eames, “the details are not the details, the details make the design,” is a useful truism in the extended development of viable computing applications for knowledge work. After all, if a specific part of a user interface is missing important options for the work practices that a tool is designed for, then its usefulness and usability will suffer during real world interactions. Armed with this understanding, some technologists immediately begin their journey away from the vagaries of a product’s strategy toward something more “real.” Without considering how they might be stifling their own success and innovations, these teams begin haphazardly anticipating workers’ detailed needs and possible complaints as a means of sketching a satisfactory concept for their product. The path of the straight to the details progression is predictable and common. Product teams enacting this progression begin implementing without the vector of a larger design strategy to guide them through the many highly specific choices that will inevitably follow. Their initial conception of their product is relatively simplistic, but they believe that they can continually map out the complex specifics along the way, whether in diagrammatic illustrations, textual specifications, or in working code. They move forward with the implicit assumption that interactive applications, being made of abstract computer language, are somehow highly malleable, and that all encompassing “fixes” can be made when needed. In reality, product teams creating knowledge work applications rarely have the luxury of extensive downstream revisions, despite their deep seated assumptions to the contrary. When they do enjoy the luxury of such changes, the cost of these revisions can be prohibitively high. For this reason, key corrections, additions, and improvements are all too often put off for the “next version,” or “next public release” with the assumption that users will be able to work their way around any issues in the meantime. Facing limited resources and complex challenges, many teams develop distorted notions of what constitutes acceptable, or even exceptional, quality and user experience. While specifying every detail of a complex interactive application before any implementation takes place is also not generally considered a viable approach to product development, at the time of writing, the pendulum seems to have swung too far in the direction of improvising design strategy. Prevailing straight to the details ideologies are largely out of step with the reality of resulting product outcomes. A survey of the inflexibilities, over extended interaction frameworks, and scattered conceptual models of contemporary knowledge work products in many domains can sufficiently prove this point. Adding Features Until “Magic Happens” Behind the straight to the details progression is a belief that a successful, even visionary, product will somehow emerge from the sum of countless detailed definition, design, and implementation decisions (see Figure 1). In this view, applications can evolve from a collection of somewhat modular pieces, so long as the assemblage does not somehow “break” in the context of users’ human limitations and cultural expectations. Keep working on the details and magic will happen — or so the assumption goes. The larger gestalt of an interactive application receives little or no consideration in this framing of product development. Teams with this mindset do not typically sketch diverse concepts for how their creation could mediate work practice in appropriate, innovative, and valuable ways. To overstate the case, many product teams believe that knowledge workers can be supported by directly giving them what they want, adding details to a tool as needed in a somewhat systematic manner. This approach may work for a while — until tools collapses along fundamental, structural fault lines of conceptual clarity, information display, and meaningful consistency.  Even though the magic happens expectation often results in poorly designed computing tools for knowledge work, the straight to the details progression may be successfully applied to other types of onscreen products. This might explain why many product teams creating knowledge work applications still hold on to these shared assumptions — there are positive examples and well known brand names that can serve as their reference points. When a product’s goals are relatively simple or very well characterized, as in a highly established genre of application, teams can have a shared grounding without actively taking time to grow that collective understanding. For example, everyone in a typical product team probably understands how a collaborative calendar application works, because they use them every day. If their understanding happens to be less than complete, team members can probably round out their views without too much difficulty or discussion. A product team may even be able to create real innovations in this kind of application by making incremental changes in small details based on assumptions about unmet needs. Crucial Understanding Gaps Tools for specialized knowledge work typically do not fit this sort of “make it up as we go” mold. One of the main reasons is that product teams inevitably have a difficult time understanding the work practices that they are striving to mediate. They do not tacitly know the cultures that they are attempting to support. A base level of understanding about larger systems of activity and meaning is necessary in order to design a useful tool that will be well suited for those systems. Teams need to understand what the architect Eliel Saarinen spoke of as the “next larger context.” Software developers, for example, do not inherently know what it means to analyze clinical research data, let alone how that data fits into the larger flows of activity within a research lab. When technologists find it difficult to understand the many specifics of foreign and elaborate work practices, they may unwittingly hold onto an initial, roughly hewn, consensus view about knowledge workers’ activities and needs. This view can become their framing point of reference throughout the development of their product, despite incoming information that could valuably transform it. In practice, the momentum of a disoriented group’s initial concept for their computing tool often places certain ideas at the primary, driving core of what is eventually developed and released. What the architect and psychologist Bryan Lawson calls a “primary driver” takes hold in their design outputs. And in these cases, as end users of such products can attest, magic does not often happen. Uncritical Reliance on Pioneering Ideas If the pioneers of interactive computing had only been thinking about detailed design decisions, at the expense of the bigger picture, they would have likely never envisioned many of the conventions that we commonly use today. For example, Douglas Englebart, a pivotal figure in the pioneering era, has defined much of his working life based on a series of epiphanies about how technology could enhance human problem solving. During a time when computers were still primarily used for batch process mathematical tasks, he envisioned remarkable possibilities for the application of computing to knowledge work. Of particular interest is Englebart’s astonishing 1962 description of an architect using interactive computing as a fluid part of complex work practices, long before such a future had been realized. In his essay “Augmenting Human Intellect: A Conceptual Framework,” Englebart outlined how an architect might use a computer to review a symbolic representation of a building site; consider different scenarios in excavation and building design; refer to handbook and catalog resources; locate windows so that light is not reflected into the eyes of passing drivers; examine the resulting structure to ensure that it does not contain functional oversights; and store the resulting work for later retrieval and annotation by stakeholders (the architectural examples used throughout this book are an homage to Englebart’s landmark application concept). Pioneers of interactive computing, such as Englebart, did not have the luxury of working only at the detailed level of their emerging creations. They also set the vision and goals for their own and subsequent generations of technological development. Looking objectively at the conversations taking place in product teams today, it appears that many technologists are relying very heavily on these and other proceeding foundations. Not on the intellectual spirit of these foundations, but on their literal conventions. As knowledge work applications have become standardized and commonplace within technologists’ worldviews, it seems that we may have all become limited by a shared, infrastructural sense of what these tools can and should be. People creating these products have, to some extent, stopped examining them through a critical lens that could uncover important new possibilities. As they continue to copy and tweak existing standards, we become increasingly accustomed to a certain rate of change and a certain level of generic, all purpose design. While vernacular evolution certainly has its place, repetition of familiar patterns is clearly not the entire picture of exceptional design process. Knowledge work tools can be much more than the sum of their discrete functional parts. A sole focus on detailed salvaging and assembling of the past leaves no room for other, important pursuits. If product teams do not explore different strategies for their application’s overall approach to mediating work, how will they imagine new tools that truly and valuably fit into workers’ specialized thought processes and cultures? Embracing a More Strategic Creativity Appropriate and exciting concepts for knowledge work tools are built on holistic vision, not just pattern matching and incremental iteration. They require a carefully considered design strategy to tame their potential complexities into clear, useful, and desirable simplicity. The very idea of design strategy implies the selection of one direction from a pool of potential approaches, yet the magic happens expectation restrains breadth and ideation by promoting a narrow track of implemented reality. In essence, teams following the straight to the details progression are practicing single vision and concept design. The essential, elemental “shapes” of their products are the shapes that happen to unfold in front of them after the sum of many small decisions. They deemphasize a larger type creativity, which in turn reduces possibilities for useful and compelling innovation. So how can product teams creating interactive applications for knowledge work embrace this larger type of creativity? If the straight to the details progression, the magic happens expectation, and single vision and concept design characterize the mindset that eventually leads to problematic or failed computing tools, what mindset can teams adopt to avoid these pitfalls? Introducing Application Envisioning Generally speaking, product teams can cultivate a perspective of targeted yet open exploration, without analysis paralysis. They can spend more time in the space between product origination and product implementation. They can create an environment where divergence and a multiplicity of ideas are valued in their discussions. They can forgo an early emphasis on specifics by creating abstract models that visualize their understandings and outline potential spaces of design possibility. They can ask more questions in their targeted markets and sketch novel concepts for how their products could play a role in knowledge work, while documenting tangible evidence of their ideas. They can balance top down decision making with bottom up input from knowledge workers in order to synthesize singular design strategies. These strategies can embody a strong brand positioning and the grounding of a team’s best application concept, assembled from a core set of sketched functionalities that target a carefully chosen scope of work practices. This suggested approach can be summarized by the following phrase, which appears in the opening pages of this book: Is there a repeatable methodology or process to advance this change in mindset and general approach? Not in any strict sense, because these explorations are very emergent and freeform, despite their focused nature. However, a name for this period between project initiation and project implementation could allow teams to effectively plan for it. The term application envisioning suggests an early, separate interval in product development in which teams can intentionally and collaboratively consider potential design strategies and design concepts for their computing tool, rather than sliding down a largely unconsidered course (see Figure 2).  Application envisioning can allow teams to cultivate empathy for targeted knowledge workers and their worlds, lay the ground work for inspiration, explore diverse questions and ideas about what their product could be, and develop a shared, big picture view — with the assumption that many important details will need to be fleshed out along the way to a completed release. One (increasingly routine) process suggestion for application envisioning is that this early, explorative time presents a significant opportunity for product teams to get out of their offices and into the field. Teams can strive for “what it’s like” understanding of knowledge workers’ current experiences by directly observing and engaging in their worlds. While immersed in the activities that they are striving to mediate with computing, teams can uncover unmet needs and other important insights for design strategy. This immersion may also lead them to start thinking about their product as a service, either literally or in spirit, which can highlight new areas for innovation through ongoing, networked connection. Teams may take a sense of partnership with targeted workers so far as to invite them to become collaborators, maintaining a healthy level of humility in the face of their expertise. Another process suggestion is for product teams to look outside of the work that they are targeting in order to cast new light on their envisioning questions and their emerging design concepts. While pioneering figures of interactive computing had to work from an essentially blank slate, today’s technologists do not have to start from square one when they think about what it might mean to augment certain thought processes and activities with computing. There is a growing body of research and critical perspective that teams can use as lenses for making sense of these complex, multifaceted design problems. In order to extract potential strategic principles, teams can examine computing tools that have been successfully adopted into similar activity contexts within other types of work practice. Advanced analogies to products in other domains can lead to inspiration that may fuel truly novel solutions that draw upon seemingly unrelated fields of endeavor. The idea of application envisioning has strong parallels to mindsets found in other, older design disciplines, whose practitioners more commonly apply design thinking in strategic ways. For example, product teams creating computing tools for knowledge work can learn a great deal about envisioning new technologies from the successful practices of the best industrial design teams. These teams also shape peoples’ daily lives through their creations, albeit with a focus on the mass produced, physical embodiment of material culture. Industrial designers typically take time early in their projects to explore different concepts so that they can divine the “right” overarching direction for their product, rather than immediately honing in on and elaborating a single solution. These designers often conduct various forms of research, synthesizing models of their problem space before moving forward into design ideation. Once they begin ideating, they typically sketch thumbnail after thumbnail of potential options, long before they even consider realistic renderings or exacting specifications. From these early explorations in “design research,” industrial design teams can uncover important constraints, possibilities, and languages for their product. They can discover potential emotional connections with end users and gain empathy for the context of a successful offering and brand, all of which puts them in strong position to define singular and compelling design strategies. The Higher Goals of “Flashbulb Interactions” Envisioning a diverse range of appropriate possibilities for a product is not an easy task. Even with a shared emphasis on a multiplicity of ideas, practitioners of all design disciplines sometimes face the lure of literal, small scale iteration of known patterns when more innovative responses could be appropriate, valuable, and feasible. Application envisioning efforts can represent a fundamental change in how product teams define and design interactive applications, but this change alone may not be enough to arrive at exceptional tools for knowledge workers. Without higher order goals that aim to truly augment peoples’ intellectual skills and abilities, application envisioning can become just another phase in product development, without any of the intended, strategic payoffs. A team’s own infrastructural grounding in the conventions of computing can easily stifle threads of divergent, meaningful concepting. The gravity of the known can easily preclude more creative questions and proposals. A new term may be useful to product teams as they attempt to uncover new sources of value in knowledge work computing. Flashbulb interactions are a branch of sorts off of the term “flashbulb memories,” coined in 1977 by Roger Brown and James Kulik in the psychology literature. A flashbulb memory is a recollection that stands out as a clear and pivotal moment, a punctuated experience in the compilation of one’s past. In a similar vein, a flashbulb interaction is one of those rare moments when an interactive application impacts a knowledge worker in some profoundly positive way, such as making a complex conclusion clear or opening up a new vista of thought. Product teams can explore how their computing tools might promote flashbulb interactions by beginning their projects with these high level questions: What are the big picture problems that knowledge workers currently face in their work practices? What mental work is currently difficult?These questions are a direct attack on low expectations of technologies for knowledge work. They contain an optimism that is similar to pioneering questions that lead to the creation of interactive computing, but they can be applied to the grounded particulars of specific challenges that product teams face today. Most importantly, when technologists have asked these questions, they may find it difficult to fall back on literal, small scale iteration of known design patterns, knowing full well that more innovative responses could be appropriate, valuable, and feasible. Product teams are not likely to know if and when they have generated design strategies and conceptual sketches that could result in products that meet these aspirations, but that sort of absolute decision making is not the point of conducting these inquiries. Instead, teams can pose these and other questions about flashbulb interactions in order to take their eyes off of the conventional state of knowledge work computing and begin considering potential narratives for exceptionally positive user experience. This change in perspective can uncover surprising ideas and design constraints that, in turn, can help teams to better understand deep seated opportunities that their application might address, as well as what those solutions might look like. Summary of Case for Application Envisioning To summarize, contemporary computing tools for knowledge work often contain significant design deficiencies — both recognized and overlooked — that detract from people’s working lives. Looking beyond the current state of these tools, interactive computing has remarkable potential for improving thinking work. An early emphasis on design strategy and design concepts, not design details, can be crucial for developing truly successful computing tools in this space. Product teams that embrace early envisioning as a central exercise in application development, along with significantly elevated goals for user experiences, can generate appropriate and innovative possibilities for emerging generations of knowledge work tools. By intensely questioning what it could mean to mediate specific thought processes and work practices with an interactive application, these teams can develop tools that deliver more enjoyable and relevant experiences, better work outcomes, improved brand loyalty, and other valuable results. Using This Book This book is a tool for product teams to use as they envision new or iteratively improved knowledge work applications. It presents 100 ideas that can remind teams of common factors for the design of extraordinary computing tools, helping them to generate a greater diversity of sketched models, frameworks, and concepts. Each concisely presented envisioning idea is a specific consideration for early, formative conversations about what an application might become. These random access topics are intentionally enmeshed and overlapping, not mutually exclusive. The categorization of the 100 ideas sketches an overall framework and is intended to improve their collective accessibility as an envisioning reference. The resulting collection is a practitioner oriented synthesis that can expand the range of questions that product teams explore as they generate potential design strategies and design concepts — inherently raising their shared expectations for their products’ positive impacts on knowledge work. The 100 ideas themselves can be traced to a range of sources and perspectives in product strategy, human factors, human computer interaction, systems analysis, industrial design, interaction design, information architecture, usability research, computer science, and other professional specialties. Many of the ideas are rooted in commonly cited considerations and guidelines, though they have been framed here specifically for use while envisioning computing tools for knowledge work. Some of these commonly cited points call out specific functionalities that are currently available in a subset of contemporary products, while others touch upon broader connections to the technological contexts that workers’ practice within. This book also borrows liberally from those authors who have put forward ideas that have advanced my own work as a practitioner providing research, strategy, and design services. These publications can be found in the bibliography. Beyond commonly cited ideas and valued references, a number of the 100 ideas can be traced back to specific stories from real world product teams. These envisioning ideas were considered assumptions in some groups of technologists and missing in others groups in a way that pointed to their value. A variety of audiences may find the 100 ideas in this book useful: Product managers and other leaders within organizations can use these ideas to promote innovative design strategies and to inspire their teams to set higher goals for product success.Book Approach and Exclusions Although much of the text is written as if the reader is part of product team designing a new knowledge work application, the same ideas can apply when revising or extending an existing tool. Similarly, the tone — but not the primary information — of this book often reflects the interests of product teams working in commercial contexts. Please note that this book’s ideas might be just as applicable to tools created by an open source community or developed internally within knowledge work organizations. 100 ideas is a very round number, and it points to the limitations of this book. Just as there is no set recipe for effective product development, there are many other, equally valid ideas for envisioning interactive applications for knowledge work. The ideas in this book were selected due to their potential impacts in a wide range of application envisioning conversations. Many of the ideas represent generally important considerations that are commonly overlooked in contemporary products. That being said, some of the ideas will presumably be much more important for specific product contexts than others. None of the 100 ideas are universals or do-or-die edicts. Please take them or leave them, depending on the situation you find yourself in and your belief in their value. The reader will find few mentions of specific technologies in this book, other than frequent references to certain genres of networked applications used in architecture, clinical research, and financial trading. For example, this book does not focus on Web technologies, even though the 100 envisioning ideas could be extensively applied to Web based tools. There are also limited references within the 100 ideas to specific methodologies, other than some general approaches to modeling work practice (the hierarchy of operations, tasks, and larger activities is coarsely adapted from Alexei N. Leontiev’s Activity Theory) and interactions (Ben Shneiderman’s “Object-Action Interface Model,” without its emphasis on direct manipulation). This exclusion of extensive technology and methodology references was intentional. Ideally, product teams using very different technological foundations and methodological approaches will find this book to be useful. In the end, all viable methodologies have some place for determining an application’s essential form and direction, regardless of what that particular process box happens to be called. Please insert this book’s application envisioning ideas there. Although this book contains ideas for the development of new technologies, it is anything but some attempt at distant futurism. Instead, the focus here is primarily on personal computing applications that could conceivably be in front of the eyes of knowledge workers at the time of writing, given the state of contemporary technologies. The domain specific examples used throughout will reinforce this focus. Although some of the functionalities described in these examples are presumably not available in real world tools (no specific products were referred to during the writing or illustration of this book), they are intended to represent realistic possibilities for interactive computing in the present tense. Thirteen Categories of Envisioning Ideas The 100 envisioning ideas are broken into thirteen different categories that form chapters of sorts. While these chapters are suited to random access skimming, some readers may benefit from having first familiarized themselves with key ideas in categories A, B, and C, such as “Interrelations of operation, task, and activity scenarios” or “Intentional and articulated conceptual models,” if they are unfamiliar with these notions. The following brief descriptions of the thirteen idea categories conclude this introductory section: Category A, “Exploring work mediation and determining scope,” contains nine ideas that can help product teams pursue useful understandings of knowledge work practice. These understandings can inform insightful models and design concepting, which can in turn illuminate where an application could provide appropriate and desirable value in workers’ experiences. The ideas in this category describe the potential importance of investigating workers’ physical and socio-cultural environments; determining tasks and larger activities that are conducive to mediation with computing tools; and supporting specialized needs related to emergent work, collaborative work, and individual, localized practices. < PREVIOUS PAGE | NEXT PAGE > Back to top | View Table of Contents |
All original contents of Working through Screens online book are subject to the creative commons license (Attribution-NonCommercial- ShareAlike http://creativecommons.org/licenses/by-nc-sa/3.0/) unless otherwise noted. Please attribute the work to “Jacob Burghardt / FLASHBULB INTERACTION Consultancy.” |