Settling a Business App's UI on One Design: What Narrows the Options, How to Compare Them, and Who Decides

Few teams choose from a blank page

Starting from a blank page, one can draw any number of options for a business app’s screen. Whether a list is a table or cards, whether input goes on one screen or is split into steps. Count the order of fields, the position of buttons, and even the amount of whitespace, and the combinations never end.

Yet in the records written by the makers of enterprise design systems and by designers of business SaaS, scenes of choosing one design from countless options hardly appear. Most options have disappeared before anyone draws them. SAP’s Fiori has designers choose a screen type (floorplan) from the screen’s purpose. A screen for finding items in a large amount of data gets a list type, and a screen for displaying and editing a single object gets a detail type (SAP 2026). At this point, the option of showing the list as cards never becomes a candidate.

Ordered by when options disappear, the process falls into three stages. They are the preconditions that narrow the space before drawing, the procedures that widen and compare the remaining options, and finally the person and criteria that choose one. The first and second are also written in standards and government guidance. For the third, who chooses the final one and on what basis, the standards and guidance read here give no concrete description, and each company’s procedures are more concrete¹.

What must be decided before drawing for the options to shrink?

The human-centred design standard ISO 9241-210:2019 sets as one of its principles that design is based upon an explicit understanding of users, tasks, and environments (ISO 2019a, 5.2). In explaining this, it gives the example that a screen that gives a good experience to young people downloading music on a smartphone may be entirely unsuited to handling corporate data on a mobile device. The standard calls the combination of users, tasks, and environment the context of use. Usability, too, is defined as the degree of effectiveness, efficiency, and satisfaction once this combination is specified (ISO 2019a, 3.13; the ISO 9241-11:2018 definition). For the description of the context of use, the report of user needs, and the evaluation report, there are standards that each define a common document format (ISO/IEC 25063, 25064, 25066; NIST n.d.). That systems used inside an organization are also subject to human-centred design is stated explicitly in the abstract of ISO 9241-220:2019: “either their internal systems or the products and services they provide” (ISO 2019b).

Within the context of use, the first thing decided is whom the screen is for. IBM’s Enterprise Design Thinking has teams sum up a project’s intent in short statements called Hills, and its Who item reads “Make it clear who you aim to serve—and who you don’t” (IBM n.d.). Writing down the users left out removes the options meant for them. Karri Saarinen, co-founder of Linear, also writes that an excellent product cannot be made without designing for someone specific, and that designing a product for everyone is nearly impossible (Saarinen 2025).

Next, once it is decided how success is measured, the direction of the screen is set. IBM’s Carbon Design System lists as conditions for using the type set for business screens (productive) that users are focused on completing a specific task, that there is a lot of interaction with inputs and forms, and that users stay on one screen for a long time, and it takes as its outcome metric the “time needed to complete a task and also the abandonment rate” (IBM Carbon n.d.-a). It then concludes that “space efficiency is key.” Once success is measured by task time, options with generous whitespace are at a disadvantage.

Devices and input methods are also decided before drawing. Fiori asks that cozy, which sizes controls to be pressed with a finger, be set app-wide on touch devices, and that compact, which shows more information, be set app-wide on mouse-and-keyboard devices (SAP n.d.). Control height is 3 rem in cozy and 2 rem in compact.

The screen type is derived from the content of the work. Fiori’s guidance on choosing a floorplan is written by purpose: Worklist for processing a defined set of items in turn, Wizard for creating or editing along a sequence of steps (SAP 2026). Wizard even comes with the conditions “Task is rather long or unfamiliar for users” and “Minimum of 3 steps, maximum of 8 steps.”

Sociomedia’s OOUI (object-oriented UI) does the same thing from the side of the work. It is a three-step procedure: extract the objects that appear in the work (customers, deals, invoices, and so on), next consider views and navigation, and finally apply layout patterns (Sociomedia 2020). The book’s introduction describes the shift from task orientation to object orientation as “also something that can be done half-mechanically.” However, what proceeds mechanically is the shift, and deciding the names of objects is not. Kota Fujii (藤井幸多), one of the authors, says that concepts that do not yet have words need names, and that he hesitates over the level of generalization (whether to call something a “briefing” or an “event”) (PERSOL CAREER 2025).

