{ "questions": [ { "id": "intent", "text": "What does the user set out to do on this screen?", "hint": "This means what a visit to the screen ends with.", "options": [ { "value": "view", "label": "Only look", "sub": "They look something up and leave again.", "example": "Checking the status of an order", "icon": "eye" }, { "value": "review", "label": "Review and decide", "sub": "They look first, then approve, reject or correct.", "example": "Approving an invoice", "icon": [ "eye", "badge_check" ] }, { "value": "edit", "label": "Edit", "sub": "They know beforehand what they want to change.", "example": "Changing a customer's address", "icon": "edit" }, { "value": "create", "label": "Create new", "sub": "They create something that does not exist yet.", "example": "Entering a new customer", "icon": "add_circle" } ] }, { "id": "viewWhat", "text": "What does the user look at?", "hint": "More than one is possible.", "multiple": true, "askIf": { "q": "intent", "is": "view" }, "options": [ { "value": "read", "label": "They read a record", "sub": "go through the details of a case" }, { "value": "find", "label": "They look for something specific", "sub": "a name, a number, a document — also to get there" }, { "value": "narrow", "label": "They narrow down a set", "sub": "pick the matching ones out of many" }, { "value": "compare", "label": "They put several things side by side", "sub": "find differences" }, { "value": "monitor", "label": "They keep an eye on a state", "sub": "runs, anomalies, open cases" }, { "value": "dates", "label": "They keep an eye on dates", "sub": "leave, deadlines, shifts — whatever hangs on a date" }, { "value": "analyze", "label": "They compile figures", "sub": "for the screen or to pass on" } ] }, { "id": "viewFocus", "text": "And which of these is the main thing?", "hint": "The main thing determines how the screen is built. The rest finds its place within it.", "focusOf": "viewWhat", "askIf": { "q": "viewWhat", "count": { "min": 2 } }, "options": [] }, { "id": "reviewWhat", "text": "What does the user review?", "askIf": { "q": "intent", "is": "review" }, "options": [ { "value": "record", "label": "One record, detail by detail", "sub": "a document, an application, a master record" }, { "value": "submissions", "label": "Submitted cases", "sub": "applications and documents someone decides on" }, { "value": "status", "label": "The state of many cases", "sub": "runs, open cases, anomalies" }, { "value": "sideBySide", "label": "Several things side by side", "sub": "two versions or several records, to find differences" } ] }, { "id": "reviewOutcome", "text": "What follows the review?", "askIf": { "q": "reviewWhat", "is": "submissions" }, "options": [ { "value": "decide", "label": "A decision", "sub": "approve or reject; the case stays as it is" }, { "value": "correct", "label": "A decision, with a correction before it", "sub": "the reviewer may correct values before approving" } ] }, { "id": "editWhat", "text": "What does the user change?", "hint": "More than one is possible.", "multiple": true, "askIf": { "q": "intent", "is": "edit" }, "options": [ { "value": "details", "label": "A record's details", "sub": "correct values, set a status" }, { "value": "assign", "label": "Links", "sub": "assign people, products or permissions" }, { "value": "settings", "label": "Settings", "sub": "values that then apply to everything" } ] }, { "id": "editFocus", "text": "And which of these is the main thing?", "hint": "The main thing determines how the screen is built. The rest finds its place within it.", "focusOf": "editWhat", "askIf": { "q": "editWhat", "count": { "min": 2 } }, "options": [] }, { "id": "readMode", "text": "How does the user go through the record?", "hint": "Overview means: look, make sense of it, carry on working. Item by item means: each item on its own, with a tick after it.", "askIf": { "q": "reviewWhat", "is": "record" }, "options": [ { "value": "overview", "label": "They get an overview", "sub": "look, make sense of it, carry on working" }, { "value": "itemByItem", "label": "They go through item by item", "sub": "each item on its own, with a tick after it" } ] }, { "id": "readDocument", "text": "Does the record come with a document that has to be visible meanwhile?", "hint": "The scanned voucher, the contract, the certificate — something the details come from or are checked against.", "askIf": { "any": [ { "main": "viewWhat", "is": "read" }, { "q": "reviewWhat", "is": "record" } ] }, "options": [ { "value": "yes", "label": "Yes, a document belongs to it", "sub": "values are read from it or checked against it" }, { "value": "no", "label": "No, only the details", "sub": "what there is to see is in the fields" } ] }, { "id": "editExtent", "text": "Does the user change a single detail or several together?", "hint": "Do the details depend on each other, so that one change brings the next with it? Or does each stand on its own?", "askIf": { "all": [ { "q": "reviewWhat", "is": "record" }, { "q": "readMode", "is": "overview" }, { "q": "readDocument", "is": "no" } ] }, "options": [ { "value": "single", "label": "Usually a single detail", "sub": "each stands on its own and applies at once" }, { "value": "several", "label": "Several together", "sub": "they depend on each other and are checked together" } ] }, { "id": "monitorScope", "text": "Does the user keep an eye on many cases or on one particular case?", "hint": "Many means: the state of operations. One means: “where is my application?”", "askIf": { "main": "viewWhat", "is": "monitor" }, "options": [ { "value": "many", "label": "The overall state", "sub": "runs, open cases, anomalies" }, { "value": "one", "label": "One particular case", "sub": "where it stands and what it is waiting for" } ] }, { "id": "monitorRealtime", "text": "Do changes have to be visible in real time or near real time?", "askIf": { "any": [ { "all": [ { "main": "viewWhat", "is": "monitor" }, { "q": "monitorScope", "is": "many" } ] }, { "q": "reviewWhat", "is": "status" } ] }, "options": [ { "value": "yes", "label": "Yes", "sub": "ongoing operations; the live state counts" }, { "value": "no", "label": "No", "sub": "periodic updates are enough" } ] }, { "id": "monitorDrilldown", "text": "Does the user need to be able to jump from the overview straight into individual records?", "askIf": { "all": [ { "main": "viewWhat", "is": "monitor" }, { "q": "monitorScope", "is": "many" } ] }, "options": [ { "value": "yes", "label": "Yes", "sub": "overview and detailed checking belong together" }, { "value": "no", "label": "No", "sub": "the overview itself is the result" } ] }, { "id": "findTarget", "text": "Does the user already know exactly what they are looking for?", "hint": "E.g. a specific name, an ID, a reference number.", "askIf": { "main": "viewWhat", "is": "find" }, "options": [ { "value": "known", "label": "The target is known precisely", "sub": "a targeted search for one hit" }, { "value": "exploring", "label": "Rather exploratory", "sub": "the target is vague and becomes clearer while browsing" } ] }, { "id": "findVolume", "text": "How large and how structured is the underlying data set?", "askIf": { "q": "findTarget", "is": "exploring" }, "options": [ { "value": "small", "label": "Manageable", "sub": "few criteria needed to narrow it down" }, { "value": "large", "label": "Large and many-layered", "sub": "many combinable criteria possible" } ] }, { "id": "browseStructure", "text": "Is the data set organized into categories the user knows?", "hint": "Clients, years, departments, document types — an order they think in anyway.", "askIf": { "q": "findVolume", "is": "small" }, "options": [ { "value": "yes", "label": "Yes, a familiar order", "sub": "the user knows which area to look in" }, { "value": "no", "label": "No, a flat data set", "sub": "no structure that helps with searching" } ] }, { "id": "filterCombine", "text": "Does the user have to combine several criteria at once?", "hint": "E.g. restricting status + period + person responsible at the same time.", "askIf": { "main": "viewWhat", "is": "narrow" }, "options": [ { "value": "yes", "label": "Yes", "sub": "narrowing along several dimensions is normal" }, { "value": "no", "label": "No", "sub": "a single search term is usually enough" } ] }, { "id": "filterRepeat", "text": "Is the same combination of filters used again and again?", "askIf": { "q": "filterCombine", "is": "yes" }, "options": [ { "value": "yes", "label": "Yes", "sub": "saved views would be valuable" }, { "value": "no", "label": "No", "sub": "filters are mostly set ad hoc" } ] }, { "id": "searchPlace", "text": "Where does the user search?", "hint": "Across the whole application means: they know the name but not the area. Search needs a page of its own only when searching is itself the work.", "askIf": { "any": [ { "q": "findTarget", "is": "known" }, { "q": "browseStructure", "is": "no" }, { "q": "filterCombine", "is": "no" } ] }, "options": [ { "value": "global", "label": "Across the whole application", "sub": "the name is known, the area is not" }, { "value": "local", "label": "In the data in front of them", "sub": "the list is there, and the search runs within it" }, { "value": "ownPage", "label": "Searching is the task itself", "sub": "many criteria, and the work continues with the hits" } ] }, { "id": "filterTiles", "text": "Does a single field divide the data set, and are its counts information in themselves?", "hint": "For example the state of a work queue: 12 open, 4 in review, 31 done. The counts are needed anyway.", "askIf": { "any": [ { "q": "findVolume", "is": "large" }, { "q": "filterRepeat", "is": "no" } ] }, "options": [ { "value": "yes", "label": "Yes, one field with telling counts", "sub": "otherwise the counts would appear somewhere else again" }, { "value": "no", "label": "No, there are several criteria", "sub": "the counts are not the information" } ] }, { "id": "filterCount", "text": "How many filters are available?", "askIf": { "q": "filterTiles", "is": "no" }, "options": [ { "value": "two", "label": "One or two, and they always apply", "sub": "e.g. the data set and its state" }, { "value": "few", "label": "Up to four, without groups", "sub": "manageable, all can be shown at once" }, { "value": "many", "label": "More than four, or in groups", "sub": "the filters themselves need an order" } ] }, { "id": "filterWidth", "text": "Does the table take the full width, or is there room left on the right?", "hint": "A drawer from the right makes the table narrower. With a wide table, that is the difference between readable and cut off.", "askIf": { "q": "filterCount", "is": "few" }, "options": [ { "value": "wide", "label": "A very wide table", "sub": "every column is needed" }, { "value": "normal", "label": "There is room left", "sub": "a panel from the right pushes nothing important aside" } ] }, { "id": "compareVersions", "text": "Are they two versions of the same record?", "hint": "Before and after, draft and final version, imported and existing.", "askIf": { "any": [ { "main": "viewWhat", "is": "compare" }, { "q": "reviewWhat", "is": "sideBySide" } ] }, "options": [ { "value": "yes", "label": "Yes, two versions", "sub": "the question is what has changed" }, { "value": "no", "label": "No, different records", "sub": "the question is which one is the right one" } ] }, { "id": "compareCount", "text": "How many records are typically compared at once?", "askIf": { "q": "compareVersions", "is": "no" }, "options": [ { "value": "two", "label": "Two", "sub": "a direct side-by-side" }, { "value": "few", "label": "Three to about five", "sub": "a small, fixed selection" }, { "value": "many", "label": "Many, or a variable number", "sub": "the selection changes with the situation" } ] }, { "id": "compareCriteria", "text": "Is the set of comparison criteria fixed and known, or does it differ from record to record?", "askIf": { "q": "compareVersions", "is": "no" }, "options": [ { "value": "fixed", "label": "Fixed and known", "sub": "the same fields for all entries" }, { "value": "variable", "label": "Differing / dynamic", "sub": "the structure varies from case to case" } ] }, { "id": "analyzeResult", "text": "What is the result of the analysis?", "askIf": { "main": "viewWhat", "is": "analyze" }, "options": [ { "value": "numbers", "label": "Figures on the screen", "sub": "the user looks at them and carries on working" }, { "value": "file", "label": "A file to pass on", "sub": "Excel, CSV, PDF for someone else" }, { "value": "report", "label": "A recurring report", "sub": "the same question, anew every month" } ] }, { "id": "approveSecond", "text": "Does the decision need a second person?", "hint": "Four-eyes principle: one person approves, someone else confirms.", "askIf": { "q": "reviewWhat", "is": "submissions" }, "options": [ { "value": "yes", "label": "Yes, two people", "sub": "the second approval is mandatory" }, { "value": "no", "label": "No, one is enough", "sub": "whoever decides, decides alone" } ] }, { "id": "approveVolume", "text": "How many items does the user typically have to approve or decide on?", "askIf": { "q": "approveSecond", "answered": true }, "options": [ { "value": "single", "label": "Individual cases, irregularly", "sub": "an exception, not a continuous workflow" }, { "value": "queue", "label": "An ongoing queue", "sub": "many entries, a recurring workflow" } ] }, { "id": "approveContext", "text": "Does the user need a lot of context for the decision, or is a quick look enough?", "hint": "Context = linked data, history, several sources of information.", "askIf": { "q": "approveSecond", "is": "no" }, "options": [ { "value": "much", "label": "A lot of context needed", "sub": "check history, linked data, justifications" }, { "value": "little", "label": "A quick look is enough", "sub": "the decision is clear at a glance" } ] }, { "id": "recordCount", "text": "How many records does the task actually concern?", "hint": "This is the most important switch between table, master-detail or bulk editing.", "askIf": { "main": "editWhat", "is": "details" }, "options": [ { "value": "single", "label": "One particular record", "sub": "the user knows which one" }, { "value": "sequential", "label": "Several, but one after another", "sub": "work through them in turn" }, { "value": "bulk", "label": "Many at once", "sub": "change them in one step" } ] }, { "id": "bulkUniform", "text": "Is the change identical for all affected records, or does the user have to decide individually per record?", "hint": "E.g. “set status to done” is identical – “correct each amount separately” is individual.", "askIf": { "q": "recordCount", "is": "bulk" }, "options": [ { "value": "uniform", "label": "Identical change for all", "sub": "e.g. set a status, assign a tag, export" }, { "value": "individual", "label": "Individual decision per record", "sub": "each entry needs its own check" } ] }, { "id": "queueMode", "text": "Should the cases be worked through in order, without returning to the list in between?", "hint": "That is the difference between “open list, work on case, back” and “case, next, case, next”.", "askIf": { "q": "bulkUniform", "is": "individual" }, "options": [ { "value": "yes", "label": "Yes, one after another", "sub": "the list is the backlog, not the workplace" }, { "value": "no", "label": "No, from the list", "sub": "the user picks the next case themselves" } ] }, { "id": "listRole", "text": "Is the list itself part of the actual task, or does it only serve to navigate to a record?", "hint": "Check the mental model: “I am working through THIS LIST” vs. “I am working on THIS record.”", "askIf": { "q": "recordCount", "in": [ "single", "sequential" ] }, "options": [ { "value": "workspace", "label": "The list is the workspace", "sub": "I work through it row by row" }, { "value": "navigation", "label": "The list only serves navigation", "sub": "select, then focus on one record" } ] }, { "id": "editScope", "text": "How big is the change to an individual record?", "hint": "A status, an amount, a checkbox — or the whole record with all its fields?", "askIf": { "q": "listRole", "is": "workspace" }, "options": [ { "value": "field", "label": "One or two fields", "sub": "set a status, correct an amount, flip a checkbox" }, { "value": "record", "label": "The whole record", "sub": "several sections; fields depend on each other" } ] }, { "id": "editPlace", "text": "Does the user see the neighboring rows while changing, or do they not need them?", "hint": "Neighboring rows help when the right value follows from the comparison — for instance with amounts in a series.", "askIf": { "q": "editScope", "is": "field" }, "options": [ { "value": "row", "label": "The neighboring rows count too", "sub": "the value follows from the comparison" }, { "value": "alone", "label": "The record stands on its own", "sub": "what is next to it does not matter" } ] }, { "id": "frequentSwitching", "text": "Does the user often have to switch between individual records while doing so?", "askIf": { "q": "editScope", "is": "record" }, "options": [ { "value": "yes", "label": "Yes", "sub": "jumping back and forth all the time is normal" }, { "value": "no", "label": "No", "sub": "mostly a linear pass or a single focus" } ] }, { "id": "listVisible", "text": "Does the list have to stay visible while editing?", "hint": "E.g. to keep an eye on progress, position or neighboring entries.", "askIf": { "q": "editScope", "is": "record" }, "options": [ { "value": "yes", "label": "Yes", "sub": "the list stays in view permanently" }, { "value": "no", "label": "No", "sub": "full focus on one record is enough" } ] }, { "id": "detailComplexity", "text": "How extensive is the detail view of a single record?", "askIf": { "any": [ { "q": "editScope", "is": "record" }, { "q": "listRole", "is": "navigation" } ] }, "options": [ { "value": "low", "label": "Little information", "sub": "a single, compact block" }, { "value": "medium", "label": "Medium complexity", "sub": "one or two content areas" }, { "value": "high", "label": "A lot of information", "sub": "several sub-areas or tabs, a working world of its own" } ] }, { "id": "listContext", "text": "Does the user still need the context of the list while doing so, or is the task completely self-contained?", "hint": "Context = position in the list, neighboring entries, active filter state.", "askIf": { "all": [ { "q": "listRole", "is": "navigation" }, { "q": "detailComplexity", "is": "low" } ] }, "options": [ { "value": "context", "label": "List context stays important", "sub": "e.g. quickly checking the next entry" }, { "value": "isolated", "label": "The task is isolated", "sub": "e.g. a confirmation, changing a single field" } ] }, { "id": "criticality", "text": "How critical is the action if it is carried out wrongly?", "askIf": { "q": "recordCount", "answered": true }, "options": [ { "value": "reversible", "label": "Can be undone", "sub": "the correction costs a click or checking back with someone" }, { "value": "critical", "label": "Critical / hardly reversible", "sub": "deleting, payment, final approval" } ] }, { "id": "assignVolume", "text": "How many assignments does the user make at once?", "askIf": { "main": "editWhat", "is": "assign" }, "options": [ { "value": "single", "label": "One", "sub": "one person responsible, one product, one role" }, { "value": "many", "label": "Several together", "sub": "select a set and assign it" } ] }, { "id": "assignKnown", "text": "Does the user know whom or what they want to assign?", "hint": "For example the name of the person responsible, the role, the product.", "askIf": { "q": "assignVolume", "is": "single" }, "options": [ { "value": "yes", "label": "Yes, they know the name", "sub": "they type it and choose from the hits" }, { "value": "no", "label": "No, they have to find it first", "sub": "they go through the data set before choosing" } ] }, { "id": "structureDepth", "text": "How deep is the structure?", "hint": "One level is clients or document types. Several are account class, account group, account.", "askIf": { "any": [ { "q": "browseStructure", "is": "yes" }, { "q": "assignKnown", "is": "no" } ] }, "options": [ { "value": "flat", "label": "One level", "sub": "a handful of areas side by side" }, { "value": "deep", "label": "Several levels", "sub": "groups within groups, three tiers or more" } ] }, { "id": "settingsScope", "text": "How many settings are there?", "askIf": { "main": "editWhat", "is": "settings" }, "options": [ { "value": "few", "label": "A handful", "sub": "on one screen, without structure" }, { "value": "many", "label": "Many, in sections", "sub": "several topics, each with its own values" } ] }, { "id": "createSource", "text": "Where does the data of the new record come from?", "askIf": { "q": "intent", "is": "create" }, "options": [ { "value": "manual", "label": "The user types it in", "sub": "by hand, field by field" }, { "value": "template", "label": "From an existing record", "sub": "a template or copy, adjusted afterwards" }, { "value": "file", "label": "From a file", "sub": "CSV, Excel, a delivery from outside" } ] }, { "id": "createSteps", "text": "How many steps or blocks of information does creating it involve?", "askIf": { "q": "createSource", "is": "manual" }, "options": [ { "value": "one", "label": "A single, short step", "sub": "few fields, done right away" }, { "value": "few", "label": "Several related steps", "sub": "logically grouped sections" }, { "value": "many", "label": "Many steps or branching logic", "sub": "depending on earlier input" } ] }, { "id": "createContext", "text": "Is the record created in the middle of a list the user has in front of them?", "hint": "Adding an item while the others stay visible.", "askIf": { "q": "createSteps", "is": "one" }, "options": [ { "value": "inline", "label": "Yes, in the list", "sub": "the new entry visibly belongs with the others" }, { "value": "own", "label": "No, on its own", "sub": "in the end the record stands alone" } ] }, { "id": "createResume", "text": "Does the user need to be able to interrupt creating it and continue later?", "askIf": { "q": "createSteps", "in": [ "few", "many" ] }, "options": [ { "value": "yes", "label": "Yes", "sub": "save a draft, continue later" }, { "value": "no", "label": "No", "sub": "the task is done in one go" } ] }, { "id": "formPlace", "text": "Does the user need anything from what is on the page while filling in the form?", "hint": "Looking things up, comparing, copying a value over — or do they have all the details in front of them anyway?", "askIf": { "q": "createContext", "is": "own" }, "options": [ { "value": "page", "label": "Yes, they look at the page while doing it", "sub": "look up, compare, copy over" }, { "value": "standalone", "label": "No, the details stand on their own", "sub": "what they need is in their head or on paper" } ] }, { "id": "createEditable", "text": "Can the new entry still be changed afterwards?", "askIf": { "q": "intent", "is": "create" }, "options": [ { "value": "yes", "label": "Yes, it stays editable", "sub": "a typo can be corrected later" }, { "value": "no", "label": "No, it is fixed", "sub": "what has been created stands as it is" } ] }, { "id": "createDeletable", "text": "Does it also have to be possible to delete the new entry again?", "hint": "Not: may it be corrected. But: can it disappear entirely if it was a mistake.", "askIf": { "q": "intent", "is": "create" }, "options": [ { "value": "yes", "label": "Yes, it can go again", "sub": "a mistake can be taken back" }, { "value": "no", "label": "No, it stays", "sub": "once created, it stays in the records" } ] } ], "results": [ { "when": { "main": "viewWhat", "is": "dates" }, "endpoint": "calendar-view", "confidence": "high", "confidenceNote": "Where the date is the order, the calendar is the form — a list sorted by date is something else.", "reasoning": "The entries hang on days and periods, and what counts are overlaps and gaps. Both can be seen in the grid and have to be worked out in a list.", "alternative": { "endpoint": "search-local", "condition": "if in practice people search by name after all and the date is just one column among many." }, "more": [ { "endpoint": "filter-drawer", "condition": "in addition, as soon as several kinds of entries sit in the same calendar — leave, sickness, training — and have to be switchable on and off individually." } ], "ai": { "endpoint": "ai-anomalies", "condition": "in addition, if overlaps and staff shortages can be quantified: the days when it gets tight should be highlighted, with the number beside them." } }, { "when": { "q": "monitorScope", "is": "one" }, "endpoint": "process-status", "confidence": "high", "confidenceNote": "A single case and its stages — that is a chain, not a list.", "reasoning": "The question is where the case stands and what it is waiting for. A list answers that for many cases and for none precisely; the chain names the time and the person for each stage and, at the open one, says whose turn it is.", "alternative": { "endpoint": "activity-feed", "condition": "if what counts is not the stages but every single change to the case." }, "more": [ { "endpoint": "read-view", "condition": "if the status is mostly about the case's details and the stages are only one line of it." } ] }, { "when": { "all": [ { "q": "readDocument", "is": "yes" }, { "q": "readMode", "is": "itemByItem" } ] }, "endpoint": "document-side", "confidence": "high", "confidenceNote": "Where the details come from a document, the document belongs beside them and not in a second window.", "reasoning": "Values are read from the document and entered or checked beside it. If the two are not side by side, the user carries values in their head across a window switch — that is where transposed digits come from. Since the review goes item by item, the review checklist belongs in the right column and the document stays on the left.", "alternative": { "endpoint": "review-checklist", "condition": "if it turns out that the document is rarely opened during the work — then a way to it is enough instead of half the width." }, "more": [ { "endpoint": "read-view-edit", "condition": "if the document also comes with corrections and the details are checked together." } ], "ai": { "endpoint": "ai-suggest-fill", "condition": "in addition, if the fields can be read from the document: the suggestion sits in the field, the place in the document beside it is highlighted, and it is accepted by hand." } }, { "when": { "q": "readDocument", "is": "yes" }, "endpoint": "document-side", "confidence": "high", "confidenceNote": "Where the details come from a document, the document belongs beside them and not in a second window.", "reasoning": "Values are read from the document and entered or checked beside it. If the two are not side by side, the user carries values in their head across a window switch — that is where transposed digits come from.", "alternative": { "endpoint": "read-view", "condition": "if it turns out that the document is rarely opened during the work — then a way to it is enough instead of half the width." }, "more": [ { "endpoint": "read-view-edit", "condition": "if the document also comes with corrections and the details are checked together." } ], "ai": { "endpoint": "ai-suggest-fill", "condition": "in addition, if the fields can be read from the document: the suggestion sits in the field, the place in the document beside it is highlighted, and it is accepted by hand." } }, { "when": { "q": "readMode", "is": "itemByItem" }, "endpoint": "review-checklist", "confidence": "high", "confidenceNote": "The set is gone through item by item, and the state of the review has to be readable along the way — that is what the review checklist is for.", "reasoning": "The user works through a fixed set of items and has to know which are still open. An ordinary list shows the content but not the state of the review. Ticking off is the change here; no separate edit mode is added.", "alternative": { "endpoint": "read-view", "condition": "if it turns out that in practice the items are skimmed rather than checked one by one." }, "more": [ { "endpoint": "edit-in-place", "condition": "if, besides the tick, each item also has a value to change." } ], "ai": { "endpoint": "ai-anomalies", "condition": "in addition, if the items can be compared — with the previous month, with the average. The conspicuous ones are at the top; the list stays complete." } }, { "when": { "q": "editExtent", "is": "single" }, "endpoint": "edit-in-place", "confidence": "high", "confidenceNote": "A detail that stands on its own and applies on its own needs no mode for the whole page.", "reasoning": "One detail at a time is changed, and it depends on no other. Switching the whole page into an edit mode for it means opening ten fields to fill one — and the rest of the page becomes unreadable for the duration.", "alternative": { "endpoint": "read-view-edit", "condition": "if it turns out that the details do have to be checked together after all, for instance because one determines the next." }, "more": [ { "endpoint": "read-view", "condition": "if changes are rare enough that a way to a separate editing page is enough." } ] }, { "when": { "q": "editExtent", "is": "several" }, "endpoint": "read-view-edit", "confidence": "high", "confidenceNote": "Details that are checked together and saved together belong in a mode for the whole page.", "reasoning": "The record is mostly read, but when it is changed, several things change at once. The details depend on each other, so they have to be valid together — no field can decide that on its own. A form for both cases makes the frequent case as heavy as the rare one.", "alternative": { "endpoint": "edit-in-place", "condition": "if it turns out that in practice almost always only a single detail is changed." }, "more": [ { "endpoint": "read-view", "condition": "if changing belongs somewhere else entirely and this screen is only for reading." } ] }, { "when": { "main": "viewWhat", "is": "read" }, "endpoint": "read-view", "confidence": "high", "confidenceNote": "Only reading, and not a single field on the screen — that is the read view.", "reasoning": "The user reads a record's details and changes nothing in them. A form with locked fields shows the same, but it promises an editing that does not exist, and costs a frame's worth of space per detail.", "alternative": { "endpoint": "read-view-edit", "condition": "if, while reading, a small thing does regularly need correcting after all." }, "more": [ { "endpoint": "review-checklist", "condition": "if reading turns into reviewing and someone needs to know where things stand." } ] }, { "when": { "all": [ { "q": "monitorRealtime", "is": "yes" }, { "q": "monitorDrilldown", "is": "no" } ] }, "endpoint": "activity-feed", "confidence": "medium", "confidenceNote": "Ongoing operations without intervention and without drill-down — what is asked for is the history, not the state.", "reasoning": "The user watches what happens, and does so as it happens. A dashboard answers “how do things stand”, but the question here is “what is happening right now”. The stream of events shows that directly, with person, action and time on each line.", "alternative": { "endpoint": "dashboard", "condition": "if it turns out that it is about key figures after all and nobody is interested in the individual case." } }, { "when": { "q": "monitorDrilldown", "is": "yes" }, "endpoint": "dashboard-drilldown", "confidence": "high", "confidenceNote": "Monitoring followed by detailed checking is a clear case for dashboard + drill-down.", "reasoning": [ "The user first needs a condensed overview, but has to be able to jump from there straight into individual records.", { "text": "Since real-time currency is required as well, the live status of the data should be communicated transparently.", "when": { "q": "monitorRealtime", "is": "yes" } } ], "alternative": { "endpoint": "dashboard", "condition": "if it turns out that the drill-down is hardly used in practice and the overview alone is enough." }, "ai": { "endpoint": "ai-anomalies", "condition": "in addition, if a key figure deviates from what is expected — then the drill-down leads there first." } }, { "when": { "q": "monitorDrilldown", "is": "no" }, "endpoint": "dashboard", "confidence": "high", "confidenceNote": "Pure monitoring with no need for drill-down is the classic dashboard case.", "reasoning": "The user primarily wants to keep an eye on the current state without jumping from there into individual records. A condensed dashboard with a clear visual hierarchy covers this need.", "alternative": { "endpoint": "dashboard-drilldown", "condition": "if the need to check individual cases from the overview does show up later." }, "ai": { "endpoint": "ai-anomalies", "condition": "in addition, if a key figure deviates from what is expected: the deviation belongs at the figure, with the comparison value it follows from." } }, { "when": { "q": "reviewWhat", "is": "status" }, "endpoint": "alert-worklist", "confidence": "high", "confidenceNote": "Work follows from the monitoring — then the state and the cases belong on the same screen.", "reasoning": [ "The user does not just watch, they intervene. A pure overview would send them somewhere else for every action. The state at the top, the conspicuous cases below it with their next action: that way seeing and doing are one movement.", { "text": "Since the live state counts, the list has to update without shifting the user's view.", "when": { "q": "monitorRealtime", "is": "yes" } } ], "alternative": { "endpoint": "dashboard-drilldown", "condition": "if it turns out that the cases are handled in another application anyway and only the overview is needed here." }, "ai": { "endpoint": "ai-anomalies", "condition": "in addition, if what is usual can be quantified. Then the order of the worklist is the anomaly, not the date received." } }, { "when": { "q": "searchPlace", "is": "ownPage" }, "endpoint": "search-page", "confidence": "high", "confidenceNote": "Where searching is itself the work, it gets a place, not a field.", "reasoning": "The user puts a search together: several criteria, linked with each other, and they carry on working with the hits. A field in the toolbar cannot carry that — there is room for one term there. A page of its own has room for the criteria, for their explanation and for what comes after the hit.", "alternative": { "endpoint": "filter-drawer", "condition": "if it turns out that the criteria always target the same data set — then it is a filter on a list and not a search of its own." }, "more": [ { "endpoint": "search-local", "condition": "if in practice a single term is almost always enough and the other criteria stay empty." } ], "ai": { "endpoint": "ai-ask", "condition": "in addition, if there are so many criteria that nobody knows them all. The question in one's own words becomes criteria that stand visibly above the hits and can be changed one by one." } }, { "when": { "q": "searchPlace", "is": "global" }, "endpoint": "search-global", "confidence": "high", "confidenceNote": "Whoever knows the name but not the area needs a search that goes across the areas.", "reasoning": "The target is known, its location is not. A search above the list does not help with that — it only finds what is in this one list. The search in the header reaches across all kinds and groups the hits by them, so that the area emerges from the result instead of having to be chosen beforehand.", "alternative": { "endpoint": "search-local", "condition": "if it turns out that users almost always know the area already." } }, { "when": { "q": "searchPlace", "is": "local" }, "endpoint": "search-local", "confidence": "high", "confidenceNote": "The search runs within what is on the screen — then the field belongs above this list.", "reasoning": "The data set is in front of the user, and they narrow it down to one hit. The search field in the toolbar makes the reference unambiguous: the search runs within what is below it. The hit count in the meta line says how much is left.", "alternative": { "endpoint": "search-global", "condition": "if users more often do not know which area their target is in." } }, { "when": { "q": "structureDepth", "is": "deep" }, "endpoint": "tree-browse", "confidence": "high", "confidenceNote": "A structure across several levels is shown by the tree; a grouped list can only show one.", "reasoning": "The user knows which area they are searching in, but the area itself lies within an area. A grouped list would have to fold the depth into the headings or leave out a level. The tree shows it and keeps collapsed what does not count right now.", "alternative": { "endpoint": "browse-categories", "condition": "if it turns out that users only ever use the top level — then the structure is flatter than thought." }, "more": [ { "endpoint": "search-local", "condition": "in addition, for those who know the name: a search above the tree leads to the hit and expands the path to it." } ], "ai": { "endpoint": "ai-ask", "condition": "in addition, if the tree is so deep that nobody knows which branch their entry is in — the question in one's own words leads there and expands the path." } }, { "when": { "all": [ { "q": "browseStructure", "is": "yes" }, { "q": "structureDepth", "is": "flat" } ] }, "endpoint": "browse-categories", "confidence": "high", "confidenceNote": "A vague target, a manageable data set and an order the user knows — for that, the structure is a better way in than the search field.", "reasoning": "The user does not know exactly what they are looking for, but they know where to look. A structure that matches their work lets them recognize instead of recall — and shows them in passing what there is at all.", "alternative": { "endpoint": "search-local", "condition": "if it turns out that users can mostly name the target after all and the structure is only a detour." } }, { "when": { "all": [ { "q": "assignKnown", "is": "no" }, { "q": "structureDepth", "is": "flat" } ] }, "endpoint": "browse-categories", "confidence": "medium", "confidenceNote": "Whoever does not know the name has to be able to look through the data set. A structure carries that; a search field does not.", "reasoning": "The user knows that they want to assign, but not what. So looking through comes before choosing. The structure of the data set is the way in for that; the search field stays beside it, for the cases where the name is known after all.", "alternative": { "endpoint": "picker-dialog", "condition": "if users know the data set after a familiarization period and then mostly type after all." } }, { "when": { "q": "filterTiles", "is": "yes" }, "endpoint": "filter-tiles", "confidence": "high", "confidenceNote": "One dimension with telling counts is more than a filter — the tiles are overview and filter at once.", "reasoning": "The data set divides along one field, and its counts are needed anyway. In a drawer this field would sit as a select, and the counts would have to appear somewhere else again. As tiles above the list, both are the same building block.", "alternative": { "endpoint": "filter-drawer", "condition": "as soon as a second dimension is added — the row of tiles no longer carries that." }, "more": [ { "endpoint": "filter-toolbar", "condition": "if nobody is interested in the counts after all and a select gives the same information more briefly." } ] }, { "when": { "q": "filterCount", "is": "two" }, "endpoint": "filter-toolbar", "confidence": "high", "confidenceNote": "One or two filters that always apply belong visibly in the toolbar and not behind a button.", "reasoning": "The filters are few and always in use. Behind a button they would be invisible, and the value set would have to be repeated as a badge beside it. Open in the toolbar, the select carries the value itself.", "alternative": { "endpoint": "filter-drawer", "condition": "as soon as a third filter is added or one is needed only occasionally." }, "more": [ { "endpoint": "filter-tiles", "condition": "if one of the two filters is a dimension with counts that are needed anyway." } ] }, { "when": { "q": "filterWidth", "is": "wide" }, "endpoint": "filter-panel", "confidence": "high", "confidenceNote": "A wide table and at most four filters — that is the case for which the panel is the exception to the drawer.", "reasoning": "Up to four filters without groups fit side by side under the toolbar. The second reason against the drawer is the table: a panel from the right makes it narrower, and with a wide table that decides whether the rear columns are still readable. The panel pushes the content down instead of aside.", "alternative": { "endpoint": "filter-drawer", "condition": "as soon as a fifth filter is added or the filters need groups." }, "more": [ { "endpoint": "filter-toolbar", "condition": "if two of the four filters almost always stay on the same value — those belong open in the bar." } ] }, { "when": { "q": "filterWidth", "is": "normal" }, "endpoint": "filter-drawer", "confidence": "high", "confidenceNote": "The drawer is the normal case for filters. Four filters are no reason to depart from it.", "reasoning": "The filters are manageable, but they are not needed all the time. Behind the filter button they take no space above the list, and what is set appears as a badge above it. The panel would be allowed but has no advantage here — the table has room.", "alternative": { "endpoint": "filter-panel", "condition": "if the filters are to stay open all the time and the table does not need the width." }, "more": [ { "endpoint": "filter-toolbar", "condition": "if it turns out that in practice only two of the four filters are used." } ], "ai": { "endpoint": "ai-ask", "condition": "in addition, if the filters are in groups and hard to find. What the question yields appears as badges above the list — the same ones that are set by hand." } }, { "when": { "q": "filterCount", "is": "many" }, "endpoint": "filter-drawer", "confidence": "high", "confidenceNote": "More than four filters, or filters in groups, only the drawer can carry.", "reasoning": "The filters themselves need an order: groups, headings, a sequence. There is no room for that above the toolbar, and a panel of that height would push the list off the screen. The drawer has the height and can group.", "alternative": { "endpoint": "saved-views", "condition": "if the same combinations recur — then the named view is the way in and the drawer is only the way to build a new one." }, "more": [ { "endpoint": "filter-tiles", "condition": "in addition, if one of the dimensions divides the data set and its counts are needed — the tiles then sit above the list, and the drawer stays beside it." } ], "ai": { "endpoint": "ai-ask", "condition": "in addition, if the filters are in groups and hard to find. What the question yields appears as badges above the list — the same ones that are set by hand." } }, { "when": { "q": "filterRepeat", "is": "yes" }, "endpoint": "saved-views", "confidence": "high", "confidenceNote": "Setting the same criteria by hand again and again is the work that saved views take off the user's hands.", "reasoning": "The user combines several criteria, and does so repeatedly with the same ones. The filter panel is still needed, but it is no longer the way in: the way in is the named view, and the panel is the way to build a new one.", "alternative": { "endpoint": "filter-drawer", "condition": "if it turns out that the combinations are different every time after all and none is needed a second time." }, "ai": { "endpoint": "ai-ask", "condition": "in addition, to build a new view: the question as a sentence, the result as criteria, which are then named and saved." } }, { "when": { "q": "compareVersions", "is": "yes" }, "endpoint": "diff-view", "confidence": "high", "confidenceNote": "Two versions of the same record ask a different question than two records — what is sought is the difference.", "reasoning": "What is compared is not two things but two points in time of one thing. A comparison table would put both versions side by side as equals; but the question is what has changed. That should be marked, not searched for.", "alternative": { "endpoint": "compare-table", "condition": "if more than two versions regularly have to be checked side by side." } }, { "when": { "all": [ { "q": "compareCount", "in": [ "two", "few" ] }, { "q": "compareCriteria", "is": "fixed" } ] }, "endpoint": "compare-table", "confidence": "high", "confidenceNote": "A small, fixed number with fixed criteria is the classic case for a comparison table.", "reasoning": "A small, manageable number of records is compared using the same, known criteria. A side-by-side comparison table makes differences recognizable at a glance.", "alternative": { "endpoint": "compare-select", "condition": "if the number of entries to compare varies more in future." } }, { "when": { "q": "compareCriteria", "is": "variable" }, "endpoint": "compare-select", "confidence": "high", "confidenceNote": "Variable criteria and/or a variable number clearly speak for a flexible mode of selecting and comparing.", "reasoning": "The number of records to compare varies, or the comparison criteria differ from case to case. A rigid side-by-side table would quickly become confusing here. Instead, the user selects specifically from a table and opens a flexible comparison mode from it.", "alternative": { "endpoint": "compare-table", "condition": "if practice shows that almost always the same small number is compared using the same criteria." } }, { "when": { "q": "compareCriteria", "is": "fixed" }, "endpoint": "compare-select", "confidence": "medium", "confidenceNote": "Fixed criteria but a larger/variable number of entries speak for a dedicated comparison mode instead of a rigid table.", "reasoning": "The number of records to compare varies, or the comparison criteria differ from case to case. A rigid side-by-side table would quickly become confusing here. Instead, the user selects specifically from a table and opens a flexible comparison mode from it.", "alternative": { "endpoint": "compare-table", "condition": "if practice shows that almost always the same small number is compared using the same criteria." } }, { "when": { "q": "analyzeResult", "is": "file" }, "endpoint": "export-dialog", "confidence": "high", "confidenceNote": "A file for someone else — what matters is that scope and format are settled before the export.", "reasoning": "The result leaves the application. That makes the question of scope the most important one: what exactly is in it, how many records there are, and what stays out. Whoever only sees that in the file has already passed the error on.", "alternative": { "endpoint": "report-builder", "condition": "if the same output is needed regularly — then it is a report and not an export." } }, { "when": { "q": "analyzeResult", "is": "report" }, "endpoint": "report-builder", "confidence": "high", "confidenceNote": "The same question anew in every period — that is a saved report and not a one-off compilation.", "reasoning": "The report recurs, so it pays to record its setup: period, breakdown, key figures. The value lies not in compiling it but in two periods being comparable because they were set up the same way.", "alternative": { "endpoint": "dashboard", "condition": "if the figures are meant to be in view permanently anyway rather than compiled periodically." }, "ai": { "endpoint": "ai-ask", "condition": "in addition, if a report's setup is easier to say than to click. What comes out of it has to be visible as a setup that can be saved." } }, { "when": { "q": "analyzeResult", "is": "numbers" }, "endpoint": "dashboard", "confidence": "high", "confidenceNote": "Figures that are meant to stay in view belong on an overview and not in a file.", "reasoning": "The result of the analysis stays in the application. The user looks, makes sense of it and carries on working. An overview with a few named key figures carries that; each figure needs its period and its comparison value.", "alternative": { "endpoint": "dashboard-drilldown", "condition": "if the figures regularly lead to the question about the individual case." }, "ai": { "endpoint": "ai-anomalies", "condition": "in addition, if a key figure deviates from what is expected: the deviation belongs at the figure, with the comparison value it follows from." } }, { "when": { "all": [ { "q": "reviewOutcome", "is": "correct" }, { "q": "approveSecond", "is": "yes" } ] }, "endpoint": "approve-with-edit", "confidence": "high", "confidenceNote": "Approving and changing by the same person is a flow of its own, not an approval with one more button.", "reasoning": "The reviewer does not only decide, they also correct. That makes the correction part of the decision: it has to be recorded on the case, with the old value beside it and with a name. An ordinary approval knows only two outcomes and would have no room for the third.", "alternative": { "endpoint": "dual-approval", "condition": "if creating and reviewing have to stay separate — then only approving or rejecting remains." }, "more": [ { "endpoint": "approval-queue", "condition": "if corrections are rare and the effort for logging and marking is not worth it." } ], "ai": { "endpoint": "ai-anomalies", "condition": "in addition, if it can be said what a deviation is to be judged by. What the reviewer then corrects remains their decision." }, "absorbs": "details" }, { "when": { "all": [ { "q": "reviewOutcome", "is": "correct" }, { "q": "approveVolume", "is": "queue" }, { "q": "approveContext", "is": "much" } ] }, "endpoint": "approve-with-edit", "confidence": "high", "confidenceNote": "Approving and changing by the same person is a flow of its own, not an approval with one more button.", "reasoning": "The reviewer does not only decide, they also correct. That makes the correction part of the decision: it has to be recorded on the case, with the old value beside it and with a name. An ordinary approval knows only two outcomes and would have no room for the third.", "alternative": { "endpoint": "approval-queue", "condition": "if creating and reviewing have to stay separate — then only approving or rejecting remains." }, "more": [ { "endpoint": "approval-queue", "condition": "if corrections are rare and the effort for logging and marking is not worth it." } ], "ai": { "endpoint": "ai-anomalies", "condition": "in addition, if it can be said what a deviation is to be judged by. What the reviewer then corrects remains their decision." }, "absorbs": "details" }, { "when": { "all": [ { "q": "reviewOutcome", "is": "correct" }, { "q": "approveVolume", "is": "queue" }, { "q": "approveContext", "is": "little" } ] }, "endpoint": "approve-with-edit", "confidence": "high", "confidenceNote": "Approving and changing by the same person is a flow of its own, not an approval with one more button.", "reasoning": "The reviewer does not only decide, they also correct. That makes the correction part of the decision: it has to be recorded on the case, with the old value beside it and with a name. An ordinary approval knows only two outcomes and would have no room for the third.", "alternative": { "endpoint": "approval-inline", "condition": "if creating and reviewing have to stay separate — then only approving or rejecting remains." }, "more": [ { "endpoint": "approval-queue", "condition": "if corrections are rare and the effort for logging and marking is not worth it." } ], "ai": { "endpoint": "ai-anomalies", "condition": "in addition, if it can be said what a deviation is to be judged by. What the reviewer then corrects remains their decision." }, "absorbs": "details" }, { "when": { "all": [ { "q": "reviewOutcome", "is": "correct" }, { "q": "approveVolume", "is": "single" }, { "q": "approveContext", "is": "much" } ] }, "endpoint": "approve-with-edit", "confidence": "high", "confidenceNote": "Approving and changing by the same person is a flow of its own, not an approval with one more button.", "reasoning": "The reviewer does not only decide, they also correct. That makes the correction part of the decision: it has to be recorded on the case, with the old value beside it and with a name. An ordinary approval knows only two outcomes and would have no room for the third.", "alternative": { "endpoint": "approval-detail", "condition": "if creating and reviewing have to stay separate — then only approving or rejecting remains." }, "more": [ { "endpoint": "approval-queue", "condition": "if corrections are rare and the effort for logging and marking is not worth it." } ], "ai": { "endpoint": "ai-anomalies", "condition": "in addition, if it can be said what a deviation is to be judged by. What the reviewer then corrects remains their decision." }, "absorbs": "details" }, { "when": { "all": [ { "q": "reviewOutcome", "is": "correct" }, { "q": "approveVolume", "is": "single" }, { "q": "approveContext", "is": "little" } ] }, "endpoint": "approve-with-edit", "confidence": "high", "confidenceNote": "Approving and changing by the same person is a flow of its own, not an approval with one more button.", "reasoning": "The reviewer does not only decide, they also correct. That makes the correction part of the decision: it has to be recorded on the case, with the old value beside it and with a name. An ordinary approval knows only two outcomes and would have no room for the third.", "alternative": { "endpoint": "modal", "condition": "if creating and reviewing have to stay separate — then only approving or rejecting remains." }, "more": [ { "endpoint": "approval-queue", "condition": "if corrections are rare and the effort for logging and marking is not worth it." } ], "ai": { "endpoint": "ai-anomalies", "condition": "in addition, if it can be said what a deviation is to be judged by. What the reviewer then corrects remains their decision." }, "absorbs": "details" }, { "when": { "all": [ { "q": "approveSecond", "is": "yes" }, { "q": "approveVolume", "is": "queue" } ] }, "endpoint": "dual-approval", "confidence": "high", "confidenceNote": "Two mandatory approvals are a flow of their own and not a variant of the simple approval.", "reasoning": "The decision needs two people. The state in between — approved but not yet confirmed — has to be a visible state, not a silent one. Deputies and deadlines belong to it, otherwise the case stalls as soon as someone is absent. With an ongoing queue, the second approval is itself a work queue again.", "alternative": { "endpoint": "approval-queue", "condition": "if the second approval can be dropped on business grounds after all and a spot check afterwards is enough." } }, { "when": { "q": "approveSecond", "is": "yes" }, "endpoint": "dual-approval", "confidence": "high", "confidenceNote": "Two mandatory approvals are a flow of their own and not a variant of the simple approval.", "reasoning": "The decision needs two people. The state in between — approved but not yet confirmed — has to be a visible state, not a silent one. Deputies and deadlines belong to it, otherwise the case stalls as soon as someone is absent.", "alternative": { "endpoint": "approval-detail", "condition": "if the second approval can be dropped on business grounds after all and a spot check afterwards is enough." } }, { "when": { "all": [ { "q": "approveVolume", "is": "queue" }, { "q": "approveContext", "is": "much" } ] }, "endpoint": "approval-queue", "confidence": "high", "confidenceNote": "An ongoing queue with a high need for context is the classic master-detail approval case.", "reasoning": "This is a recurring workflow with many cases to decide, each of which needs sufficient context. A master-detail queue allows efficient processing without loss of context between decisions.", "alternative": { "endpoint": "approval-inline", "condition": "if it turns out that most cases can in fact be decided with a quick look." }, "ai": { "endpoint": "ai-anomalies", "condition": "in addition, if the cases can be checked against an expectation. The reasoning has to be verifiable by calculation — “82 % above the previous month”, not “conspicuous”." } }, { "when": { "all": [ { "q": "approveVolume", "is": "queue" }, { "q": "approveContext", "is": "little" } ] }, "endpoint": "approval-inline", "confidence": "high", "confidenceNote": "Many simple cases with little checking effort speak for inline and bulk approval.", "reasoning": "Many cases come up, but each can be decided with a quick look. An inline action directly in the table row, combined with multiple selection for identical serial cases, is clearly more efficient here than a full detail view per case.", "alternative": { "endpoint": "approval-queue", "condition": "if individual cases turn out to be more complex after all and need more context for the decision." } }, { "when": { "all": [ { "q": "approveVolume", "is": "single" }, { "q": "approveContext", "is": "much" } ] }, "endpoint": "approval-detail", "confidence": "high", "confidenceNote": "Rare but context-rich individual cases fit well on a detail page of their own.", "reasoning": "Approvals occur only irregularly but need a lot of context for a well-founded decision. A detail page of its own offers enough room to bring all relevant information together.", "alternative": { "endpoint": "approval-queue", "condition": "if the irregular individual cases do turn into a regular workflow with several cases." } }, { "when": { "all": [ { "q": "approveVolume", "is": "single" }, { "q": "approveContext", "is": "little" } ] }, "endpoint": "modal", "confidence": "high", "confidenceNote": "Rare, simple individual decisions are a classic modal case.", "reasoning": "Approvals are rare and can be decided with a quick look. A focused confirmation dialog covers this need without an unnecessary page change.", "alternative": { "endpoint": "drawer", "condition": "if the user does want to look at the surrounding list again while doing so." } }, { "when": { "all": [ { "q": "bulkUniform", "is": "uniform" }, { "q": "criticality", "is": "critical" } ] }, "endpoint": "bulk-edit", "confidence": "medium", "confidenceNote": "Bulk editing fits in substance, but with critical, hardly reversible actions the confirmation should be designed with particular care.", "reasoning": "The user changes many records at once with the same change. A table with multiple selection and bulk actions saves a great deal of time in this case compared with editing each entry individually.", "alternative": { "endpoint": "bulk-individual", "condition": "if a closer look does show that individual records need different treatment." } }, { "when": { "q": "bulkUniform", "is": "uniform" }, "endpoint": "bulk-edit", "confidence": "high", "confidenceNote": "The task clearly fits identical changes to many records.", "reasoning": "The user changes many records at once with the same change. A table with multiple selection and bulk actions saves a great deal of time in this case compared with editing each entry individually.", "alternative": { "endpoint": "bulk-individual", "condition": "if a closer look does show that individual records need different treatment." } }, { "when": { "all": [ { "q": "queueMode", "is": "yes" }, { "q": "criticality", "is": "critical" } ] }, "endpoint": "record-queue", "confidence": "medium", "confidenceNote": "The queue fits, but with hardly reversible decisions every step needs a confirmation — and that costs exactly the speed the queue exists for.", "reasoning": "Each case needs a decision of its own, but the order is not worth the user deciding it themselves each time. The queue takes the searching off their hands and gives the individual case the full width.", "alternative": { "endpoint": "bulk-individual", "condition": "if the user has to be able to pick the cases themselves, for instance because they do the easy ones first." }, "ai": { "endpoint": "ai-anomalies", "condition": "in addition, if the cases can be ordered by how conspicuous they are. The order of the queue is then a statement and not a random sequence." } }, { "when": { "q": "queueMode", "is": "yes" }, "endpoint": "record-queue", "confidence": "high", "confidenceNote": "Many cases, each to be decided individually, in a fixed order — that is what the work queue is built for.", "reasoning": "Each case needs a decision of its own, but the order is not worth the user deciding it themselves each time. The queue takes the searching off their hands and gives the individual case the full width.", "alternative": { "endpoint": "bulk-individual", "condition": "if the user has to be able to pick the cases themselves, for instance because they do the easy ones first." }, "ai": { "endpoint": "ai-anomalies", "condition": "in addition, if the cases can be ordered by how conspicuous they are. The order of the queue is then a statement and not a random sequence." } }, { "when": { "q": "queueMode", "is": "no" }, "endpoint": "bulk-individual", "confidence": "high", "confidenceNote": "Since every record has to be checked individually, a sequential approach is preferable to the bulk action.", "reasoning": "Even though the task concerns many records, each entry needs a decision of its own. Real bulk editing would lead to ill-considered or faulty mass changes here. A master-detail layout allows quick but individual processing.", "alternative": { "endpoint": "bulk-edit", "condition": "if it turns out that most of the cases can be treated identically after all – then process those beforehand with a bulk action and check only the exceptions individually." } }, { "when": { "all": [ { "q": "editPlace", "is": "row" }, { "q": "criticality", "is": "critical" } ] }, "endpoint": "inline-edit", "confidence": "medium", "confidenceNote": "Inline editing fits the task, but with hardly reversible changes the cell has to show what already applies — and an undo has to stand beside it.", "reasoning": "The change covers one or two fields, and the right value follows from comparing with the neighbors. A detail area would hide exactly this comparison and introduce an open-close cycle for every correction.", "alternative": { "endpoint": "master-detail", "condition": "if it turns out that the two fields regularly come with notes, attachments or dependent values as well." }, "ai": { "endpoint": "ai-suggest-fill", "condition": "in addition, if the right value follows from the series. The suggestion sits in the cell, visibly as a suggestion, and Enter accepts it." } }, { "when": { "q": "editPlace", "is": "row" }, "endpoint": "inline-edit", "confidence": "high", "confidenceNote": "Short changes to a work list where the neighboring rows count too — the classic case for changing in the row.", "reasoning": "The change covers one or two fields, and the right value follows from comparing with the neighbors. A detail area would hide exactly this comparison and introduce an open-close cycle for every correction.", "alternative": { "endpoint": "master-detail", "condition": "if it turns out that the two fields regularly come with notes, attachments or dependent values as well." }, "ai": { "endpoint": "ai-suggest-fill", "condition": "in addition, if the right value follows from the series. The suggestion sits in the cell, visibly as a suggestion, and Enter accepts it." } }, { "when": { "q": "editPlace", "is": "alone" }, "endpoint": "inline-edit", "confidence": "medium", "confidenceNote": "The short change speaks for changing in the row, but the missing relation to the neighbors also speaks for a drawer — both are defensible.", "reasoning": "One or two fields are changed, and for that the row is the shortest way. That the record stands on its own does, however, take away inline editing's second argument: the comparison with the neighboring rows plays no part here.", "alternative": { "endpoint": "drawer", "condition": "if the fields come with an explanation, a check or a second look at the record." }, "ai": { "endpoint": "ai-suggest-fill", "condition": "in addition, if the right value follows from the series. The suggestion sits in the cell, visibly as a suggestion, and Enter accepts it." } }, { "when": { "all": [ { "q": "editScope", "is": "record" }, { "any": [ { "q": "frequentSwitching", "is": "yes" }, { "q": "listVisible", "is": "yes" } ] }, { "not": { "q": "detailComplexity", "is": "high" } } ] }, "endpoint": "master-detail", "confidence": "high", "confidenceNote": "List as workspace, frequent switching or a need for visibility, manageable detail complexity – a clear master-detail case.", "reasoning": "The list is part of the actual workflow: the user switches frequently between records or needs the list visible while editing. That keeps the context, and switches between records are reduced.", "alternative": { "endpoint": "table-detail", "condition": "if a single record is going to be edited much longer and more intensively in future than today." } }, { "when": { "all": [ { "q": "editScope", "is": "record" }, { "any": [ { "q": "frequentSwitching", "is": "yes" }, { "q": "listVisible", "is": "yes" } ] } ] }, "endpoint": "master-detail", "confidence": "medium", "confidenceNote": "Strong signals for master-detail (switching/visibility), but the high detail complexity speaks rather for a page of its own. Both are defensible here.", "reasoning": "The workflow demands frequent switching between records or a visible list while editing – that speaks clearly for master-detail. At the same time, the detail view is very extensive, which would rather speak for a detail page of its own at full width. In practice, master-detail is recommended, with a clearly structured, possibly scrollable detail area and progressive disclosure for less important sections.", "alternative": { "endpoint": "table-detail", "condition": "if editing a single record typically takes very long (minutes to hours) and needs a sub-navigation of its own with several tabs." } }, { "when": { "all": [ { "q": "editScope", "is": "record" }, { "q": "detailComplexity", "is": "high" } ] }, "endpoint": "table-detail", "confidence": "high", "confidenceNote": "Without frequent switching or a need for visibility, master-detail loses its main advantage – a detail page is usually the clearer choice here.", "reasoning": "Even though the list was first classed as the workspace, neither frequent switching nor the need to keep the list visible speaks for master-detail. In this case a detail page of its own offers more room and clarity for the actual editing.", "alternative": { "endpoint": "master-detail", "condition": "if the workflow changes and the user does have to jump back and forth between several records regularly." } }, { "when": { "q": "editScope", "is": "record" }, "endpoint": "table-detail", "confidence": "medium", "confidenceNote": "Without frequent switching or a need for visibility, master-detail loses its main advantage – a detail page is usually the clearer choice here.", "reasoning": "Even though the list was first classed as the workspace, neither frequent switching nor the need to keep the list visible speaks for master-detail. In this case a detail page of its own offers more room and clarity for the actual editing.", "alternative": { "endpoint": "master-detail", "condition": "if the workflow changes and the user does have to jump back and forth between several records regularly." } }, { "when": { "q": "listContext", "is": "isolated" }, "endpoint": "modal", "confidence": "high", "confidenceNote": "A short, self-contained task with no relation to the list – a classic modal case.", "reasoning": "The list only serves navigation, the detail information is slight, and the task is completely isolated from the list. A modal allows full concentration on exactly this one action, without an unnecessary page change.", "alternative": { "endpoint": "drawer", "condition": "if the user does want to glance at the list again without leaving the dialog." } }, { "when": { "q": "listContext", "is": "context" }, "endpoint": "drawer", "confidence": "high", "confidenceNote": "Little detail content, but the list context stays relevant – a classic drawer case.", "reasoning": "The detail information is compact, but the user still needs the context of the list (e.g. to jump to the next entry). A drawer keeps the list visible in the background without forcing a full page change.", "alternative": { "endpoint": "modal", "condition": "if it turns out that the list context is in fact never needed during the task." } }, { "when": { "all": [ { "q": "listRole", "is": "navigation" }, { "q": "detailComplexity", "is": "high" } ] }, "endpoint": "table-detail", "confidence": "high", "confidenceNote": "The detail view is extensive enough to clearly justify a page of its own.", "reasoning": "The list primarily serves navigation to a record, and the detail information is extensive enough to justify a page of its own. That matches the mental model “I am working on THIS record” – not “I am working through the list”.", "alternative": { "endpoint": "master-detail", "condition": "if it turns out that, despite the complexity, the user switches between records very frequently and the list should stay visible." } }, { "when": { "q": "listRole", "is": "navigation" }, "endpoint": "table-detail", "confidence": "medium", "confidenceNote": "Medium complexity – a drawer would also be conceivable if loading times/clicks have to be kept to a strict minimum.", "reasoning": "The list primarily serves navigation to a record, and the detail information is extensive enough to justify a page of its own. That matches the mental model “I am working on THIS record” – not “I am working through the list”.", "alternative": { "endpoint": "drawer", "condition": "if the click paths have to be shorter and the list context should stay visible while editing." } }, { "when": { "q": "assignVolume", "is": "many" }, "endpoint": "transfer-list", "confidence": "high", "confidenceNote": "Several assignments at once require both sides to stay visible.", "reasoning": "The user does not assign one value but puts a set together. The state is the actual information here: what is already assigned, what is still available. A selection field only ever shows one half.", "alternative": { "endpoint": "picker-dialog", "condition": "if it turns out that mostly only one or two entries are assigned at a time after all." } }, { "when": { "q": "assignKnown", "is": "yes" }, "endpoint": "picker-dialog", "confidence": "high", "confidenceNote": "An assignment whose target the user can name — typing and choosing is the shortest way.", "reasoning": "It is about one value, and the user knows it by name. A search with hits below it gets them to the target in two moves, regardless of how large the data set behind it is. Additional details per hit separate entries with the same name.", "alternative": { "endpoint": "transfer-list", "condition": "if the one assignment regularly turns into several." }, "ai": { "endpoint": "ai-suggest-fill", "condition": "in addition, if the assignment can be derived from comparable cases — the three most likely at the top, with the reason beside them." } }, { "when": { "q": "settingsScope", "is": "many" }, "endpoint": "settings-sections", "confidence": "high", "confidenceNote": "Many values across several topics — the structure is the real achievement here.", "reasoning": "Settings grow, and they are rarely used. Both speak for sections: the whole stays manageable, and every setting has a place you can name to someone. That includes a sentence per value on what it does and when it applies.", "alternative": { "endpoint": "form-inline", "condition": "if it turns out that the sections each contain only two or three values." } }, { "when": { "q": "settingsScope", "is": "few" }, "endpoint": "form-inline", "confidence": "high", "confidenceNote": "Settings stand on their page. A dialog for values that apply permanently would be the wrong frame.", "reasoning": "The values fit on one screen, and afterwards they apply to everything. A dialog turns that into an action you complete and forget again — a page turns it into a place you find again and can name to someone.", "alternative": { "endpoint": "settings-sections", "condition": "if the number of settings grows — from about one screen's worth on, the structure is due." }, "ai": { "endpoint": "ai-suggest-fill", "condition": "in addition, if fields can be prefilled from the context. The suggestion names its origin and is accepted, not set." } }, { "when": { "q": "createSource", "is": "file" }, "endpoint": "import-wizard", "confidence": "high", "confidenceNote": "Data from an outside file needs mapping and a preview before it is in the records.", "reasoning": "The record is not typed but taken over. That shifts the task from filling in to checking: mapping columns, finding faulty rows, confirming the scope. Whatever slips through here is then in the records.", "alternative": { "endpoint": "wizard", "condition": "if the file is always structured the same way — then an upload with a result report is enough instead of the mapping." }, "ai": { "endpoint": "ai-suggest-fill", "condition": "in addition, if the files are structured differently each time: the column mapping can be suggested instead of being set anew each time. The suggestion only applies once someone accepts it." }, "recovery": [ { "text": "A mistake can be put right: the entry can be changed and deleted again. Creating may therefore stay lightweight — the safeguard lies behind the action, not before it.", "when": { "all": [ { "q": "createDeletable", "is": "yes" }, { "q": "createEditable", "is": "yes" } ] } }, { "text": "A wrongly created entry can be deleted but not corrected. Whoever mistypes creates it anew. Deleting therefore has to be reachable without a detour, and the message after creating should show the way there.", "when": { "all": [ { "q": "createDeletable", "is": "yes" }, { "q": "createEditable", "is": "no" } ] } }, { "text": "The entry stays once it is there. Correcting is possible, taking it back is not. So a summary of what is about to be created belongs before creating — and the required details are checked beforehand, not afterwards.", "when": { "all": [ { "q": "createDeletable", "is": "no" }, { "q": "createEditable", "is": "yes" } ] } }, { "text": "Once created, the entry stays unchanged in the records. That makes creating the critical action of this screen. Check the required details, show a summary, and only then create.", "when": { "all": [ { "q": "createDeletable", "is": "no" }, { "q": "createEditable", "is": "no" } ] } } ] }, { "when": { "q": "createSource", "is": "template" }, "endpoint": "duplicate-template", "confidence": "high", "confidenceNote": "A new record made from an existing one is not an empty form but a check of the values taken over.", "reasoning": "Most of the details are already there because they come from the template. The real work is finding the deviations and not taking over what must not be taken over. An empty form would throw this advantage away.", "alternative": { "endpoint": "form-inline", "condition": "if it turns out that in practice almost every field gets changed anyway." }, "ai": { "endpoint": "ai-suggest-fill", "condition": "in addition, if the existing records show which values get taken over and which do not — suggested, marked, and confirmed by hand." }, "recovery": [ { "text": "A mistake can be put right: the entry can be changed and deleted again. Creating may therefore stay lightweight — the safeguard lies behind the action, not before it.", "when": { "all": [ { "q": "createDeletable", "is": "yes" }, { "q": "createEditable", "is": "yes" } ] } }, { "text": "A wrongly created entry can be deleted but not corrected. Whoever mistypes creates it anew. Deleting therefore has to be reachable without a detour, and the message after creating should show the way there.", "when": { "all": [ { "q": "createDeletable", "is": "yes" }, { "q": "createEditable", "is": "no" } ] } }, { "text": "The entry stays once it is there. Correcting is possible, taking it back is not. So a summary of what is about to be created belongs before creating — and the required details are checked beforehand, not afterwards.", "when": { "all": [ { "q": "createDeletable", "is": "no" }, { "q": "createEditable", "is": "yes" } ] } }, { "text": "Once created, the entry stays unchanged in the records. That makes creating the critical action of this screen. Check the required details, show a summary, and only then create.", "when": { "all": [ { "q": "createDeletable", "is": "no" }, { "q": "createEditable", "is": "no" } ] } } ] }, { "when": { "all": [ { "q": "createContext", "is": "inline" }, { "q": "createDeletable", "is": "no" } ] }, "endpoint": "quick-add", "confidence": "medium", "confidenceNote": "The row in the list suits the short entry, but it makes creating casual — and what is created here stays. The two together are defensible, but call for a confirmation the pattern otherwise does not need.", "reasoning": "The record is created in the middle of a list the user has in front of them anyway. A dialog would separate them from exactly the context the new entry stands in, and demand a round of opening and closing for every further entry.", "alternative": { "endpoint": "form-modal", "condition": "if the entry comes with more fields or rules than a row can carry." }, "ai": { "endpoint": "ai-suggest-fill", "condition": "in addition, if the row can be prefilled from the context — wage type from the previous month, amount from the series. Recognizable as a suggestion, not as a value." }, "recovery": [ { "text": "The entry stays once it is there. Correcting is possible, taking it back is not. So a summary of what is about to be created belongs before creating — and the required details are checked beforehand, not afterwards.", "when": { "q": "createEditable", "is": "yes" } }, { "text": "Once created, the entry stays unchanged in the records. That makes creating the critical action of this screen. Check the required details, show a summary, and only then create.", "when": { "q": "createEditable", "is": "no" } } ] }, { "when": { "q": "createContext", "is": "inline" }, "endpoint": "quick-add", "confidence": "high", "confidenceNote": "Few fields, and the new entry visibly belongs with the others — that is what the row in the list is for.", "reasoning": "The record is created in the middle of a list the user has in front of them anyway. A dialog would separate them from exactly the context the new entry stands in, and demand a round of opening and closing for every further entry.", "alternative": { "endpoint": "form-modal", "condition": "if the entry comes with more fields or rules than a row can carry." }, "ai": { "endpoint": "ai-suggest-fill", "condition": "in addition, if the row can be prefilled from the context — wage type from the previous month, amount from the series. Recognizable as a suggestion, not as a value." }, "recovery": [ { "text": "A mistake can be put right: the entry can be changed and deleted again. Creating may therefore stay lightweight — the safeguard lies behind the action, not before it.", "when": { "q": "createEditable", "is": "yes" } }, { "text": "A wrongly created entry can be deleted but not corrected. Whoever mistypes creates it anew. Deleting therefore has to be reachable without a detour, and the message after creating should show the way there.", "when": { "q": "createEditable", "is": "no" } } ] }, { "when": { "q": "formPlace", "is": "standalone" }, "endpoint": "form-modal", "confidence": "high", "confidenceNote": "A short input with no relation to the page behind it is the case the dialog is built for.", "reasoning": "The user needs nothing from what is on the page while filling in the form. So the page behind is no help but a distraction. The dialog sets the task apart and makes its completion unambiguous — as long as the content fits on one screen.", "alternative": { "endpoint": "form-inline", "condition": "as soon as the content grows or it turns out that things do get looked up while filling in." }, "ai": { "endpoint": "ai-suggest-fill", "condition": "in addition, if fields can be prefilled from the context. The suggestion names its origin and is accepted, not set." }, "recovery": [ { "text": "A mistake can be put right: the entry can be changed and deleted again. Creating may therefore stay lightweight — the safeguard lies behind the action, not before it.", "when": { "all": [ { "q": "createDeletable", "is": "yes" }, { "q": "createEditable", "is": "yes" } ] } }, { "text": "A wrongly created entry can be deleted but not corrected. Whoever mistypes creates it anew. Deleting therefore has to be reachable without a detour, and the message after creating should show the way there.", "when": { "all": [ { "q": "createDeletable", "is": "yes" }, { "q": "createEditable", "is": "no" } ] } }, { "text": "The entry stays once it is there. Correcting is possible, taking it back is not. So a summary of what is about to be created belongs before creating — and the required details are checked beforehand, not afterwards.", "when": { "all": [ { "q": "createDeletable", "is": "no" }, { "q": "createEditable", "is": "yes" } ] } }, { "text": "Once created, the entry stays unchanged in the records. That makes creating the critical action of this screen. Check the required details, show a summary, and only then create.", "when": { "all": [ { "q": "createDeletable", "is": "no" }, { "q": "createEditable", "is": "no" } ] } } ] }, { "when": { "q": "formPlace", "is": "page" }, "endpoint": "form-inline", "confidence": "high", "confidenceNote": "When the user looks things up while filling in a form, what they look up must not be covered.", "reasoning": "During input the user needs what is on the page — they compare, copy over or check against it. A dialog lies right on top of it. On the page both stay visible, and there is room there for hints and validation messages too.", "alternative": { "endpoint": "form-modal", "condition": "if it turns out that the page behind is never needed while filling in after all." }, "ai": { "endpoint": "ai-suggest-fill", "condition": "in addition, if fields can be prefilled from the context. The suggestion names its origin and is accepted, not set." }, "recovery": [ { "text": "A mistake can be put right: the entry can be changed and deleted again. Creating may therefore stay lightweight — the safeguard lies behind the action, not before it.", "when": { "all": [ { "q": "createDeletable", "is": "yes" }, { "q": "createEditable", "is": "yes" } ] } }, { "text": "A wrongly created entry can be deleted but not corrected. Whoever mistypes creates it anew. Deleting therefore has to be reachable without a detour, and the message after creating should show the way there.", "when": { "all": [ { "q": "createDeletable", "is": "yes" }, { "q": "createEditable", "is": "no" } ] } }, { "text": "The entry stays once it is there. Correcting is possible, taking it back is not. So a summary of what is about to be created belongs before creating — and the required details are checked beforehand, not afterwards.", "when": { "all": [ { "q": "createDeletable", "is": "no" }, { "q": "createEditable", "is": "yes" } ] } }, { "text": "Once created, the entry stays unchanged in the records. That makes creating the critical action of this screen. Check the required details, show a summary, and only then create.", "when": { "all": [ { "q": "createDeletable", "is": "no" }, { "q": "createEditable", "is": "no" } ] } } ] }, { "when": { "q": "createResume", "is": "yes" }, "endpoint": "wizard", "confidence": "high", "confidenceNote": "Several steps combined with the need to interrupt creation clearly speak for a wizard with intermediate saving.", "reasoning": "Creation involves several related or mutually dependent steps. A wizard reduces the cognitive load per step and makes the overall progress transparent. Since it has to be possible to interrupt the task, automatic saving of the draft is essential.", "alternative": { "endpoint": "form-inline", "condition": "if in practice the steps can be combined so tightly that they fit on a single, clearly structured page." }, "recovery": [ { "text": "A mistake can be put right: the entry can be changed and deleted again. Creating may therefore stay lightweight — the safeguard lies behind the action, not before it.", "when": { "all": [ { "q": "createDeletable", "is": "yes" }, { "q": "createEditable", "is": "yes" } ] } }, { "text": "A wrongly created entry can be deleted but not corrected. Whoever mistypes creates it anew. Deleting therefore has to be reachable without a detour, and the message after creating should show the way there.", "when": { "all": [ { "q": "createDeletable", "is": "yes" }, { "q": "createEditable", "is": "no" } ] } }, { "text": "The entry stays once it is there. Correcting is possible, taking it back is not. So a summary of what is about to be created belongs before creating — and the required details are checked beforehand, not afterwards.", "when": { "all": [ { "q": "createDeletable", "is": "no" }, { "q": "createEditable", "is": "yes" } ] } }, { "text": "Once created, the entry stays unchanged in the records. That makes creating the critical action of this screen. Check the required details, show a summary, and only then create.", "when": { "all": [ { "q": "createDeletable", "is": "no" }, { "q": "createEditable", "is": "no" } ] } } ] }, { "when": { "q": "createResume", "is": "no" }, "endpoint": "wizard", "confidence": "medium", "confidenceNote": "Several steps speak for a wizard; without a need to interrupt, a longer single form would also be conceivable for really few, closely related fields.", "reasoning": "Creation involves several related or mutually dependent steps. A wizard reduces the cognitive load per step and makes the overall progress transparent.", "alternative": { "endpoint": "form-inline", "condition": "if in practice the steps can be combined so tightly that they fit on a single, clearly structured page." }, "recovery": [ { "text": "A mistake can be put right: the entry can be changed and deleted again. Creating may therefore stay lightweight — the safeguard lies behind the action, not before it.", "when": { "all": [ { "q": "createDeletable", "is": "yes" }, { "q": "createEditable", "is": "yes" } ] } }, { "text": "A wrongly created entry can be deleted but not corrected. Whoever mistypes creates it anew. Deleting therefore has to be reachable without a detour, and the message after creating should show the way there.", "when": { "all": [ { "q": "createDeletable", "is": "yes" }, { "q": "createEditable", "is": "no" } ] } }, { "text": "The entry stays once it is there. Correcting is possible, taking it back is not. So a summary of what is about to be created belongs before creating — and the required details are checked beforehand, not afterwards.", "when": { "all": [ { "q": "createDeletable", "is": "no" }, { "q": "createEditable", "is": "yes" } ] } }, { "text": "Once created, the entry stays unchanged in the records. That makes creating the critical action of this screen. Check the required details, show a summary, and only then create.", "when": { "all": [ { "q": "createDeletable", "is": "no" }, { "q": "createEditable", "is": "no" } ] } } ] } ], "addOns": [ { "when": { "all": [ { "q": "viewWhat", "has": "read" }, { "not": { "main": "viewWhat", "is": "read" } }, { "not": { "q": "monitorScope", "is": "one" } } ] }, "endpoint": "read-view", "condition": "Reading happens too: the individual record needs a view in which its details stand as text." }, { "when": { "all": [ { "q": "viewWhat", "has": "find" }, { "not": { "main": "viewWhat", "is": "find" } }, { "not": { "main": "viewWhat", "is": "dates" } }, { "not": { "q": "searchPlace", "answered": true } } ] }, "endpoint": "search-local", "condition": "Searching happens too: the field belongs in the toolbar above the list, so that the reference is unambiguous." }, { "when": { "all": [ { "q": "viewWhat", "has": "narrow" }, { "not": { "main": "viewWhat", "is": "narrow" } }, { "not": { "main": "viewWhat", "is": "dates" } }, { "not": { "q": "filterTiles", "answered": true } }, { "not": { "q": "searchPlace", "is": "ownPage" } } ] }, "endpoint": "filter-drawer", "condition": "Narrowing down happens too: the filters belong behind the filter button, and what is set appears as a badge above the list." }, { "when": { "all": [ { "q": "viewWhat", "has": "compare" }, { "not": { "main": "viewWhat", "is": "compare" } } ] }, "endpoint": "compare-select", "condition": "Comparing happens too: for that the list needs a selection and a comparison mode of its own." }, { "when": { "all": [ { "q": "viewWhat", "has": "monitor" }, { "not": { "main": "viewWhat", "is": "monitor" } } ] }, "endpoint": "alert-worklist", "condition": "Keeping an eye on things happens too: the state belongs above the list, with the conspicuous cases below it." }, { "when": { "all": [ { "q": "viewWhat", "has": "analyze" }, { "not": { "main": "viewWhat", "is": "analyze" } } ] }, "endpoint": "export-dialog", "condition": "Analyzing happens too: scope and format have to be settled before the export, not only in the file." }, { "when": { "all": [ { "q": "editWhat", "has": "details" }, { "not": { "main": "editWhat", "is": "details" } } ] }, "endpoint": "inline-edit", "condition": "Changing happens too: for one or two short fields the row is the shortest way." }, { "when": { "all": [ { "q": "editWhat", "has": "assign" }, { "not": { "main": "editWhat", "is": "assign" } } ] }, "endpoint": "picker-dialog", "condition": "Assigning happens too: a search with hits is enough for that, as long as the name is known." }, { "when": { "all": [ { "q": "editWhat", "has": "settings" }, { "not": { "main": "editWhat", "is": "settings" } } ] }, "endpoint": "settings-sections", "condition": "Configuring happens too: values that then apply to everything belong on a page of their own and not on this screen." } ], "endpoints": { "master-detail": { "title": "Master detail", "description": "List and detail area are visible at the same time. The list stays the work surface while the details appear beside it.", "principles": [ "Flexibility and efficiency of use", "Recognition rather than recall", "User control and freedom", "Progressive Disclosure" ], "pros": [ "No loss of context when switching between entries", "Fast, keyboard-friendly navigation from entry to entry", "Progress within the list stays visible at all times" ], "cons": [ "Less room for very extensive detail content", "The layout quickly gets tight with a complex detail view", "Requires careful behavior on responsive/mobile" ], "whenNot": "When editing a single record takes very long, needs a lot of space, or requires its own sub-navigation with several tabs.", "designTips": [ "Do not make the master area unnecessarily wide – it serves orientation, not detail work", "Make the selection state of the active entry unmistakably visible", "Allow navigation to the next/previous record by keyboard", "Make the detail area scrollable independently", "Take URL/browser navigation into account so that entries stay linkable", "For longer details, use progressive disclosure within the detail area" ], "next": { "click": "“Save document” on the right", "text": "The document stays selected, the row on the left takes over the new state, and focus stays in the detail. Anyone editing several documents one after another needs the way to the next one from here – as a button and by keyboard – without having to search on the left. If this becomes a series, it is sequential editing with progress.", "target": "bulk-individual", "image": "“Next document” below the fields leads to the following entry of the list, without having to look for it on the left." }, "patterns": [ "SC03", "SC04", "L07" ], "reviewed": false }, "table-detail": { "title": "Table and detail page", "description": "The table serves as an overview and entry point. For the actual work, the user switches to a dedicated, full detail page.", "principles": [ "Recognition rather than recall", "Aesthetic and minimalist design", "Progressive Disclosure", "Doherty Threshold" ], "pros": [ "Enough room for extensive content, tabs and sub-areas", "A clear, separate URL per record – easy to share and bookmark", "Scales well when a record represents its own world of work" ], "cons": [ "The context switch between list and detail costs clicks and loading time", "Jumping quickly through several entries is more cumbersome than with master-detail", "Returning to the list has to preserve the previous state (filters, scroll)" ], "whenNot": "When the list itself is the actual work surface and the user constantly switches between many entries – then master-detail is the better fit.", "designTips": [ "Returning to the list must preserve filter, sort and scroll state", "With several sub-areas, use clear tab or section navigation", "Most important information at the top, load details progressively (progressive disclosure)", "Offer a breadcrumb or clear back navigation to the originating list", "With frequent use, consider keyboard shortcuts for “next/previous record”" ], "next": { "click": "“Edit master data” on the page", "text": "The page switches to edit mode: the same details, as fields, in the same place. Saving leads back to the page's read view and not to the list – the list only comes with “Back to overview”, and the row shows the new state there.", "target": "read-view-edit", "image": "On the client's page, “Edit master data” swaps the details for fields; Save and Cancel lead back to the text." }, "patterns": [ "SC01", "SC02", "L07" ], "reviewed": false }, "drawer": { "title": "Detail drawer", "description": "A panel sliding in from the side shows details or focused editing while the list context is preserved in the background.", "principles": [ "User control and freedom", "Recognition rather than recall", "Aesthetic and minimalist design" ], "pros": [ "The list context (filters, position, neighboring entries) stays visible", "No full page change needed – feels lightweight", "Well suited to short, focused tasks related to the list" ], "cons": [ "Limited room for very extensive content", "Feels overloaded when used too often for complex forms", "Nested drawers (drawer in drawer) should be avoided" ], "whenNot": "Do not use for extensive forms or detail views with many sub-areas – use table + detail page instead.", "designTips": [ "The drawer should keep the list context visible in the background and dim it, but not cover it", "Allow closing with the Escape key and by clicking outside (user control and freedom)", "With several fields, use clear visual grouping instead of one long list", "Do not open a second level of drawers – switch to the detail page instead" ], "next": { "click": "“Save changes” in the footer", "text": "The drawer closes, the row shows the new state and stays highlighted. If the content outgrows the panel, there belongs a way at the top to the record's own page – not a second drawer and not a drawer that scrolls.", "target": "table-detail", "image": "At the top of the drawer is “Open on its own page” – the way out when the panel gets too narrow." }, "patterns": [], "components": [ "ed-drawer" ], "reviewed": false }, "modal": { "title": "Modal dialog", "description": "A focused dialog above the interface for a short, self-contained task unrelated to the list context.", "principles": [ "Aesthetic and minimalist design", "Error Prevention", "User control and freedom" ], "pros": [ "Forces full attention onto a single, clearly delimited task", "Well suited to confirmations and very short inputs", "No context switch in the real sense – the background remains reachable" ], "cons": [ "Unsuitable as soon as the content grows or needs several areas", "Nested modals (modal over modal) confuse and should be avoided", "No relation to the list context – unsuitable for context-sensitive tasks" ], "whenNot": "Do not use as the default solution for complex forms or extensive detail views. As soon as the content grows, switch to a drawer or detail page.", "designTips": [ "Limit to one single, clearly named action per modal", "For critical/irreversible actions, name the consequence explicitly, not just “Are you sure?”", "Allow closing with Escape and via a visible Cancel button", "Do not open nested modals" ], "next": { "click": "The accent button in the footer", "text": "The dialog closes, the row carries the new state, and a line above the list names the action – with “Undo” as long as that is still possible in business terms. A confirmation that leads nowhere leaves the user guessing whether it took effect.", "image": "After “Release payroll run”, a line above the list says what happened – without Undo, because the release completes the run." }, "patterns": [], "components": [ "ed-dialog" ], "reviewed": false }, "bulk-edit": { "title": "Bulk actions", "description": "The user selects several rows in the table and applies one identical action to all selected records at once.", "principles": [ "Flexibility and efficiency of use", "Tesler's Law", "Error Prevention", "User control and freedom" ], "pros": [ "Saves a great deal of time for identical, recurring changes", "Considerably reduces clicking effort with large amounts of data", "Scales well with power-user workflows" ], "cons": [ "Higher risk of error from an accidental multiple selection", "Unsuitable when each record needs an individual decision", "Undo/reversal has to work cleanly for the whole action" ], "whenNot": "When each record has to be checked individually and treated differently – then sequential processing (master-detail) instead of bulk editing.", "designTips": [ "Clearly summarize the selected count and the affected action before execution", "For critical actions, show an explicit confirmation with the number of affected records", "Offer an undo option after execution where technically feasible", "Support selection by keyboard (shift-click, select all)", "Show the bulk action bar only once something is actually selected" ], "next": { "click": "“Set document type” in the dialog", "text": "The dialog closes, the rows show the new value, the selection stays in place – the user often wants to apply the next action to the same rows right away. Above the table it says how many were affected, with “Undo” for all at once.", "image": "After the dialog, above the table it says what was set for how many, and “Undo” beside it." }, "patterns": [ "BE02" ], "reviewed": false }, "bulk-individual": { "title": "Serial edit", "description": "Since each record needs an individual decision, pure bulk editing is unsuitable. Instead, the records are worked through one after another in a master-detail layout.", "principles": [ "Recognition rather than recall", "User control and freedom", "Flexibility and efficiency of use" ], "pros": [ "Each record gets the individual attention it needs", "The list stays visible, progress is recognizable at any time", "Quick switch to the next entry without loss of context" ], "cons": [ "Slower than real bulk editing with very large amounts", "Requires a clear progress indicator, otherwise orientation is lost" ], "whenNot": "When it turns out that many records can be treated identically after all – then real bulk editing with multiple selection.", "designTips": [ "Make progress visible (e.g. “14 of 40 checked”)", "Offer a keyboard shortcut for “next record”", "Visually mark already processed entries in the list", "Allow jumping back to an already processed entry (user control and freedom)" ], "next": { "click": "“Save document and continue”", "text": "The next document is on the right, the status above advances with it. After the last one there is no empty step, but the summary: how many processed, how many skipped, and the way back to the list – with the skipped ones at the top." }, "patterns": [ "BE03", "BE04" ], "reviewed": false }, "dashboard": { "title": "Dashboard", "description": "A condensed overview of key figures and states, optimized for quickly grasping the current overall picture.", "principles": [ "Gestalt Principles", "Aesthetic and minimalist design", "Doherty Threshold" ], "pros": [ "Quick overall overview without having to navigate", "Well suited to recurring monitoring of a running state", "Anomalies and outliers become quickly recognizable through visual hierarchy" ], "cons": [ "Unsuitable for in-depth editing of individual records", "Loses clarity when too many metrics are shown at the same time" ], "whenNot": "When the actual task is editing individual records – a dashboard does not replace a working view.", "designTips": [ "Clearly prioritize the most important key figure visually, do not weight everything equally", "Communicate the refresh interval or live status transparently", "Link directly from conspicuous values to the matching detail or list view", "Use Gestalt principles (grouping, proximity) to cluster related key figures" ], "patterns": [ "SC05" ], "reviewed": false }, "dashboard-drilldown": { "title": "Dashboard with drill-down", "description": "An overview as an entry point from which the user can jump specifically into individual records or filtered lists.", "principles": [ "Gestalt Principles", "Progressive Disclosure", "Recognition rather than recall" ], "pros": [ "Combines a quick overview with targeted access to details", "Reduces the need to operate overview and detail search separately" ], "cons": [ "Requires careful navigation so the return to the dashboard is not lost", "Too many drill-down levels make orientation harder" ], "whenNot": "When there is no need to jump from the overview into details – then a pure dashboard is enough.", "designTips": [ "Clear visual signals showing which key figures are clickable", "On drill-down, carry the filter context from the dashboard over into the target view", "Returning to the dashboard should preserve the previous state" ], "patterns": [ "SC05", "SC02" ], "reviewed": false }, "compare-table": { "title": "Side-by-side comparison", "description": "A small, fixed number of records is shown side by side with the same attributes.", "principles": [ "Gestalt Principles", "Recognition rather than recall", "Aesthetic and minimalist design" ], "pros": [ "Direct, column-wise comparison makes differences easier to spot", "Fixed criteria give a clear, predictable structure" ], "cons": [ "Scales poorly with many or very differently structured records", "With too many attributes, horizontal scrolling becomes unavoidable" ], "whenNot": "When the number of records to compare varies strongly or the criteria differ from case to case – then a flexible selection with a comparison mode is the better fit.", "designTips": [ "Highlight differences between the columns visually (Gestalt: similarity/contrast)", "Keep the header row visible while scrolling", "Use the criteria in the same order and with the same labels across all columns" ], "next": { "click": "Choose a column", "text": "The comparison ends with a decision: one health insurer is adopted – where the comparison began, at the employee. A comparison without this button is a piece of information, and the user carries the result by hand somewhere else.", "image": "Below the table is “Adopt Barmer” – the decision the comparison has led to." }, "patterns": [ "TD04" ], "reviewed": false }, "compare-select": { "title": "Comparison mode", "description": "The user selects a variable number of records from a table and opens a dedicated comparison mode from them.", "principles": [ "Flexibility and efficiency of use", "User control and freedom", "Progressive Disclosure" ], "pros": [ "Flexible with a changing number and composition of the entries to compare", "The comparison stays optional, without burdening the normal table view" ], "cons": [ "An additional step (select → open comparison view) is needed", "With very different record structures, the display becomes more complex" ], "whenNot": "When always the same small, fixed number of elements is compared – then a simple comparison table without a separate selection step is enough.", "designTips": [ "Clearly distinguish the selection for the comparison from the normal row selection", "With differing structures, show missing values clearly as “not available” instead of empty", "Let the user leave the comparison mode at any time without losing the selection" ], "next": { "click": "“Add to comparison”", "text": "The comparison mode opens with the selected health insurers as columns. It ends with a choice, and the choice leads back to the list, in which the chosen insurer is marked – the selection for the comparison is cleared afterwards.", "target": "compare-table" }, "patterns": [ "TD04" ], "reviewed": false }, "wizard": { "title": "Wizard", "description": "The creation is divided into clearly delimited, consecutive steps that the user goes through one after another.", "principles": [ "Progressive Disclosure", "Hick's Law", "Error Prevention", "User control and freedom" ], "pros": [ "Reduces cognitive load, since only the relevant fields are visible per step", "Well suited to branching logic where later steps depend on earlier ones", "Progress and remaining effort become transparent" ], "cons": [ "Slower for experienced users who could enter all the information at once", "Too many steps for an actually simple task feel bureaucratic" ], "whenNot": "When the creation is only a single, short step with few fields – then a simple form or a modal is enough.", "designTips": [ "Show a progress indicator with clearly named steps, not just dots", "Allow jumping back to previous steps at any time (user control and freedom)", "Save inputs automatically as a draft in case an interruption is possible", "Validate per step, not only at the end (error prevention)" ], "patterns": [ "F02", "F05" ], "reviewed": false }, "approval-queue": { "title": "Approval queue", "description": "A running stream of approval cases is shown as a list, while the detail area shows the context needed for each decision.", "principles": [ "Flexibility and efficiency of use", "Recognition rather than recall", "Error Prevention" ], "pros": [ "Efficient processing of many cases without loss of context between decisions", "Enough room to show history and linked data for the decision" ], "cons": [ "Unsuitable when approvals occur only rarely and without a recurring workflow", "Requires clear marking of cases already decided" ], "whenNot": "When approvals occur only irregularly, one at a time – then a modal or a detail page per case is enough.", "designTips": [ "After each decision, jump automatically to the next open case", "Clearly distinguish cases already decided from open ones", "For critical decisions, require a short confirmation with a reason field", "Offer an undo option for accidental approvals, where technically possible" ], "next": { "click": "“Approve” on the right", "text": "The case leaves the list, the next one is on the right, the counter advances. Rejecting requires a reason in the dialog. “Ask a question” leaves the case in the list, with a mark – it is not decided, just no longer due. If the list is empty, the page says so." }, "patterns": [ "SC03", "SC04" ], "reviewed": false }, "approval-inline": { "title": "Inline approval", "description": "Approvals with low review effort are handled directly in the table row by an action, complemented by multiple selection for serial cases.", "principles": [ "Flexibility and efficiency of use", "Tesler's Law", "Error Prevention" ], "pros": [ "Very fast processing of large amounts of simple approval cases", "Combinable with multiple selection for identical serial decisions" ], "cons": [ "Unsuitable as soon as individual cases need more context for the decision", "Increased risk of wrong decisions without sufficient review" ], "whenNot": "As soon as individual cases need more context for the decision than a table row can show – then a master-detail queue.", "designTips": [ "Before executing critical approvals, show a short confirmation with the number of affected cases", "Make the most important decision information visible directly in the row, not just the name", "Offer an undo option for accidental approvals" ], "next": { "click": "“Reject” in the row", "text": "Approving needs no second step – the row disappears. Rejecting needs one: the reason goes to the person, so a small dialog opens, and only its button takes the row out of the list.", "image": "“Reject” opens the dialog with the reason; “Approve” takes effect immediately." }, "patterns": [ "TD03" ], "reviewed": false }, "approval-detail": { "title": "Approval detail page", "description": "Individual, irregular approval cases with a high need for context are decided on a dedicated detail page.", "principles": [ "Recognition rather than recall", "Progressive Disclosure", "Error Prevention" ], "pros": [ "Enough room for extensive decision context", "Fits rare but substantively demanding individual cases" ], "cons": [ "Not efficient when many cases suddenly arise at once – then a queue is the better fit" ], "whenNot": "As soon as this becomes a regular, recurring workflow with many cases – then a master-detail queue.", "designTips": [ "Bring all relevant information sources together on the detail page, so they do not have to be linked", "Clearly separate decision and reason from the pure information block", "After the decision, make transparent what happens next" ], "next": { "click": "“Release” on the page", "text": "The page returns to the list, and above the list it says what was decided. The row carries the new state or is gone, depending on what the list shows. Rejecting requires a reason beforehand – in the dialog, not in a field one overlooks.", "image": "“Release” leads back to the list; above it is the decision." }, "patterns": [ "SC01", "SC02" ], "reviewed": false }, "inline-edit": { "title": "Inline editing", "description": "The value is changed where it stands. The row stays in the list, the neighboring rows stay visible, nothing opens.", "principles": [ "Flexibility and efficiency of use", "Recognition rather than recall", "Doherty Threshold", "Fitts's Law" ], "pros": [ "No opening and closing per record – the shortest way from seeing to changing", "The comparison with the neighboring rows is preserved during input", "Many small corrections in a row cost hardly more than reading" ], "cons": [ "Only for a few, short fields – as soon as several sections belong to it, the row becomes unreadable", "Faulty input needs a place for the message, which a row hardly has", "Without a visible save state, the user does not know what already applies" ], "whenNot": "When the whole record is edited or fields depend on each other. Then the editing belongs in a detail area with room for groups and rules.", "designTips": [ "Show the save state per cell – saved, in progress, failed", "Guide through the cells with Tab and Enter, as in a spreadsheet", "Leave a failed input in the cell, do not discard it", "Offer undo as long as the row is in view", "Visibly distinguish non-editable columns from editable ones" ], "complements": true, "next": { "click": "Enter in the cell", "text": "The value is written, the cell is text again. Below the table it says what was last written, with the way back. If saving fails, the cell stays open and carries the error itself – nobody leaves the row because of an error.", "image": "The line below the table names what was last written and carries “Undo change”." }, "patterns": [ "TD01", "L06" ], "reviewed": false }, "record-queue": { "title": "Work queue", "description": "The cases come one after another. The user decides, the next one moves up, the list stays in the background and is not navigated to.", "principles": [ "Flexibility and efficiency of use", "Aesthetic and minimalist design", "Doherty Threshold", "Tesler's Law" ], "pros": [ "No searching for the next case – the order is decided", "Full width for the single case, without the list taking up space", "Progress is countable and the end is foreseeable" ], "cons": [ "The user cannot jump ahead and take the easy cases first", "A skipped case has to reappear somewhere, otherwise it gets lost", "With few cases, the setup is heavier than the task" ], "whenNot": "When the user picks the cases themselves or their order does not matter in business terms. Then the list with a detail area is enough.", "designTips": [ "Count what is still to come – “Case 7 of 34”, not just “next”", "Allow going back, at least one step", "Offer skipping and show the skipped ones again at the end", "Keep the exit visible at all times, with the progress in it", "After the last case, say what is done – do not release the user into the empty list" ], "complements": true, "next": { "click": "“Save and continue”", "text": "The next case comes by itself. Whoever cannot decide a case sets it aside, and it comes back at the end of the supply. When the supply is empty, the page says so and leads to the list – instead of showing an empty form.", "image": "“Set aside” next to the Continue: for the case one cannot decide right now." }, "patterns": [ "ST01" ], "reviewed": false }, "quick-add": { "title": "Quick add row", "description": "The new entry arises in its place. At the end of the list is an empty row, the user fills it, and it becomes the first real one.", "principles": [ "Recognition rather than recall", "Flexibility and efficiency of use", "Aesthetic and minimalist design" ], "pros": [ "The context stays visible – the new entry stands next to those it belongs with", "No opening, no closing, no finding the way back to the spot", "Creating several entries in a row is a flow, not a repetition run" ], "cons": [ "Only for a few fields – anything more than a row holds belongs elsewhere", "Required fields and dependencies are hard to explain in one row", "A half-filled entry is a state the list has to bear" ], "whenNot": "When the record has more than a handful of fields or its creation has consequences that need explaining. Then a form of its own.", "designTips": [ "After triggering, focus is in the first field", "Enter creates and opens the next empty row", "Escape discards the row begun, without asking when the fields are empty", "Briefly highlight the new entry after creating it, so it can be found again", "Do not let it jump away when sorting, as long as it should stay in view" ], "complements": true, "patterns": [ "TD01" ], "reviewed": false }, "duplicate-template": { "title": "Create from template", "description": "The new record begins as a copy of an existing one. The user picks the template, checks the adopted values and changes what differs.", "principles": [ "Recognition rather than recall", "Flexibility and efficiency of use", "Error Prevention" ], "pros": [ "Most of the fields are already right – only the difference is typed", "The template carries the knowledge of what a proper record looks like", "Recurring cases become a routine instead of a chore" ], "cons": [ "Adopted values are easily overlooked and carried along unchecked", "Numbers, dates and references must not be copied along and have to be set individually", "An outdated template passes its error on to every successor" ], "whenNot": "When every record looks different or the fields would only happen to be the same. Then the copy pretends a kinship that does not exist.", "designTips": [ "Show where it was copied from, and throughout, not only at the moment of choosing", "Mark the adopted fields as long as they are unchanged", "Never adopt number, date and status. Leave them empty and say why", "Make the choice of template searchable, not only a list of the most recent", "After creating, do not claim a connection to the template that does not exist" ], "complements": true, "patterns": [ "BE03" ], "reviewed": false }, "import-wizard": { "title": "Import wizard", "description": "The file comes first, then the mapping of the columns, then the preview with the cases that do not fit, and only at the end the adoption.", "principles": [ "Error Prevention", "Visibility of system status", "User control and freedom", "Progressive Disclosure" ], "pros": [ "Errors are noticed before the adoption, not afterwards in the data", "The column mapping is explained once and reusable afterwards", "The user sees what arrives before taking responsibility for it" ], "cons": [ "Several steps for a task that feels like one button", "With large files the preview has to select what it shows – and say that it selects", "Partial adoption needs a rule the user understands" ], "whenNot": "When the file is always structured the same way and needs no mapping. Then an upload with a result report is enough.", "designTips": [ "Prefill the detected columns and mark the suggestion as a suggestion", "Count the faulty rows, show them and make them downloadable", "Say what happens to the faulty rows – skipped or everything aborted", "Name what the last step does: “Import 312 documents”, not “Done”", "After the import, show the way to the result, not just a success message" ], "complements": true, "patterns": [ "BE05" ], "reviewed": false }, "transfer-list": { "title": "Transfer list", "description": "On the left is what is available, on the right what is assigned. The user moves back and forth, and both sides stay visible.", "principles": [ "Recognition rather than recall", "Visibility of system status", "User control and freedom" ], "pros": [ "The state is there at a glance – assigned and not assigned side by side", "Several assignments in one move, without opening a dialog for each", "Undoing is the same gesture as assigning, just the other way round" ], "cons": [ "Needs space – on narrow screens the side-by-side falls apart", "With long inventories the left side is unusable without search", "The order on the right side needs a rule, otherwise it looks random" ], "whenNot": "When it is about a single assignment. Two lists for one value are an apparatus for one hand movement.", "designTips": [ "Make both sides searchable, not only the left", "Show the count per side and let it run along while moving", "Allow both multiple selection and double-click", "Gray out what is already assigned on the left instead of removing it, when the origin remains important", "Say when the assignment takes effect – immediately or only on saving" ], "complements": true, "next": { "click": "“Save assignment”", "text": "The page returns to the record, and the assignments are there as a list with their count. Anyone leaving the page with unsaved moves is asked – the two lists do not remember anything on their own." }, "patterns": [ "L09" ], "reviewed": false }, "picker-dialog": { "title": "Picker dialog", "description": "A dialog with a search field and the hits below it. The user types the name, chooses an entry, the dialog closes.", "principles": [ "Flexibility and efficiency of use", "Aesthetic and minimalist design", "Doherty Threshold" ], "pros": [ "The shortest way when the name is known – type, choose, done", "The inventory behind it may be arbitrarily large, the interface stays the same", "Additional details per hit help with identical names, without overloading the list" ], "cons": [ "Anyone who does not know the name faces an empty field", "Without additional details, two identically named entries cannot be told apart", "A dialog above the page hides the context in which the assignment is made" ], "whenNot": "When the user first has to look through the inventory to know what they are looking for. Then a structure belongs in front of it.", "designTips": [ "Focus is in the search field on opening", "A second line per hit with what distinguishes it – location, number, department", "Show the most recent or most frequent entries before anything is typed", "With no hits, say what is missing and offer the way to create it", "After the choice, show what was assigned and put the undo beside it" ], "complements": true, "next": { "click": "“Adopt client”", "text": "The dialog closes, the field carries the chosen client, focus is on it again. If the user does not find the record, the dialog needs the way to create it – otherwise they cancel, create it elsewhere and search once more.", "target": "form-modal", "image": "In the dialog footer, on the left, is “Create new client” – for the case that the search stays empty." }, "patterns": [ "BE04" ], "reviewed": false }, "browse-categories": { "title": "Category browsing", "description": "The inventory stands in its order – clients, years, departments. The user follows the path they have in mind anyway, and the list gets shorter as they go.", "principles": [ "Recognition rather than recall", "Match between system and the real world", "Progressive Disclosure", "Hick's Law" ], "pros": [ "The user does not have to be able to name anything – they recognize instead of remembering", "The order itself explains the inventory: what exists is seen while walking", "The path is repeatable and can be explained to someone" ], "cons": [ "Slower than a search when the target is known", "An order the user does not share leads them astray", "Entries that belong in two places fit into no structure without duplication" ], "whenNot": "When the inventory is flat or the structure comes from the database rather than from the work. Then search is the more honest way.", "designTips": [ "Leave the search next to it, not behind it – both ways apply at the same time", "Show per branch how much is in it before it is opened", "Keep the path taken visible and allow jumping back at any point", "Two levels are usually enough; three are the limit", "Do not hide empty branches, show them as empty" ], "complements": true, "next": { "click": "An account in the list on the right", "text": "The account is chosen and is adopted – where the assignment is needed. The structure was the way and closes afterwards; what remains is the value in the field, with its path beside it.", "image": "Below the list is “Adopt account” for the chosen account." }, "patterns": [ "L08" ], "reviewed": false }, "saved-views": { "title": "Saved views", "description": "The always-same combination of filters, columns and sorting gets a name. The user chooses the view and is where they left off yesterday.", "principles": [ "Flexibility and efficiency of use", "Recognition rather than recall", "User control and freedom", "Consistency and standards" ], "pros": [ "The recurring setting is made once and afterwards only chosen", "A named view can be talked about – “look at the open cases North”", "Shared views turn a personal habit into an agreement in the team" ], "cons": [ "Views silently go stale when the data or the task changes", "Many views are themselves a list that has to be organized", "Whoever changes a shared view changes it for others too" ], "whenNot": "When the filtering is different every time. A saved view that nobody calls up twice is one more entry in the menu.", "designTips": [ "When a view is changed, make clear that it is changed – and distinguish between Save and Save as", "Let a view be set as the start view", "Show what is in a view without opening it", "Separate shared views from own ones and name the owner", "The unsaved intermediate state must not silently disappear on switching" ], "complements": true, "patterns": [ "TB03", "TB04" ], "reviewed": false }, "diff-view": { "title": "Diff view", "description": "On the left one state, on the right the other, and in between what differs is marked. What is the same recedes, what deviates stands out.", "principles": [ "Recognition rather than recall", "Visibility of system status", "Aesthetic and minimalist design", "Error Prevention" ], "pros": [ "The difference is shown and not searched for – that is the actual question", "Both states stay completely visible, not just their summary", "Before an adoption it is traceable what it will change" ], "cons": [ "With many small deviations, the marking itself becomes noise", "Fields that exist on only one side need a representation of their own", "Only for two states – a third bursts the side-by-side" ], "whenNot": "When different records are compared instead of two states of the same one. Then the question is “which one”, and the comparison table is there for that.", "designTips": [ "Make unchanged parts collapsible and name the number of hidden rows", "Distinguish added, removed and changed, not just “different”", "Name both sides, with time and origin", "Bind the sides together when scrolling", "If adoption is possible, then per field and not only as a whole" ], "complements": true, "next": { "click": "A changed row", "text": "Whoever compares two states often wants one of them back. Each changed row therefore carries “Restore” for its old value – individually, not for the whole state. Afterwards the row is no longer changed, and the counter at the top follows.", "image": "Each changed row carries “Restore” for the old value." }, "patterns": [ "ST02" ], "reviewed": false }, "dual-approval": { "title": "Dual approval", "description": "Two people decide one after the other. The first releases, the second confirms, and until then the process visibly stands in between.", "principles": [ "Error Prevention", "Visibility of system status", "Help users recognize, diagnose, and recover from errors" ], "pros": [ "The intermediate state is a state of its own and not an oversight", "Whoever is still missing is named – responsibility does not lie in a fog", "An error in the first approval gets a second chance to be noticed" ], "cons": [ "The process stands still as long as the second person is not there", "Substitution and escalation have to be thought through, otherwise vacation blocks operations", "Two approvals by the same person are a circumvention that has to be prevented" ], "whenNot": "When one decision is enough. The second signature costs time and only achieves something where the potential damage justifies it.", "designTips": [ "Name the intermediate state – “released by Keller, waiting for second approval”", "Do not allow one's own approval twice and write down the reason", "Make substitution and deadline visible before something gets stuck", "Lead the second person's rejection back to the first, with a reason", "Keep the history on the process: who did what when" ], "complements": true, "next": { "click": "“Give second approval”", "text": "The chain advances to “Executed”, the run leaves the list of open ones, and the confirmation names the execution day. Afterwards the run is a process with stations – whoever looks later wants to know where it stands.", "target": "process-status" }, "patterns": [ "ST01" ], "reviewed": false }, "alert-worklist": { "title": "Monitoring worklist", "description": "At the top the state, below it the cases that are not in order. What stands out can be acknowledged, assigned or opened from there.", "principles": [ "Visibility of system status", "Help users recognize, diagnose, and recover from errors", "Flexibility and efficiency of use" ], "pros": [ "Seeing and acting are in one place – no switch to another view", "The list is the day's work and says when it is done", "Acknowledged cases disappear, and the rest stays manageable" ], "cons": [ "Too many alerts dull the senses, and the list becomes background noise", "Without responsibility, everyone or nobody takes care of it", "An alert without a next step is a worry without a way out" ], "whenNot": "When nothing follows from the monitoring. Then the overview is enough, and a worklist promises a responsibility that does not exist.", "designTips": [ "Offer the next step per alert, not just the state", "Make acknowledging and assigning possible from the list without leaving it", "Make thresholds visible – from when something counts as conspicuous", "Bundle similar alerts instead of counting them", "Show standstill as a state: since when the oldest case has been lying there" ], "complements": true, "next": { "click": "“Details” on the alert", "text": "“Take over” writes the name on the alert and takes it out of the list of open ones. But it is not fixed here: “Details” leads to the process in which the error lies – to the aborted run, to the interface. The alert is the entry, the work happens there.", "target": "table-detail" }, "patterns": [ "SC05", "L06" ], "reviewed": false }, "activity-feed": { "title": "Activity feed", "description": "The events stand one below the other, the newest on top. Each row names the person, the action and the time. New entries are added at the top without the page being reloaded.", "principles": [ "Visibility of system status", "Match between system and the real world", "Recognition rather than recall" ], "pros": [ "The history is there without anyone having to compile it", "Temporal connections stand out that get lost in a table", "Each row is the entry into the process behind it" ], "cons": [ "Without a filter, the list is unreadable after a day", "The important stands next to the trivial, both the same size", "Entries moving up shift the row one is just reading" ], "whenNot": "When it is about the state and not the history. Here it says what happened – not how things stand.", "designTips": [ "Make it filterable by type and person, from the start", "Structure by days and name the days", "Announce newly arriving entries instead of shifting the view", "Per row person, action, object and time – in this order", "Show an end when the stream ends, instead of loading endlessly" ], "complements": true, "patterns": [ "L02", "L04" ], "reviewed": false }, "export-dialog": { "title": "Export dialog", "description": "A dialog says what is output, in which format, and how many records that is. Only then is the file created.", "principles": [ "Visibility of system status", "Error Prevention", "User control and freedom" ], "pros": [ "The scope is fixed before the export and not discovered afterwards", "Format and column choice in one place instead of in three menus", "The number of records prevents the accidental full export" ], "cons": [ "A dialog for something that feels like one button", "Large exports take time and need a place where they get finished", "Too many settings turn the export into a task of its own" ], "whenNot": "When always the same is exported. Then the dialog is a detour, and a button with a clear label is enough.", "designTips": [ "Name the scope – “filtered 312 of 8,400”, not “Selection”", "Prefill the format chosen last", "Finish long exports in the background and show the way there", "Suggest the file name, with date and filter in it", "Say what does not come along – attachments, hidden columns, formulas" ], "complements": true, "patterns": [ "BE06" ], "reviewed": false }, "report-builder": { "title": "Report builder", "description": "The user chooses period, structure and key figures, sees the result and saves the composition for next time.", "principles": [ "Flexibility and efficiency of use", "User control and freedom", "Visibility of system status", "Progressive Disclosure" ], "pros": [ "Recurring questions are formulated once and afterwards only run", "The tailoring is with the one who has the question, not in a ticket", "Saved analyses are comparable because they are tailored the same way" ], "cons": [ "The freedom invites analyses that nobody understands any more", "Intermediate states without a result frustrate when the path is long", "Numbers from two different setups look comparable and are not" ], "whenNot": "When it is about a few fixed analyses. Then ready-made views are more honest than a construction kit that is operated anew every time.", "designTips": [ "Show an interim result after every change, not only at the end", "Carry the tailoring along on the result – period, filter, structure", "Start with ready-made analyses and derive the changing from them", "Require a name on saving that states the question", "Let the export of the analysis carry the same tailoring" ], "complements": true, "patterns": [ "SC06" ], "reviewed": false }, "settings-sections": { "title": "Settings sections", "description": "On the left the sections, on the right the values of the chosen one. Each setting stands with its explanation where it belongs.", "principles": [ "Recognition rather than recall", "Aesthetic and minimalist design", "Progressive Disclosure", "Consistency and standards" ], "pros": [ "The inventory of settings stays manageable, even as it grows", "Each setting has a place that can be described", "Rarely used things lie behind a section instead of on the same screen" ], "cons": [ "A setting that belongs in two sections is hard to find in both", "Search is rarely missing for long once there are more than twenty values", "Validity and time of effect are often unclear with settings" ], "whenNot": "When it is a handful of values. Sections for six settings are a structure without a subject.", "designTips": [ "One sentence per setting saying what it does – not just the label", "Say when a change takes effect: immediately, on the next run, after logging in again", "Name the default value and offer resetting", "Make it searchable across all sections as soon as it is more than one screen", "Mark settings with consequences for others as such" ], "complements": true, "next": { "click": "“Save changes” in the section", "text": "The “unsaved” mark on the section disappears, and the value applies from now on to everyone who works afterwards. Whoever switches sections with an open change is asked. Saving is per section, not for the whole page.", "image": "After saving, the “General” section loses its “unsaved” mark." }, "patterns": [ "F04", "F02" ], "reviewed": false }, "read-view": { "title": "Read view", "description": "The record is there to be read. The details stand as text, in named groups, the most important at the top. No fields, no frames in between.", "principles": [ "Aesthetic and minimalist design", "Recognition rather than recall", "Progressive Disclosure" ], "pros": [ "The details are quicker to take in than in the form, because no frames stand in between", "Nothing can be changed by accident, because there is nothing to change", "More room per detail, so long values too without truncation" ], "cons": [ "Whoever does have to correct something needs a second way there", "Without groups, a long read view becomes a wall of text", "Details without a value look like forgotten ones if they are left standing" ], "whenNot": "When something is regularly corrected while reading. Then an edit mode belongs with it.", "designTips": [ "Group the details and name each group", "Leave out empty details instead of filling them with a dash", "Put long texts and attachments behind progressive disclosure", "Keep the way to editing visible, even if it is not the normal case here", "Offer values for copying, such as document and account number" ], "complements": true, "patterns": [ "SC02" ], "reviewed": false }, "read-view-edit": { "title": "Read view with edit mode", "description": "Reading is the normal case, changing the exception. The record stands as text, a button switches to fields. After saving, text stands there again.", "principles": [ "Error Prevention", "User control and freedom", "Aesthetic and minimalist design", "Progressive Disclosure" ], "pros": [ "The frequent case, reading, is also the fast one", "Changing is an action of its own and does not happen on the side", "One place for the record instead of two pages for the same details" ], "cons": [ "Switching costs a click and shifts the layout", "Two states mean two versions of the same content that can drift apart", "Unsaved changes on leaving need a rule of their own" ], "whenNot": "When almost every visit ends with a change. Then the form is the normal case and switching is only a detour.", "designTips": [ "Leave the details in the same place in read and edit mode", "With long records, switch individual groups instead of the whole", "Ask about unsaved changes on leaving", "After saving, back to read mode, do not stay in the form", "Show who changed last and when" ], "complements": true, "next": { "click": "“Save” at the top right", "text": "The page stands as text again, the line at the top names who changed when. Cancelling with open changes asks first. The user stays on the page – back to the list leads only the way they came by." }, "patterns": [ "SC04", "F01" ], "reviewed": false }, "review-checklist": { "title": "Review checklist", "description": "The items stand one below the other, each with a checkmark behind it. The user goes through them in turn. At the top it says how many are still open.", "principles": [ "Recognition rather than recall", "Error Prevention", "Flexibility and efficiency of use", "Zeigarnik Effect" ], "pros": [ "The state is readable at any time, also for whoever asks about it later", "An interruption costs nothing, because the ticks set remain", "Skipped items stay visible instead of getting lost" ], "cons": [ "For a brief look at a few items, the setup is too heavy", "Ticks without consequence become a habit and are then set without checking", "Whoever has to pass on the state also needs it outside this view" ], "whenNot": "When the items are independent of each other and nobody needs the state. Then the list is enough.", "designTips": [ "Count the state – “14 of 40 checked”, do not just show a bar", "For each item, say what it is checked against", "Let an item with a finding take a comment, not just a tick", "Do not count the last tick as completion – completion is an action of its own", "Record who checked and when" ], "complements": true, "next": { "click": "The item with a finding", "text": "A finding is not a tick: the item needs the way to the correction, to where the value stands. Back in the list it then carries “checked”. The completion at the bottom stays locked as long as a finding is open – and says why.", "target": "edit-in-place", "image": "The item with a finding carries “Correct” beside the note; the completion at the bottom is locked and names the reason." }, "patterns": [ "L03", "L06" ], "reviewed": false }, "approve-with-edit": { "title": "Approval with correction", "description": "The reviewer does not only decide, they may correct beforehand. What they changed stands beside the old value, and the approval applies to the corrected state.", "principles": [ "Flexibility and efficiency of use", "Error Prevention", "Visibility of system status", "User control and freedom" ], "pros": [ "A transposed digit costs no rejection and no second round", "The process stays in one hand instead of shuttling between two people", "What was changed stands on the process and not in an email beside it" ], "cons": [ "The separation of creating and reviewing loosens – whoever corrects reviews their own change", "Without a log, it cannot be established afterwards who set which value", "With extensive corrections, rejection is the more honest way" ], "whenNot": "When creating and reviewing have to stay separate in business terms. Then there is only approve or reject, and the correction is made by whoever submitted.", "designTips": [ "Leave the old value standing beside the new one, do not replace it", "Record per correction who made it and when", "Set a limit from which to reject instead of correct – and name it", "Notify the submitter about the correction, not just about the approval", "Treat approving and correcting as two actions, not as one" ], "complements": true, "next": { "click": "“Approve as corrected”", "text": "Before the approval stands the difference from the submitted state. Afterwards the submitter receives the correction with the note, and the document goes into the second approval – from €1,000 it takes two people.", "target": "dual-approval" }, "patterns": [ "SC04", "TD01" ], "reviewed": false }, "edit-in-place": { "title": "Edit in place", "description": "Each detail is changed on its own. One click turns the text into a field, saving applies only to that one detail, and the rest of the page stays text.", "principles": [ "Flexibility and efficiency of use", "Error Prevention", "Aesthetic and minimalist design", "Fitts's Law" ], "pros": [ "The shortest way for the most frequent change – one detail, one click", "The other details stay readable while one is being changed", "A failed attempt affects only one field and not the whole page" ], "cons": [ "It is the wrong form for details that depend on each other", "Each field needs its own save state – saved, in progress, failed", "Whoever changes many details in a row clicks more than in a form" ], "whenNot": "When several details have to be checked or saved together. Then the whole page belongs in an edit mode.", "designTips": [ "Make visible which details are changeable – before the first click, not only on hover", "Show per detail whether it is saved, and put the message beside the field", "Escape discards, Enter saves, Tab goes to the next detail", "Leave a failed input standing, do not reset it to the old value", "Offer undo as long as the detail is in view" ], "complements": true, "next": { "click": "“Save” on the detail", "text": "The detail becomes text again, and beside it it says when it was saved. If it fails, the field stays open and carries the error. Tab leads to the next detail – whoever changes several runs through the page without ever switching into a mode." }, "patterns": [ "TD01", "L06" ], "reviewed": false }, "form-inline": { "title": "Inline form", "description": "The form stands on the page, next to what the user needs while filling it in. They can look things up and compare without leaving it.", "principles": [ "Recognition rather than recall", "Aesthetic and minimalist design", "User control and freedom" ], "pros": [ "What stands on the page stays readable while filling in", "No opening and closing, and several entries in a row are a flow", "Room for hints and validation messages, which a dialog does not have" ], "cons": [ "The page carries two tasks at the same time and gets longer", "The start of the form is not necessarily in view when the user is standing at the bottom", "Without clear delimitation it is not visible where the form begins" ], "whenNot": "When the page behind it plays no role while filling in. Then the dialog takes the distraction away from the user.", "designTips": [ "Delimit the form visibly – a card or a heading, not just spacing", "Jump to the form when it arises through an action", "Cancel and Save at the end of the form, not at the end of the page", "After saving, show what was created and where it stands" ], "complements": true, "next": { "click": "“Create cost center” – or “Save” for settings", "text": "The new row stands at the top of the list, highlighted, and the form is empty for the next one. With settings, the saved value applies immediately to everyone who works afterwards, and the page says so – a silent save makes the user check whether it took effect.", "image": "After “Create cost center”, the new row stands at the top of the list, highlighted." }, "patterns": [ "F01", "F03" ], "reviewed": false }, "form-modal": { "title": "Dialog form", "description": "The form opens as a dialog above the page. The page behind waits, and the user fills in a delimited task.", "principles": [ "Aesthetic and minimalist design", "Hick's Law", "Error Prevention", "User control and freedom" ], "pros": [ "One task, one window – nothing beside it distracts", "Can be opened from anywhere, also where no fitting page exists", "The completion is unambiguous: the dialog closes or it stays open" ], "cons": [ "The page behind is covered, looking things up is not possible", "As soon as the content grows, the dialog becomes a bad form", "Nested dialogs are not a way out but a sign of the wrong form" ], "whenNot": "When the user has to look things up or compare while filling in. And as soon as the content grows beyond one screen – then it belongs on a page.", "designTips": [ "Limit to one task and carry exactly one accent button in the footer", "Close via Escape and via a visible Cancel button", "On cancelling with input, ask instead of silently discarding it", "Do not open a second dialog from the first", "After creating, say what was created – the dialog disappears, the information must not" ], "complements": true, "patterns": [ "F01", "BE03" ], "reviewed": false }, "search-global": { "title": "Global search", "description": "A search field in the header searches across all kinds of data. The hits stand below, grouped by type, with the total count per group and the way to all of them.", "principles": [ "Recognition rather than recall", "Flexibility and efficiency of use", "Aesthetic and minimalist design" ], "pros": [ "One way to the target, no matter in which area it lies", "Reachable from every page without navigating first", "The groups show along the way which kinds of data exist at all" ], "cons": [ "Good hits across all types are costly to build", "Without grouping, clients and employees stand mixed up", "It is not good for narrowing a set – it looks for a hit" ], "whenNot": "When the user knows anyway in which inventory they are searching. Then the search field belongs above the list and not in the header.", "designTips": [ "Show what was opened last before anything is typed – the surface does not stay empty", "Group hits by type, per group the total count and three hits", "Offer the way into the full list per group", "Assign a keyboard shortcut and name it in the field", "With zero hits, say what was searched in" ], "complements": true, "patterns": [ "SU01" ], "reviewed": false }, "tree-browse": { "title": "Tree browsing", "description": "The structure is multi-level, and the tree shows it. The user expands what concerns them and sees where they are and what lies beside it.", "principles": [ "Recognition rather than recall", "Progressive Disclosure", "Gestalt Principles" ], "pros": [ "The order of the inventory is visible, not just its entries", "The way to an entry is at the same time its classification – account class, group, account", "Only what is needed is expanded; the rest stays one row" ], "cons": [ "A deep tree demands many clicks down to the leaf", "Whoever does not know the structure searches in the wrong branch", "From about four levels, the indentation becomes a space problem" ], "whenNot": "When the structure has only one level. Then a grouped list is enough, and the tree is a mechanism without a subject.", "designTips": [ "Lay a search over the tree – it leads to the hit and expands the way there", "Name the path of the chosen entry outside the tree, e.g. as a breadcrumb", "Keep the expanded state across page changes", "Show per node the number of entries below it, if it helps when searching", "From four levels, check whether the structure itself is too deep" ], "complements": true, "next": { "click": "An account in the tree", "text": "The path above the tree shows the choice, and “Adopt account” carries it to where it is needed. The tree is the way to the assignment, not its place – after adopting, the value stands in the field, with the path beside it.", "image": "Below the tree is “Adopt account” for the chosen account." }, "patterns": [ "L08", "L03" ], "reviewed": false }, "document-side": { "title": "Document beside form", "description": "On the left the document, on the right the details for it. The user reads in the document and checks or captures beside it, without switching between two windows.", "principles": [ "Recognition rather than recall", "Flexibility and efficiency of use", "Error Prevention", "Aesthetic and minimalist design" ], "pros": [ "The source and the detail stand side by side – no remembering, no switching", "Typing errors are noticed as long as the document stands beside it", "Paging, zooming and rotating stay with the document and do not disturb the fields" ], "cons": [ "Two areas share the width; both get narrower than alone", "Without a movable divider, the ratio never fits all document types", "On narrow screens only switching remains instead of a side-by-side" ], "whenNot": "When no document belongs to the record or nobody needs it during the work. An empty document area takes half the width away from the work.", "designTips": [ "Make the divider movable – which side needs more depends on the document", "Leave zoom, rotate and paging with the document and do not mix them into the page's toolbar", "Highlight the spot in the document a value comes from, when it is known", "Change the document along when moving to the next record, without losing the zoom level", "On narrow screens switch instead of squeezing, and keep the switch visible" ], "complements": true, "next": { "click": "“Post and continue”", "text": "The next document from the inbox stands on the left, the fields on the right are empty or prefilled, the counter advances. That is the work queue with Continue – only with the document beside it. Whoever cannot post the document sets it aside.", "target": "record-queue" }, "patterns": [ "SC03", "SC02" ], "reviewed": false }, "process-status": { "title": "Process status", "description": "A process, its stations and the one it currently stands at. Each station names time and person, and the next says what is being waited for.", "principles": [ "Visibility of system status", "Match between system and the real world", "Recognition rather than recall" ], "pros": [ "The question “where does my process stand” is answered without asking back", "Each station carries time and person – the history is documented", "What it hangs on stands at the open station and not in a footnote" ], "cons": [ "Meant for one process; a list of processes needs a different form", "A chain without times only says the order, which one knows anyway", "Skipped or repeated stations are hard to show in a straight chain" ], "whenNot": "When many processes have to be in view at the same time. Then it is a list with a state column and not a chain.", "designTips": [ "Name time and person per station, not just the checkmark", "At the open station, say what is being waited for and who is up", "Show a rejection as a station of its own, not as a jump back without a trace", "Offer the way to the process itself – the chain is information, not the work", "With long chains, summarize the finished ones and spell out the open ones" ], "complements": true, "patterns": [ "ST01" ], "reviewed": false }, "calendar-view": { "title": "Availability grid", "description": "The people stand as rows, the days as columns. A period is a continuous area across several days, and where two overlap, they stand one below the other in the same column.", "principles": [ "Match between system and the real world", "Gestalt Principles", "Visibility of system status", "Recognition rather than recall" ], "pros": [ "Overlaps and gaps are seen and not calculated", "A period is an area and not two dates in one row", "Weekends and holidays are in the picture as columns" ], "cons": [ "The width grows with the period – a year does not fit on one screen", "Details have no room in a day column and need a second place", "Whoever looks for a particular entry finds it faster in a list" ], "whenNot": "When the date is only one detail among many. Then it belongs in a column, and the list stays the form. And when only a single date is to be chosen – that is what the date picker is for.", "designTips": [ "Make the time span selectable: two weeks, month, quarter. The choice persists on the next visit", "Mark weekends and holidays as columns, they are half the reason for the form", "Each area carries an abbreviation and not just a color; the legend stands beside it", "Offer the same entries as a list – searching and filtering happen there", "To enter, drag across the days; the details for it come afterwards in a dialog" ], "complements": true, "patterns": [ "KA01" ], "reviewed": false }, "ai-suggest-fill": { "title": "Suggested values", "description": "The fields are prefilled, but marked as a suggestion. Beside it stands where the value comes from, and only adopting makes it the value of the record.", "principles": [ "Visibility of system status", "User control and freedom", "Error Prevention", "Recognition rather than recall" ], "pros": [ "The frequent input falls away, the rare one remains possible", "The suggestion names its origin – document, previous month, same booking in the previous year", "Whoever adopts nothing still has a complete form in front of them" ], "cons": [ "A wrong suggestion that looks like a value is adopted without looking", "Suggestions that are often off cost more time than they save", "Without marking, it cannot be established afterwards who set which value" ], "whenNot": "When the suggestions are not reliable or their origin cannot be named. A suggestion without a reason is guessed, and a guessed value in a required field is worse than an empty one.", "designTips": [ "Visibly distinguish suggested values from entered ones, not just by a note below", "Say per suggestion where it comes from – “read from the document”, “as in the previous month”", "Adopting must be an action, even if it is one for all at once", "With low confidence, rather leave the field empty than guess badly", "Record which value was suggested and which was typed" ], "complements": true, "patterns": [ "F01", "TD01" ], "reviewed": false }, "ai-anomalies": { "title": "Flagged anomalies", "description": "The interface highlights what deviates from the usual, and says for each case what it bases that on. The list stays complete – it is sorted, not filtered.", "principles": [ "Visibility of system status", "Recognition rather than recall", "Error Prevention", "Match between system and the real world" ], "pros": [ "The eye goes first to where it is needed", "The reasoning is checkable – “82% above the previous month” can be recalculated", "What does not stand out still stays in the list and is not hidden" ], "cons": [ "Whoever relies on it no longer checks the rest", "Too many hits without consequence dull the senses, and then the real one is overlooked too", "An anomaly without a reason is an assertion and not a help" ], "whenNot": "When it cannot be said what a deviation is based on. A marker without a comprehensible reason only shifts the check instead of easing it.", "designTips": [ "Name the reason per anomaly as a number or comparison, not as an assessment", "Keep the complete list and highlight the anomalies in it, do not filter them out", "Let users tick off that an anomaly has been checked and is fine", "Show how much was checked and how much not – the rest is not checked, just inconspicuous", "Make wrongly detected cases reportable, otherwise they repeat every month" ], "complements": true, "patterns": [ "L03", "L04" ], "reviewed": false }, "ai-ask": { "title": "Natural language query", "description": "A field takes the question as a sentence. What becomes of it stands above as readable criteria – the user sees how the question was understood and can correct it there.", "principles": [ "Recognition rather than recall", "Visibility of system status", "User control and freedom", "Flexibility and efficiency of use" ], "pros": [ "Whoever does not know the criteria still arrives at a selection", "The translated criteria are visible and individually changeable", "The path ends in an ordinary search – what becomes of it can be saved" ], "cons": [ "A misunderstood question delivers a plausible but wrong set", "Without visible criteria it cannot be recognized what was searched for", "For always the same question, typing is longer than a saved filter" ], "whenNot": "When the criteria are manageable and named. Then the form is shorter than the sentence, and it says more precisely what it does.", "designTips": [ "Show the understood question as criteria before the hits come", "Make each criterion individually changeable and removable", "Offer example questions while the field is empty", "Say when part of the question was not understood – do not silently leave it out", "Transfer the result into the ordinary search so that it becomes saveable" ], "complements": true, "patterns": [ "SU01", "TB03" ], "reviewed": false }, "search-page": { "title": "Search page", "description": "Searching is the task, not the way to it. The criteria stand at the top as a form, the hits below, and the search has an address of its own – it can be saved, shared and repeated.", "principles": [ "Recognition rather than recall", "Flexibility and efficiency of use", "User control and freedom", "Visibility of system status" ], "pros": [ "Room for many criteria, in groups, with an explanation per field", "The search is a place: linkable, repeatable, passable to someone", "Work continues with the hits – select, export, process further" ], "cons": [ "One more place in the navigation that has to be found", "For a quick look for a name, the way is too long", "Whoever does not know the criteria faces an empty form" ], "whenNot": "When one search term and a hit list are enough. Then the field belongs above the list and not on a page of its own.", "designTips": [ "Group the criteria and put the rarely used ones behind progressive disclosure", "Show the most recently used searches as long as the form is empty", "Name the hit count before the list is built – with 12,000 hits the list does not help further", "Make the search saveable and nameable; the address must carry the criteria", "Let work continue from the hits: select, export, assign" ], "complements": true, "patterns": [ "F02", "F04" ], "reviewed": false }, "search-local": { "title": "List search", "description": "The search field stands in the toolbar above the list and narrows it. The number below says how many of how many are left.", "principles": [ "Visibility of system status", "Recognition rather than recall", "Doherty Threshold" ], "pros": [ "The reference is unambiguous: the search is in what stands below", "Immediate feedback – the list gets shorter while typing", "No applying, no second step" ], "cons": [ "Finds only what stands in this list", "With several criteria, one search field is not enough", "Without a hit count, an empty list cannot be told apart from an empty inventory" ], "whenNot": "When the user does not know in which area their target lies. Then the global search in the header is the way.", "designTips": [ "Show the hit count in the meta line below the toolbar, as “6 of 84”", "Filter while typing, without applying", "Name the search term in the empty state when nothing is left", "Make the field clearable – one click, not seven backspaces" ], "complements": true, "patterns": [ "TB03" ], "reviewed": false }, "filter-drawer": { "title": "Filter drawer", "description": "The filter button opens a drawer from the right. It has room for any number of filters, also for groups. Every change takes effect immediately, there is no applying.", "principles": [ "Progressive Disclosure", "Flexibility and efficiency of use", "Visibility of system status" ], "pros": [ "Room for any number of filters without lengthening the page", "The filters are gone when not needed, and completely there when they are", "Groups of filters can be named and ordered" ], "cons": [ "The filters are not visible as long as the drawer is closed", "It makes the table narrower as long as it is open", "What is set must be shown outside the drawer – otherwise nobody sees it" ], "whenNot": "When one or two filters are enough that always apply. They belong visibly in the toolbar and not behind a button.", "designTips": [ "Show set filters as badges above the list, individually removable", "Write the number of set filters on the button", "Filter without applying – every change takes effect immediately", "Offer reset all, visibly beside the badges", "Let the hit count run along while choosing in the drawer" ], "complements": true, "patterns": [ "FI01" ], "reviewed": false }, "filter-panel": { "title": "Inline filter panel", "description": "The same filter button unfolds a panel across the full width, directly below the toolbar. The content moves down, nothing is covered.", "principles": [ "Progressive Disclosure", "Visibility of system status", "Aesthetic and minimalist design" ], "pros": [ "The table keeps its full width – nothing gets narrower", "All filters stand side by side and can be taken in at a glance", "No overlay, so no modality that blocks the rest" ], "cons": [ "Carries at most four filters, and no groups", "The content jumps down when the panel unfolds", "With more filters, the panel becomes taller than the list below" ], "whenNot": "As soon as there are more than four filters or they need groups. Then only the drawer carries them.", "designTips": [ "Change the button's label and set `aria-expanded`", "Do not scroll on unfolding – the start of the list stays in view", "Show set filters as badges also when the panel is folded", "Filter without applying, as in the drawer" ], "complements": true, "patterns": [ "FI02" ], "reviewed": false }, "filter-toolbar": { "title": "Toolbar filters", "description": "The filters stand openly as selects in the toolbar. The first says which inventory is on the screen, the second narrows it. Both take effect immediately.", "principles": [ "Visibility of system status", "Recognition rather than recall", "Aesthetic and minimalist design" ], "pros": [ "The set value is always visible – without a click, without a badge beside it", "The shortest way: look, change, done", "No opening, no closing, no second level" ], "cons": [ "Carries only one to two filters – after that the toolbar is full", "On narrow screens the selects compete with the actions", "What does not fit in still needs a filter button beside it" ], "whenNot": "As soon as there are more than two filters or they are not always needed. Then they belong in the drawer.", "designTips": [ "The first select is the context choice and always has a value – it never stands on “all”", "Both without a label, the chosen value carries the information", "Take effect immediately, no applying", "If something lies behind it, a filter button is added – otherwise not" ], "complements": true, "patterns": [ "FI03" ], "reviewed": false }, "filter-tiles": { "title": "Tiles as filters", "description": "The tiles above the list are the filter. Each carries a number and a state, a click narrows the list to it, and several tiles work together.", "principles": [ "Visibility of system status", "Recognition rather than recall", "Gestalt Principles" ], "pros": [ "The numbers are themselves information and do not stand somewhere else once more", "The inventory is structured before the user clicks anything", "Filtering and overview are the same action" ], "cons": [ "Carries exactly one dimension – for the second, a drawer is needed after all", "Takes space above the list that nobody can survey any more with many tiles", "Whether several tiles add up or narrow down has to be tried out if it does not say so" ], "whenNot": "When several criteria are combined or nobody is interested in the numbers. Then it is a filter and not an overview.", "designTips": [ "Build the tile as `ed-card selectable` – it thereby gets the role of a checkbox", "Say that several tiles add up, if they do", "Also carry the set tiles as badges above the list", "Let the numbers run along when another filter changes the set" ], "complements": true, "patterns": [ "FI04" ], "reviewed": false } } }