Abstract
Feature lists offer a poor vocabulary for deciding whether an authoring environment is professionally capable, overwhelming, or appropriately simple. A function can be technically present without being practically available to a given reader in a given task. Its availability depends on a route, a vocabulary, a current interface and configuration state, dependencies, an alternative method, and the evidence a reader has for predicting the function’s effects. This paper introduces capability distribution as a teaching construct for examining that relation. It does not measure software quality, rank products, diagnose readers, or recommend a universal number of features.
The paper’s instrument, the Feature Opportunity Map, records one task-relevant capability through ten fields: task, capability sought, route and moment of relevance, conceptual demand, configuration or maintenance condition, dependencies, alternative route, evidence needed, countervailing capability gain, and non-conclusion. The Map helps editorial teams, instructors, and independent writers replace a generic complaint about “too much software” with a proportionate inquiry: what capability is available to whom, for what work, under what conditions—and what would be lost by changing the field?
Teaching proposition. More software becomes less tool not at a feature count, but when a task-relevant capability is so unevenly distributed across route, understanding, maintenance, and evidence that its nominal presence cannot responsibly be treated as present opportunity.
1. The function that exists somewhere
A copy editor has one narrow job before a manuscript can move on. Thirty contributor notes have arrived in five slightly different forms. Some begin with a name, some with an affiliation, some with a disclosure phrase carried over from an earlier draft. The editor does not need a better sentence, a new layout, or a general tour of the environment. She needs to make one repeated pattern consistent without damaging the distinctions that matter.
The work area is full of possibility. There are panels for review, styles, searches, comments, automation, document structure, references, exports, histories, and preferences. The editor knows that some form of batch transformation must exist; a colleague used something like it in another issue. But “must exist” is not yet the same as “is available for this task.” The route could begin with a command whose label uses a vocabulary she does not connect to contributor notes. It could depend on a saved search, a configuration choice made by a previous editor, a structural view that is currently closed, or a procedure whose scope she cannot predict. It could be a shortcut, an automation, a menu path, an extension, or an option she has not been told to look for.
The editor can still perform the work one note at a time. That possibility is important: no dramatic failure proves that the environment is unusable. Yet the feature list around her has stopped being an account of what she can presently do. It has become an account of what the environment might support under conditions that have not been named.
This is the small but consequential error in many arguments about “professional” software. One environment is described as serious because it contains everything. Another is described as humane because it contains less. The first description treats capability as a pile of available objects. The second treats immediate relief as evidence that nothing essential was lost. Neither description asks the reader to account for the relation between a function and the work that needs it.
A function is not simply present or absent. It may be visible but unintelligible. It may be legible but not relevant at the moment of use. It may be reachable only after a setup decision whose consequences are unclear. It may be routine for a specialist and a mystery for an occasional reviewer. It may make one task possible while making another task slower to find, maintain, or explain. Those are not merely differences in taste. They are differences in capability distribution.
This paper does not argue that a crowded environment is bad, that a small environment is good, or that readers who do not reach a capability need more training. It teaches a more accountable question:
What capability is relevant to this task, and through what conditions does it become available—or remain only nominally present—for this reader at this moment?
The question is deliberately modest. It does not produce a product rating. It does not determine who is an expert. It asks a team to name a task, trace one capability, identify what has to be true for that capability to count as an option, and record what evidence would be needed before anyone changes the environment.
2. Why inventory is not opportunity
A long menu, an extensive settings pane, or a marketing page can establish that an environment contains possibilities. It cannot, by itself, establish what a reader can recognize, predict, use, revisit, or maintain. The distinction is easiest to miss when the desired capability is familiar to someone else. A colleague says, “It has that.” The statement may be technically correct. It still leaves unanswered whether the colleague’s route depends on personal vocabulary, a remembered gesture, a default that has been changed, a project-specific configuration, or a task pattern the present reader does not share.
The Cognitive Dimensions framework is useful here because it treats information artifacts as arrangements of trade-offs rather than as collections of visual parts. Its terms include visibility, hidden dependencies, viscosity, premature commitment, hard mental operations, and role-expressiveness.[1] The vocabulary is not a test that an application passes or fails. Its authors describe the dimensions as discourse tools and acknowledge that their definitions and coverage are incomplete.[1] That limitation is a strength for this paper’s purpose. It keeps the reader from confusing a useful question with a universal metric.
Consider the difference between three statements.
| Statement | What it can establish | What it cannot establish |
|---|---|---|
| “The environment includes batch transformation.” | A capability is nominally present. | Whether the current task can reach it, whether its scope is intelligible, or whether it can be corrected. |
| “The command is visible in a menu.” | One route has a visible label. | Whether the label connects to the reader’s vocabulary, whether a dependency blocks use, or whether the route is task-timely. |
| “An experienced editor uses it every day.” | A particular task history has produced a usable route for someone. | Whether the route is available to a different role, project, state, or task. |
Feature count collapses these differences. It makes availability look like an on/off property of a system. Capability distribution restores the missing conditions.
The phrase opportunity matters because it is weaker than mastery and more concrete than preference. A feature opportunity exists when a reader has a proportionate path to recognize a capability, judge whether it applies, proceed with enough understanding of scope, find a viable alternative when necessary, and return to the work without treating a hidden personal convention as a public requirement. This does not mean every capability must be on the first screen. Nor does it mean every reader should be able to use every advanced method without preparation. It means that claims about professional capability must specify the task and conditions under which that capability is being counted.
This distinction also changes the meaning of simplicity. A sparse surface can make a first encounter calm while relocating work into memory, settings, help files, or another person’s tacit knowledge. A dense surface can be difficult to parse while preserving a direct route for a repeated, specialized activity. Neither arrangement earns a verdict from appearance alone. The relevant question is not, “How many things are visible?” It is, “What must a reader do to make the right capability usable in the work at hand?”
3. Capability distribution is not a verdict about expertise
The language of expertise can make this problem unnecessarily moral. When one person knows a route and another does not, it is tempting to say that the first is professional and the second is not. That conclusion converts an interface relation into a character judgment. It also makes expertise sound like tolerance for clutter or possession of secrets.
Research on novice-to-expert transitions offers a more precise counterpoint. Cockburn, Gutwin, Scarr, and Malacria organize relevant work around practice within a method, movement to a method with a higher performance ceiling, vocabulary extension, and task mapping.[4] Their review notes that expert components may be seldom used and that people can persistently fail to adopt faster methods.[4] The finding does not tell us why a particular person did not use a particular command. It does, however, prevent two bad inferences: that a feature is valueless because it is unused, and that a feature is available to all relevant readers because an expert uses it.
A specialist editor who normalizes contributor notes every week may have a compact route through a complex environment. A peer reviewer who opens the document twice a year may have no reason to maintain that route. An author may have a third relation to the same capability: she needs to understand enough to review a proposed change but does not need to perform the batch operation herself. The environment has not changed. The distribution of opportunity has.
The following constructed comparison is not a usability study. It is a teaching device for keeping task, reader, and route together.
| Constructed reader | Present task | Potential capability | What may make it available | What may make it merely nominal | Countervailing gain if retained |
|---|---|---|---|---|---|
| The production editor | Normalize recurring contributor-note patterns across an issue. | A batch transformation or repeatable search-and-replace sequence. | Repetition, project knowledge, a stable configuration, a known shortcut, a recovery routine. | A hidden dependency on prior setup; uncertainty about scope; a label not connected to the task. | Faster repeat work and preserved consistency across a production cycle. |
| The occasional reviewer | Check whether contributor notes contain a required disclosure phrase. | Search, filtering, or structured navigation. | Plain task vocabulary, a direct manual route, visible results, a low-cost exit. | Reliance on specialized terms, a configuration pane, or a route meant for a different role. | Access to deeper checking functions when the reviewer’s task expands. |
| The author | Approve proposed normalization without losing an intentional distinction. | Preview, change history, or comparison view. | Clear scope, reversible inspection, a visible difference record. | An opaque automation path or an assumption that the author will understand production settings. | A more precise route for complicated revisions when collaboration requires it. |
The table does not divide people into fixed classes. The production editor can be new to a project. The reviewer can be highly skilled in another environment. The author can become the person who configures the workflow. The point is that task history, present obligation, and route all alter what a feature means.
This is why capability distribution is a map of the field rather than a diagnosis of mode state or a prescription about chosen constraints. It asks what is in the field before deciding how a reader crosses a boundary or whether a limit should govern the field. It provides a carefully bounded starting condition for later analysis: a capability may be technically present yet differently available across readers and tasks.
4. Structure, decision, and maintenance are different burdens
Feature density is often discussed as if every additional function contributes the same sort of difficulty. The evidence does not support that simplification. Structure, configuration, and decision-making produce different kinds of work.
Kiger’s experiment on menu-driven information-retrieval systems examined the depth and breadth of menu and tree structures.[3] The study’s historical conclusion about particular menu breadths should not be carried forward as a universal number for contemporary authoring systems. Its lasting teaching value is narrower: route structure is a variable in its own right. An environment with the same nominal inventory can produce different retrieval work depending on how choices are layered, named, and sequenced.
Configuration introduces another category. Xu and colleagues studied real-world system-software configuration and describe settings spaces with hundreds of parameters as daunting and error-prone.[5] In one system case, their guidelines could remove 51.9 percent of parameters and simplify 19.7 percent of the remainder with little impact on existing users.[5] Those figures are not transferable to writing environments. They should not be used to argue that 51.9 percent of an authoring interface should disappear. They matter because they expose a conceptual mistake: an option is not costless merely because it is not visible all the time. It may still impose maintenance, troubleshooting, compatibility, documentation, or handoff work.
Lin, Brown, and Hellerstein make a related distinction in their work on decision complexity in IT configuration. They model the difficulty a non-expert faces in identifying an appropriate sequence of configuration actions and report that perceived difficulty can have a different relationship to time and error from what a simple efficiency measure would suggest.[7] Again, that is IT configuration and an analogous route-planning study, not a document editor. Its value here is methodological. A task can feel difficult because the next decision is under-specified even when an observer sees no dramatic delay or error.
These sources advise against a single complaint called “complexity.” A Feature Opportunity Map therefore records three distinct questions:
| Distinction | Inquiry question | Evidence a team should seek | Mistake avoided |
|---|---|---|---|
| Route structure | Where does the reader expect to begin, and how many meaningful decisions are required before the capability can be evaluated? | Task walkthrough, information architecture, a record of labels and branch points. | Treating a visible inventory as a navigable path. |
| Configuration / maintenance | What prior setup, saved state, preference, integration, or project convention must be preserved? | Configuration history, handoff notes, permission/state checks, project documentation. | Treating a capability as free once it exists. |
| Decision condition | What must the reader know in order to choose the next step without guessing? | A think-aloud task observation, role-specific examples, a bounded test of explanation. | Equating lack of obvious error with lack of decision burden. |
The distinctions do not make the work less complex. They make the complexity describable. That is an editorial gain. A team can decide to improve labels, reduce a setup dependency, create a handoff note, preserve a specialist route, or obtain evidence that the perceived route is already adequate. It is much harder to decide responsibly when the only statement is, “This is too much.”
5. The Feature Opportunity Map
The Feature Opportunity Map is an original Wexley teaching instrument. It is not an accessibility audit, a security assessment, a product comparison, a training diagnosis, or a statistically validated scale. It is a record that forces a reviewer to name what a feature list leaves out.
A team should map one task at a time. The discipline is important. When a team maps “the whole application,” every condition becomes vague and every suggestion becomes global. When it maps “check a required phrase across contributor notes before handoff,” the relevant capability, route, state, and evidence can become specific enough to investigate.
| Field | What to record | Teaching question |
|---|---|---|
| 1. Present task and desired outcome | A concrete current objective, including the artifact and the consequence of success. | What work is actually being attempted? |
| 2. Capability sought | The hoped-for transformation, inspection, or result; “unknown” is a valid entry. | What function is presumed relevant, if any? |
| 3. Route and moment of relevance | The expected starting place and the point in the task when the capability should surface. | Where and when would a reasonable reader look? |
| 4. Conceptual / vocabulary demand | Labels, models, scope predictions, or specialized terms required to proceed. | What must be understood before action is meaningful? |
| 5. Configuration or maintenance condition | Preferences, saved states, setup work, permissions, integrations, or handoff conventions. | What must remain true for this route to work? |
| 6. Interaction / dependency condition | Other features, structural states, view modes, formats, or prior choices that affect the route. | What is the capability connected to that is not immediately visible? |
| 7. Alternative or accelerated route | A manual, default, shortcut, assistive, delegated, or specialist route—or “unknown.” | Is there another proportionate way to reach the outcome? |
| 8. Reader/task evidence | The observation, walkthrough, documentation, interview, or controlled test needed next. | What would distinguish a complaint from a finding? |
| 9. Countervailing capability gain | A function, range, or specialized route that might be lost by hiding, reducing, or changing the field. | What good work could a simplification make harder? |
| 10. Non-conclusion and next question | What the record does not establish and the next bounded question. | What should nobody claim from this map alone? |
The Map’s final two fields protect it from becoming a tool for simplification theater. A team may discover a hard-to-reach function and be tempted to move it to the first surface. The countervailing-gain field asks whether the move would burden another task, remove a high-ceiling method, break a specialized configuration, or falsely imply that every reader needs the same route. The non-conclusion field prevents the map from becoming an audit. It can say, for example: “This record does not show that the command is badly designed; it shows that the present team lacks evidence about its route and scope for occasional reviewers.”
A completed Map can be short. Its value lies in its honesty. Consider the copy editor’s constructed incident:
| Map field | Example record |
|---|---|
| Present task | Normalize recurring contributor-note patterns while retaining intentional exceptions. |
| Capability sought | A batch transformation, structured search, or repeatable pattern operation; exact capability unknown. |
| Route and relevance | Expected during pre-production cleanup; route not established. |
| Conceptual demand | Must distinguish a broad replacement from a scope-limited transformation and recognize the environment’s vocabulary. |
| Maintenance condition | May depend on a saved search, project template, local history, or role-specific configuration; unknown. |
| Dependency condition | Could depend on document structure, tracked-change state, selection scope, or format; unknown. |
| Alternative route | Manual editing exists; colleague consultation may exist; accelerated route unknown. |
| Evidence needed | A bounded walkthrough using representative notes, a scope preview, and a record of recovery options. |
| Countervailing gain | Retained automation or structural controls may save repeated production work for a specialist. |
| Non-conclusion | The record does not prove feature overload or recommend removal; it identifies a task-specific opportunity gap to investigate. |
The example is intentionally full of “unknown.” An unknown is not a failure of the Map. It is evidence that a feature claim outran the team’s knowledge. The appropriate response may be documentation, a task walkthrough, a role-specific guide, a configuration handoff, a product-neutral workflow convention, or a decision to preserve the current arrangement while more evidence is gathered.
6. The countercase: retained range can be a genuine good
Arguments for less software often become persuasive because they name a real relief: fewer visible choices can make a first task easier to orient. The problem begins when that relief is treated as the whole account. A reduction can also remove a route that a specialist needs, hide a capability that becomes relevant later, or replace a stable personal configuration with a forced generic one.
Thompson, Hamilton, and Rust’s feature-fatigue research is useful precisely because it refuses to make capability and usability identical.[2] Its consumer-product setting limits what this paper can claim. It does not tell us how writers use authoring tools. It does suggest that anticipated capability and lived usability can be differently weighted. For a teaching instrument, the implication is modest: a team should treat both as evidence questions rather than assuming that one cancels the other.
Findlater and McGrenere offer a closer, though still bounded, productivity-software countercase. Their field evaluation compared a user-controlled adaptable menu design with a particular adaptive-menu implementation in a commercial word-processor context.[6] The abstract reports that, when given a flexible and understandable customization mechanism, a majority of users personalized their interface; the adaptable condition was associated with better reported navigation and learnability than the studied adaptive condition.[6] The study does not demonstrate that personalization solves feature density generally. It does show why “full default interface” and “usable tailored route” need not be mutually exclusive categories.
The countercase changes the practical question. Instead of asking whether a function should be exposed or removed, a team can ask whether different work relations need different routes. A production editor may need a maintained high-ceiling path. An author may need a clear inspection route. An instructor may need a visible teaching route. An occasional reviewer may need a limited, explainable manual path. These are not four versions of the same requirement.
A Feature Opportunity Map must therefore contain a countervailing capability gain field. Before reducing a field, moving an option, standardizing a configuration, or declaring a route unnecessary, the team names what it might lose. The answer may be “nothing identifiable,” which is valuable information. It may be “a daily production route used by a different role,” which is equally valuable. The point is not to preserve complexity automatically. The point is to preserve the burden of explanation when someone proposes to redistribute it.
7. A review protocol without a product verdict
The Map becomes useful when it changes what a group does next. The following protocol is intentionally small enough for an editorial meeting, a workshop, or an individual’s project notebook.
First, choose one active task whose outcome matters. Do not choose a category such as “editing” or “writing.” Choose an observable objective: find the contributor notes missing a disclosure phrase; compare two versions of a paragraph; repair a repeated structural label; prepare a manuscript for a specified export; verify that comments have been resolved.
Second, name the capability sought without assuming its mechanism. “A way to identify repeated phrases with exceptions” is often better than “the search feature.” It keeps the reader open to more than one route and prevents a familiar label from settling the inquiry too early.
Third, complete the Map through the evidence-needed field. Mark unknown conditions plainly. At this stage, do not recommend a layout change, a training intervention, or a feature reduction. The work is descriptive: it specifies the task-reader relation that a feature list obscured.
Fourth, name one countervailing capability gain. This is the moment most generic simplification claims fail or mature. If no gain is apparent, record that as a hypothesis to test, not as permission to erase an option. If a gain is apparent, identify whose task depends on it and whether another route could preserve it.
Fifth, write a non-conclusion. A strong non-conclusion does not weaken the review. It protects it. “We do not yet know whether the issue is terminology, configuration history, or route structure; a role-specific walkthrough is required” is more useful than “the feature is buried.” It tells the group what evidence would make the next decision proportionate.
The protocol does not produce a universal endpoint. A team may learn that a clearer label is needed. It may learn that a specialist’s configuration has become a fragile single point of knowledge. It may learn that the current arrangement is adequate and the missing element is a handoff note. It may learn that the apparent capability does not apply to the task after all. Each result is better than a feature count because each attaches a proposed change—or a decision not to change—to a describable condition.
8. What this paper does not establish
The Feature Opportunity Map has sharp limits. It does not determine whether an interface is accessible, secure, private, affordable, or compliant with a standard. It does not measure cognitive load. It does not show that a reader is a novice, that a function is objectively hidden, or that a team should eliminate an option. It does not convert consumer-product research, historical menu research, IT-configuration work, or a particular adaptable-interface study into a general law of authoring software.[2] [3] [5] [6] [7]
It also does not replace the neighboring papers in this atlas. A reader who needs to understand what happens when a working environment shifts between modes must analyze entry, carryover, and return conditions; that is a different diagnostic problem. A reader who needs to decide whether a limit should be chosen, reversible, and contestable must analyze constraint legitimacy; that is a different action problem. This paper remains prior to both. It maps the field in which a capability becomes more or less available.
The editorial payoff is not a cleaner interface in the abstract. It is a better account of what is being requested when someone says, “I cannot find the tool,” “There are too many options,” or “Professionals need the full system.” Each statement might be true in a narrow sense. None is sufficient. The Feature Opportunity Map asks the next question: for which task, through which route, with which conceptual and maintenance conditions, against which retained capability, and on what evidence?
A professional environment need not make every possibility equally prominent. It does need a defensible account of how task-relevant possibility becomes usable opportunity—or why the team has not yet gathered enough evidence to say. That is the point at which more software becomes less tool: not when a number is crossed, but when nominal presence is allowed to stand in for the work of making a capability genuinely available.
References
[1] T. R. G. Green, A. E. Blandford, L. Church, C. R. Roast, and S. Clarke, “Cognitive Dimensions: Achievements, New Directions, and Open Questions,” Journal of Visual Languages & Computing 17, no. 4 (2006): 328–365.
[2] Debora Viana Thompson, Rebecca W. Hamilton, and Roland T. Rust, “Feature Fatigue: When Product Capabilities Become Too Much of a Good Thing,” Journal of Marketing Research 42, no. 4 (2005): 431–442.
[3] John I. Kiger, “The Depth/Breadth Trade-Off in the Design of Menu-Driven User Interfaces,” International Journal of Man–Machine Studies 20 (1984): 201–213.
[4] Andy Cockburn, Carl Gutwin, Joey Scarr, and Sylvain Malacria, “Supporting Novice to Expert Transitions in User Interfaces,” ACM Computing Surveys 47, no. 2 (2014).
[5] Tianyin Xu, Long Jin, Xueqiang Fan, Yuanyuan Zhou, Shankar Pasupathy, and Rukma R. Talwadker, “Hey, You Have Given Me Too Many Knobs!: Understanding and Dealing with Over-Designed Configuration in System Software,” Proceedings of the 10th Joint Meeting on Foundations of Software Engineering (2015).
[6] Leah Findlater and Joanna McGrenere, “A Field Evaluation of an Adaptable Two-Interface Design for Feature-Rich Software,” Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (2007).
[7] Bo Lin, Alan Brown, and Joseph L. Hellerstein, “Towards an Understanding of Decision Complexity in IT Configuration,” Proceedings of the 2007 Symposium on Computer Human Interaction for the Management of Information Technology (2007).