A time budget also reduces the options. Basecamp’s Shape Up distinguishes estimates from appetite (the time one is willing to spend on a piece of work) and writes, “Estimates start with a design and end with a number. Appetites start with a number and end with a design” (Singer n.d.-a). Once it is decided up front to spend only six weeks, options that cannot be built in six weeks are not drawn.

Some requirements are set from outside. For accessibility, W3C’s WCAG 2.2 and JIS X 8341-3:2016, which is based on WCAG 2.0, define success criteria (W3C n.d.; Japanese Standards Association 2016). In Japan, the amended Act for Eliminating Discrimination against Persons with Disabilities took effect on April 1, 2024, making the provision of reasonable accommodation by businesses mandatory (Cabinet Office n.d.). Options that fail these requirements drop out before any comparison.

Where, and how far, are options widened?

Even within the space narrowed by the preconditions, teams build several options instead of narrowing to one. ISO 9241-210 states that “The most appropriate design for an interactive system cannot typically be achieved without iteration” and asks that uncertainty be removed progressively through iteration (ISO 2019a, 5.5).

The UK government’s GOV.UK Service Manual calls the stage of widening and discarding alpha (GDS 2019). In alpha, teams build prototypes to try different ideas. Prototypes are kept “just complex enough to let you test different ideas,” and for the end of the phase the manual says, “Expect to throw away any code - and lots of the ideas you test.” The condition for moving on is that, at the end of alpha, the team is in a position to decide which of the ideas it tried will go forward to beta².

One of the few practice records that measured the effect of multiple options is a 1996 case from Nielsen Norman Group. Four designers created designs independently, and each design was evaluated by 10 test participants. The improvement from version 1 to version 2 was 18% with conventional iteration, which keeps revising a single design, and 70% with parallel design (Nielsen & Faber 1996). An article that re-read the same data reports that simply picking the best of the four designs scored 56% higher than the average of the original four, merging the good points of the losing designs into the best one scored 70% higher, and revising the merged design once more scored 152% higher (Fessenden 2024). The same article recommends at least three designs.

These numbers also show that narrowing is not the same as picking one. The gap between 56% and 70% is the contribution of the parts taken in from the designs not chosen. On the other hand, parallel design in this case cost 73% more than conventional iteration (Nielsen & Faber 1996). It is a single case, and the screens are from the 1990s.

At the widening stage, lowering fidelity is recommended. Shape Up uses breadboarding, which draws a screen with only places (destinations), affordances (things to press and input fields), and connection lines (links), and fat marker sketches drawn with a thick pen (Singer n.d.-b). The reason given is that starting from wireframes gets people stuck on unnecessary detail. At LayerX’s Bakuraku, usually, once the spec is set, engineers implement it with components and the designer adjusts layout and styling in code (Watanabe 2022). Only when the spec is complex, or when a new feature involves a lot of thinking, does the team prototype several options in Figma and settle the UI while discussing them as a team. The reason given is that making large layout changes after implementation is hard. How far to widen is varied by the complexity of the screen.

What are the remaining options compared on?

The core material for comparison is a test in which representative users perform representative tasks. ISO 9241-210 sets as a principle that design is driven and refined by evaluation with users, and holds that feedback from users in operation is also material for finding long-term problems and feeding them into the next design (ISO 2019a, 5.4). Nielsen recommends splitting research into three studies with five users each rather than running one large study (Nielsen 2000). With two user groups, that means 3 to 4 users per group; with three or more, 3 per group. In business apps, how these groups are divided becomes the issue.

In a business app, people who have just joined and people who have used it every day for years use the same screen. In a MeasuringU study, of the problems found by five novices and five experts, only half (24) were found by both; 16 were found only by novices and 8 only by experts (Sauro 2018). The product studied was a social media product, but the studies the same article relays include business software. In a timesheet app, novices deviated from the optimal path about three times as often as experts (66 versus 19), and with nurses’ electronic health records, novices ran into more serious problems (Faulkner & Wick 2005, Kjeldskov et al. 2005; relayed by Sauro 2018). The article concludes that testing should include both.

Experts carry another pitfall. NN/g’s guidelines for complex applications say that most users, left alone, do not become true experts and keep using a satisfactory (often inefficient) way of working (Kaplan 2020). That is why the second of its eight guidelines is “Help Users Adopt More Efficient Methods.” The design in which users do not get lost on first use and the design that is fast to use after six months are not necessarily the same. Accelerators such as shortcuts are placed where they can be found but do not get in novices’ way, classically shown next to commands in menus and toolbars (Laubheimer 2020). To measure learnability itself, NN/g recommends recruiting usually 30 to 40 or more participants and repeating trials until performance plateaus (Kendrick 2019).

The way of comparing changes before and after a design settles. NN/g holds that design critique belongs early, while a design can still change, and that independent evaluation through expert review or usability testing belongs after the design is stable and a high-fidelity prototype can be made (Harley 2018).

Numerical scales are better suited to checking against a benchmark than to finding problems. In MeasuringU’s 2025 study, the mean SUS of 23 business software products was 70.5, slightly above the mean of 68 across all products (Sauro & Lewis 2025). On the other hand, just detecting that a screen’s SUS differs from a benchmark by 5 points takes 58 participants (90% confidence) to 80 (95%), under a one-tailed test with 80% power (Lewis & Sauro 2022). By this calculation, it is hard to decide whether a design is good or bad against a numerical benchmark using SUS from tests with a few to a dozen or so participants. Small tests suit finding reasons to drop an option (serious problems), but rarely serve as grounds for choosing the final one.

Iteration continues after the choice. In Nielsen’s four cases from 1993, the median improvement from the first to the final version was 165%, or 38% per iteration, and he recommends at least three versions (Nielsen 1993). Some changes did not improve things. GOV.UK’s Service Standard also includes “Iterate and improve frequently” and “Define what success looks like and publish performance data” among its 14 points (GDS n.d.-a).

Who chooses the final one, and on what basis?

When two or three options remain that testing cannot eliminate, what decides? Laid side by side, the practical procedures agree on one point: a single decider is designated before the comparison.

Atlassian’s DACI divides the people involved in a decision into four roles (Atlassian n.d.). The Driver gathers stakeholders, assembles the material, and gets a decision made by the deadline; the Approver makes the decision; Contributors hold knowledge and make recommendations; and Informed are those affected by the decision and told after it is made. The Approver is “The one person (yes: one!) who makes the decision,” and of Contributors it says “they have a voice, but not a vote.” The last step is to record the decision and communicate it.

GV’s Design Sprint lines up options and chooses among them on Wednesday (Zeratsky 2016). Solutions are posted on the wall, each person silently places dot stickers on the parts they like, each solution is critiqued in three minutes, and each person casts one vote. The votes up to this point (the straw poll) are not binding. Finally, the Decider holds three large dot stickers, and the solution the Decider picks is prototyped and tested.

In Shape Up, the betting table decides what to build next every six weeks (Singer n.d.-c). At Basecamp it consists of four people, the CEO (who is the product’s final decision-maker), the CTO, a senior programmer, and a product strategist, and the text says, “There’s no ‘step two’ to validate the plan or get approval.”

IBM builds into the place of decision a procedure that shows whether there is agreement. Playbacks are divided into an early session that shares the Hills, a session that narrates the user’s end-to-end flow with medium-fidelity designs (Playback Zero), and a session that checks with the working product, and IBM writes, “Playbacks reveal alignment or misalignment on a team” (IBM n.d.). Of Sponsor Users, who bring actual users onto the team, it also writes, “Like any other team member, they don’t always get what they want.” Users’ voices are material for judgment, not decision rights.

So what does the decider rely on to choose? Des Traynor, co-founder of Intercom, describes product design principles as things that “help us make decisions when faced with competing options that seem valuable along different dimensions” (Traynor 2021). Naoyuki Miura (三浦尚之), a designer on Money Forward Cloud Accounting, set aside one hour a week with the PdM, laid out the current state and the ideal in a mind map, narrowed them down to five or six words, and turned these into four principles: “Appropriate operability,” “Guide clearly,” “Emphasize consistency,” and “Fact-based decision-making” (Miura 2022). He then calls the principles “a ‘yardstick’ for when we discuss” and writes, “This is not a rulebook.” A UX writer at SmartHR says that, when the design principles were made, they thought, “So it’s not rules like school regulations; it’s about conveying a philosophy, a way of thinking,” and goes on, “Unless we align our way of thinking, reproducibility won’t go up” and “When that skill is aligned, I think decisions come to align too” (SmartHR 2023). Principles are used to decide, between options that showed no difference in testing, which one is more like this product.

Some companies state outright that they do not decide by data. Linear’s Saarinen writes, “we don’t make decisions based on data or experiments—including A/B tests,” and says the company hires people who can make judgments based on expertise (Saarinen 2025). For a reason separate from the sample-size calculation in the previous section, this arrives at the same place: in the end, a person chooses.

In business apps, whose knowledge to gather before deciding also has its own circumstances. When deciding which features to put on the menu, RAKUS checked with and consulted the CS team, which supports a wide range of customers every day, and the PdM, who knows customer issues well (RAKUS 2025). NN/g writes that while in B2C one user researches, decides, buys, and uses, in B2B “each of these steps might involve different people and different departments” (Nielsen 2006). The person who uses the screen, the person who selects and buys the product, and the person who decides on adoption are different people.

How does a decision narrow the next one?

What is decided on one screen is recorded and becomes a precondition for the next screen. DACI includes recording the decision among its steps (Atlassian n.d.). In Cybozu’s kintone redesign, the team wrote component documentation with the goal that “‘why this component is used’ is unified from the design stage” (Cybozu 2022).

Some companies turn decisions into review items. SmartHR runs UI reviews for new apps and for medium-to-large feature development, checking the relevant items of its usability checklist and accessibility (SmartHR n.d.). Reviewers, one product designer and one accessibility specialist, are assigned at random and proceed asynchronously through Figma comments, and the page says, “it is desirable that there be one round of back-and-forth communication in response to each point raised.” Sansan’s Bill One joined every frontend pull request as a reviewer, commented, “This can be replaced with the design system’s XX component!”, and brought existing screens toward the design system (Sansan 2025).

Decisions accumulated this way become patterns like the floorplans at the start. The person responsible for the next screen starts not from a blank page but from patterns decided earlier. It can be read that options disappeared before being drawn because earlier decisions remained as patterns.

Where teams tend to hesitate on business apps

The issue that recurs most in records about business apps is information density. In Lightning Experience, Salesforce let each user choose a density in response to customer feedback (Salesforce 2018). It gives the reason as “Rather than compromising on “middle of the road” values that are not ideal for anyone, we are defining separate sets of optimized values.” The company says Compact has 30% higher information density than Comfy. Fiori, too, makes cozy the default on devices that support both touch and mouse, while letting users switch to compact if an administrator has enabled it (SAP n.d.). Carbon’s data table offers five row heights while asking that content be given enough width to display without truncation (IBM Carbon n.d.-b). Decisions to raise density also have a floor, just short of the point where things become unreadable.

Letting users choose in settings may look like postponing the decision. In fact, every example settles on one default. Intercom’s principle “Opinionated by default, flexible under the hood” shows the order: settle on one default, and leave room for change underneath (Traynor 2021).

A decision not to apply the principles of public-facing screens as-is to business screens used by staff is also on record. The GOV.UK Design System makes one question per page its basic pattern, and gives as the reason that users can understand what they are being asked and focus on that question and its answer (GDS n.d.-b). It then says that related questions may sometimes be grouped on one page, that user research decides this, and gives as an example “an internal service for government users who need to repeat and switch between tasks quickly.” Even within the same design system of the same organization, when the users and the frequency of use change, the default pattern changes.

The relationship with existing work is also a constraint that new products do not have. Mayumi Shinozaki (篠崎真由美), lead designer at PERSOL CAREER, said, “When an existing product is task-oriented, changing it to OOUI inevitably becomes difficult,” and noted that it becomes necessary to change not only the screens but the flow of the work itself (PERSOL CAREER 2025). On screens that people use every day, whether an option is good and whether it is acceptable to migrate to are asked separately.

The pattern from preconditions to decision

Where this account does not apply

Most of the material consists of makers describing their own procedures. Whether a UI decided by those procedures was better than a UI decided by other procedures has not been measured. The figures showing the effect of parallel design come from a single 1996 case, based on four designers and evaluation by 10 participants per design.

Settings such as contract development and system integration, where the client sets the spec and the contract fixes the scope of the screens, are barely covered. Articles on design for business systems from Fujitsu or NEC could not be reached. The Digital Agency Design System says it incorporates WCAG and similar guidelines to the fullest extent for government websites, online services, and the like, but no description of business systems for staff was found within what was checked (Digital Agency n.d.). Most of the ways of deciding covered here come from companies with their own products, where the decider is inside the company.

Academic literature was not collected systematically. Research on fixation on options and on people choosing among multiple generated options is in Asking an LLM for Design: Briefs, Skills, and a Process That Keep UIs from Converging on the Obvious and 探索としてのデザインと評価の社会学：機会の開閉をめぐる文献地図private, and ISO 9241-210 as an authority for the process is in Which standard can design and new-business work actually sit on?.

Finally, there remains the relationship between mechanisms that make one person the decider and the position of business app users. DACI’s Approver, the Sprint’s Decider, and the betting table are all people on the side that builds the product. In B2B, the people who use the screen all day are at the customer’s company, and are often present neither where the product is chosen nor where the UI is decided. Sponsor Users bring users closer to where decisions are made, but IBM itself writes that their voice does not always prevail. When people who do not use the screen make judgments on behalf of those who do, none of the materials read here answers what supports the correctness of those judgments.

Related notes

• Asking an LLM for Design: Briefs, Skills, and a Process That Keep UIs from Converging on the Obvious: divergence and convergence, and selection by a person, when having an LLM produce UI options
• A Genealogy of Practitioner Methods for Reframing Problems: Who Made Them, Traced to Their Origins: the lineage of practical methods that cycle divergence and convergence, such as Double Diamond and Design Sprint
• Which standard can design and new-business work actually sit on?: an account that uses ISO 9241-210 as the authority for the process
• Design System Best Practices: What the Evidence from Research and Practice Supports: evidence on design system operation and governance
• How Much of the Evidence for Adjudicating the Six Design System Conflicts Is in Place?: whether evidence exists to adjudicate points of contention in design systems
• 探索としてのデザインと評価の社会学：機会の開閉をめぐる文献地図private: a literature map of design as exploration and the sociology of evaluation

Unverified items

No main claim is unverified. The open items remaining in peripheral statements and in the ledger are listed below; details are in source/review/business-app-ui-decision/industry.md.

• The text of ISO 9241-210:2019 was checked in the standard’s public sample (from the foreword through 5.5). The text of each activity in Chapter 7 was not read. [要一次検証: 本文未到達 (full text not reached; public sample only)]
• ISO/IEC 25063, 25064, and 25066 were only confirmed to exist, along with their scope, on NIST’s description page; the text of the standards was not read. [要一次検証: 本文未到達 (full text not reached; iso.org returns 403 to WebFetch)]
• The figures from Faulkner & Wick (2005) and Kjeldskov et al. (2005) are relayed through MeasuringU’s summary; the original papers were not checked. [要一次検証: 本文未到達 (full text not reached; original papers, MeasuringU summary only)]
• How Salesforce calculated the “30% higher information density” is not stated in the article. [要確認: 記載なし (not stated; Salesforce 2018 text)]
• The description of Fiori’s cozy and compact was checked on the v1.38 version of the page. Whether the description has changed in the current version was not checked. [要確認: 未試行 (not attempted; comparison with the current version of the page)]
• The dates of the WCAG 2.2 Recommendation (first edition and revised edition) are not settled. [要確認: 記載なし (not stated; the first-edition date could not be identified on the relevant W3C page)]
• SmartHR’s UI review page, IBM Enterprise Design Thinking, Atlassian DACI, the chapters of Shape Up, and the Digital Agency Design System show no publication or revision date. [要確認: 記載なし (not stated; text of each page)]

References

Public bodies and standards organizations

• Government Digital Service (2019). How the alpha phase works. GOV.UK Service Manual. updated 2019-05-08. https://www.gov.uk/service-manual/agile-delivery/how-the-alpha-phase-works
• Government Digital Service (n.d.-a). The Service Standard. GOV.UK Service Manual. https://www.gov.uk/service-manual/service-standard
• Government Digital Service (n.d.-b). Question pages. GOV.UK Design System. https://design-system.service.gov.uk/patterns/question-pages/
• ISO (2019a). ISO 9241-210:2019 Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systems. https://www.iso.org/standard/77520.html
• ISO (2019b). ISO 9241-220:2019 Ergonomics of human-system interaction — Part 220: Processes for enabling, executing and assessing human-centred design within organizations. https://www.iso.org/standard/63462.html
• NIST (n.d.). Industry Usability Reporting. https://www.nist.gov/itl/tted/industry-usability-reporting
• W3C (n.d.). Web Content Accessibility Guidelines (WCAG) 2.2. W3C Recommendation. https://www.w3.org/TR/WCAG22/
• Digital Agency (デジタル庁) (n.d.). デザインシステムとは [What is a design system]. デジタル庁デザインシステムβ版 [Digital Agency Design System, beta]. https://design.digital.go.jp/dads/guidance/design-system/
• Cabinet Office (内閣府) (n.d.). 障害を理由とする差別の解消の推進 [Promoting the elimination of discrimination on the basis of disability]. https://www8.cao.go.jp/shougai/suishin/sabekai.html
• Japanese Standards Association (日本規格協会) (2016). JIS X 8341-3:2016 高齢者・障害者等配慮設計指針―情報通信における機器，ソフトウェア及びサービス―第3部：ウェブコンテンツ [Guidelines for older persons and persons with disabilities: Information and communications equipment, software and services, Part 3: Web content]. https://webdesk.jsa.or.jp/books/W11M0090/index/?bunsyo_id=JIS+X+8341-3:2016

Research firms and UX research companies

• Fessenden, T. (2024). 3 Design Processes for High Usability: Iterative Design, Parallel Design, and Competitive Testing. Nielsen Norman Group. 2024-12-03. https://www.nngroup.com/articles/parallel-and-iterative-design/
• Harley, A. (2018). UX Expert Reviews. Nielsen Norman Group. 2018-02-25. https://www.nngroup.com/articles/ux-expert-reviews/
• Kaplan, K. (2020). 8 Design Guidelines for Complex Applications. Nielsen Norman Group. 2020-11-08. https://www.nngroup.com/articles/complex-application-design/
• Kendrick, A. (2019). How to Measure Learnability of a User Interface. Nielsen Norman Group. 2019-10-20. https://www.nngroup.com/articles/measure-learnability/
• Laubheimer, P. (2020). Flexibility and Efficiency of Use (Usability Heuristic #7). Nielsen Norman Group. 2020-11-22. https://www.nngroup.com/articles/flexibility-efficiency-heuristic/
• Lewis, J., & Sauro, J. (2022). Sample Sizes for Comparing SUS to a Benchmark. MeasuringU. 2022-03-01. https://measuringu.com/sample-sizes-for-sus-benchmark-tests/
• Nielsen, J. (1993). Iterative User Interface Design. Nielsen Norman Group. 1993-11-01. https://www.nngroup.com/articles/iterative-design/
• Nielsen, J. (2000). Why You Only Need to Test with 5 Users. Nielsen Norman Group. 2000-03-18. https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/
• Nielsen, J. (2006). B2B Usability. Nielsen Norman Group. 2006-05-31. https://www.nngroup.com/articles/b2b-usability/
• Nielsen, J., & Faber, J. M. (1996). Improving System Usability Through Parallel Design. Nielsen Norman Group. 1996-02-01. https://www.nngroup.com/articles/parallel-design/
• Sauro, J. (2018). Do Novices or Experts Uncover More Usability Issues? MeasuringU. 2018-02-28. https://measuringu.com/novice-expert-issues/
• Sauro, J., & Lewis, J. (2025). Business Software UX & NPS Benchmarks (2025). MeasuringU. 2025-03-18. https://measuringu.com/business-software-ux-2025/

Enterprise design systems and product teams

• Atlassian (n.d.). DACI: A Decision-Making Framework. Atlassian Team Playbook. https://www.atlassian.com/team-playbook/plays/daci
• IBM (n.d.). Enterprise Design Thinking Framework. https://www.ibm.com/training/enterprise-design-thinking/framework
• IBM Carbon Design System (n.d.-a). Typography: Style strategies. https://carbondesignsystem.com/elements/typography/style-strategies/
• IBM Carbon Design System (n.d.-b). Data table: Usage. https://carbondesignsystem.com/components/data-table/usage/
• Saarinen, K. (2025). Karri Saarinen’s 10 rules for crafting products that stand out. Figma Blog. 2025-03-18. https://www.figma.com/blog/karri-saarinens-10-rules-for-crafting-products-that-stand-out/
• Salesforce (2018). New Density Settings for the Lightning Experience UI in Winter ‘19. Salesforce Developers Blog. 2018-08-08. https://developer.salesforce.com/blogs/2018/08/new-density-settings-for-the-lightning-experience-ui-in-winter-19
• SAP (n.d.). Content Density (Cozy and Compact). SAP Fiori Design Guidelines, v1.38. https://www.sap.com/design-system/fiori-design-web/v1-38/foundations/visual/cozy-compact
• SAP (2026). When to Use Which Floorplan. SAP Fiori Design Guidelines, v1.136. updated 2026-09-23. https://www.sap.com/design-system/fiori-design-web/v1-136/page-types/floorplans/when-to-use-which-floorplan
• Singer, R. (n.d.-a). Set Boundaries. Shape Up, Chapter 3. Basecamp. https://basecamp.com/shapeup/1.2-chapter-03
• Singer, R. (n.d.-b). Find the Elements. Shape Up, Chapter 4. Basecamp. https://basecamp.com/shapeup/1.3-chapter-04
• Singer, R. (n.d.-c). The Betting Table. Shape Up, Chapter 8. Basecamp. https://basecamp.com/shapeup/2.2-chapter-08
• Traynor, D. (2021). Foundations to build on: Intercom’s principles for building product. Intercom Blog. 2021-10-20. https://www.intercom.com/blog/intercom-product-principles/
• Zeratsky, J. (2016). Sprint: Wednesday. 2016-04-19. https://www.johnzeratsky.com/p/sprint-week-wednesday-900fe3f2c26e

Japanese business SaaS teams and practitioners

• Cybozu (sakito) (2022). ユーザー体験を最高にするkintone Design Systemsをつくってます [We are building kintone Design Systems to make the user experience the best it can be]. Cybozu Inside Out. 2022-03-16. https://blog.cybozu.io/entry/2022/03/16/141935
• Sansan (Egawa, 江川) (2025). Vol. 16 Bill Oneにおけるデザインシステムの取り組みの現在地 [Vol. 16: Where Bill One’s design system efforts stand now]. Builders Box. 2025-01-27. https://buildersbox.corp-sansan.com/entry/2025/01/27/130000
• SmartHR (n.d.). UIレビュー [UI review]. SmartHR Design System (Usability). https://smarthr.design/products/design-review/ui-review/
• SmartHR (2023). 「ちいさくはじめるデザインシステム」著者対談 〜同期入社の2人のこれまでとこれから〜 [A conversation between the authors of “Starting a Design System Small”: two colleagues who joined the company at the same time, on their past and future]. SmartHR Tech Blog. 2023-03-30. https://tech.smarthr.jp/entry/2023/03/30/120000
• Sociomedia (Manabu Ueno 上野学 and Kota Fujii 藤井幸多) (2020). オブジェクト指向UIデザイン：使いやすいソフトウェアの原理 [Object-oriented UI design: Principles of usable software]. 技術評論社 (Gijutsu-Hyoronsha). 2020-06-05. ISBN 978-4297113513. https://www.sociomedia.co.jp/10046
• PERSOL CAREER (パーソルキャリア) (2025). 【ソシオメディア×パーソルキャリア】実践から考える OOUI と生成 AI の未来 [Sociomedia x PERSOL CAREER: The future of OOUI and generative AI, considered from practice]. techtekt. 2025-09-25. https://techtekt.persol-career.co.jp/entry/culture/250925_01
• Miura, N. (三浦尚之) (2022). マネーフォワード クラウド会計のデザイン原則をPdMと作った話 [How we made the design principles for Money Forward Cloud Accounting with the PdM]. note. 2022-05-10. https://note.com/3ura_n/n/n7dd846933d1e
• RAKUS (Aoyagi, 青柳) (2025). UIを変えたら、プロダクトもチームも、動き出した [When we changed the UI, both the product and the team started moving]. RAKUS Developers Blog. 2025-06-20. https://tech-blog.rakus.co.jp/entry/20250620/uiux
• Watanabe, N. (わたなべなつき) (2022). 入社3ヶ月目のデザイナーから見たLayerXのデザインプロセス [LayerX’s design process as seen by a designer three months after joining]. LayerX エンジニアブログ [LayerX Engineering Blog]. 2022-06-24. https://tech.layerx.co.jp/entry/2022/06/24/092727

All sources accessed 2026-09-25.

Footnotes

1. Sources were divided into three tiers: public bodies and standards organizations (T1), the factual parts of research firms and UX research companies (T2), and testimony from the makers of the products themselves (T3, developer-voice). Academic literature was not collected systematically; only where a research firm relays it is the original source named. The ledger is at source/review/business-app-ui-decision/industry.md. ↩

2. Design Council’s Double Diamond, which repeats divergence and convergence twice, and the lineage of GV’s Design Sprint are covered in A Genealogy of Practitioner Methods for Reframing Problems: Who Made Them, Traced to Their Origins. Design Council is now an independent charity, not a government body. ↩