Early-stage founders commonly move too quickly from noticing a problem to committing to their first solution. This creates a solution-first bias: effort is spent refining features before the customer, context and underlying problem have been understood. This article develops an academically grounded design for a standalone Validation & Delivery Builder within Dhruvi Infinity. The proposed application combines Design Thinking, the Double Diamond, structured business ideation, MoSCoW prioritisation, Lean Startup experimentation and an evidence-controlled delivery gate. A conversational artificial intelligence assistant helps founders articulate observations, assumptions, alternative concepts and test plans, while deterministic server rules and explicit founder confirmation retain authority over creation, evidence, decisions and approval. The design therefore treats AI as a facilitator rather than an autonomous entrepreneur. The article also proposes a source-provenance model, database-backed learning guidance, contextual assistance, accessible dynamic interaction and immutable validation history. Alignment is examined against ISO 9241-210:2019 for human-centred design, ISO 56002:2019 for innovation management and ISO/IEC 42001:2023 for AI governance. The central argument is that Design Thinking should not become another isolated framework in the application. It should supply the missing discovery and divergence layer before the existing Validation & Delivery workspace converges through prioritisation, experiments, evidence, decisions and a delivery brief. This architecture can reduce premature commitment and improve learning quality, but it cannot itself prove demand or commercial viability. Those claims still require genuine external evidence.
Keywords: business ideation; Design Thinking; Double Diamond; human-centred design; startup validation; generative AI; evidence provenance; MoSCoW; ISO 9241-210; innovation management.
Referencing note: The author-date citations and alphabetical reference list follow Brookes Harvard, which Oxford Brookes University identifies as equivalent to Cite Them Right Harvard (Oxford Brookes University, n.d.).
Source: Author's original diagram, synthesised from the sources cited in the surrounding discussion.
1. Introduction: the gap between having an idea and knowing what to build
Business ideation is often presented as a moment of inspiration. In practice, venture creation is a sequence of uncertain judgements about people, problems, markets, technologies and organisational capacity. A founder may begin with an attractive product concept, but the existence of a concept does not demonstrate that a sufficiently important problem exists, that the proposed users experience it as expected, or that they will change behaviour and pay for a solution. The central design challenge is therefore not simply to help a user describe an idea. It is to help that user transform an initially uncertain belief into an evidence-backed proposition without destroying the creative flexibility that makes innovation possible.
Dhruvi Infinity already contains a substantial Validation & Delivery workspace. Its capabilities include a reviewed problem statement, target-user context, MoSCoW scope prioritisation, versioned validation cycles, evidence records, explicit decisions, delivery briefs, milestones and a server-owned readiness gate. The proposed expansion adds a standalone product entrance for someone who does not yet have a BusinessIdea record. The founder talks with an assistant in a conversational interface, the application gathers a minimum set of information, the founder reviews what has been understood, and exactly one BusinessIdea is created before the user continues into the existing workspace. The product also adds contextual tutorials, information icons, larger editable fields, field-aware AI actions, global search integration and dynamic JavaScript interactions.
The danger is that a conversational intake can become a friendly form that merely legitimises the first idea. Brown (2008) popularised Design Thinking as a human-centred approach to products, services and strategy, but later research has warned that the term is interpreted inconsistently and can collapse into a superficial sequence of workshop activities (Johansson-Sköldberg, Woodilla and Çetinkaya, 2013; Micheli et al., 2019). The correct response is not to reject Design Thinking. It is to define precisely what work it performs in this application.
This article argues that Design Thinking should provide the upstream discovery, problem-framing and divergent-ideation logic. The existing Validation & Delivery domain should remain the downstream system for prioritisation, experiments, evidence, decisions and delivery preparation. The two should be connected through one traceable journey, not implemented as parallel frameworks with duplicated data. This interpretation reflects the Design Council's Double Diamond: Discover and Define broaden and then focus understanding of the problem; Develop and Deliver broaden and then focus potential responses through small-scale testing (Design Council, n.d.). Stanford d.school's Empathize, Define, Ideate, Prototype and Test modes provide founder-friendly teaching language, while its card-based presentation emphasises methods that may be revisited rather than a rigid waterfall (Stanford d.school, n.d.).
The resulting proposition is an AI-assisted learning system with human authority. The assistant can ask questions, extract tentative facts, identify contradictions, reframe a problem, generate alternatives and suggest test methods. It must not invent customer evidence, convert a synthetic persona into research, select the winning concept, record an experiment as successful, make the founder's decision or approve delivery. This boundary is essential academically and operationally: the application should accelerate thought and documentation, not manufacture certainty.
2. Academic foundations for a human-centred ideation system
2.1 Design problems are framed, not merely received
Many business problems are ill-structured. Their goals, constraints and relevant stakeholders are not fully known at the beginning, and changing the proposed solution can change how the problem itself is understood. Buchanan (1992) connected design thinking with “wicked” problems: situations in which problem formulation and resolution cannot be cleanly separated. Dorst (2011) similarly identifies frame creation as a core design practice. Instead of accepting the founder's statement “customers need my app”, the system should ask what people are currently trying to achieve, what happens in the relevant context, which workaround they use, what is observed and what is assumed. A user-centred problem frame may then be proposed for review.
This matters because a polished description can hide a weak frame. For example, “students need an AI business-plan generator” starts with a technology and output. A stronger frame might be: “time-poor novice founders struggle to convert fragmented customer observations into testable assumptions and do not know which uncertainty to address first.” The second formulation admits multiple responses: guided research, a decision aid, facilitated workshops, a checklist, a concierge service or an AI-supported workspace. It creates room for innovation rather than prescribing one interface.
Carlgren, Rauth and Elmquist (2016a) identify five themes across organisational uses of Design Thinking: user focus, problem framing, visualisation, experimentation and diversity. These themes are more useful for product architecture than treating five named stages as boxes to tick. Dhruvi Infinity can operationalise them through data and interaction: user-focus fields, versioned problem frames, visual journey maps, alternative-concept cards, small-test plans and explicit provenance. Design Thinking becomes observable behaviour inside the application rather than a label attached to ordinary form completion.
2.2 Divergence before convergence
The proposed intake should deliberately separate idea generation from idea selection. Girotra, Terwiesch and Ulrich (2010) found that a hybrid structure, in which people first generate ideas independently and then work collectively, produced more and better ideas and improved the ability to identify quality compared with group-only work. Although a solo founder using AI is not equivalent to the experimental groups in that study, the finding supports a product principle: preserve an independent founder concept, invite additional alternatives, and compare them only after a short divergent period. If the AI immediately edits the first concept, it may increase fluency without increasing conceptual variety.
The application should therefore request or generate several materially different concepts when credible. A marketplace, an advisory service, a workflow tool and an educational programme are distinct concepts; three differently worded chatbots are not. The system can compare alternatives across desirability, feasibility, viability, evidence strength, resource constraints and learning value. These criteria should organise discussion rather than produce a false mathematical winner. The founder remains responsible for selection and rationale. Where only one concept is possible because of regulation, contractual scope, an existing asset or another genuine constraint, the user should be permitted to continue but should explicitly record the reason. This creates useful audit information without turning ideation into bureaucracy.
Liedtka (2015) argues that Design Thinking practices may improve innovation outcomes by reducing cognitive biases. Perspective taking can challenge egocentric projection; multiple options can reduce attachment to an initial answer; prototypes can make abstract beliefs testable; and structured feedback can confront confirmation bias. These benefits are plausible mechanisms, not a guarantee of success. The product should consequently make uncertainty visible. Completion should mean that a required question has been answered and reviewed, not that the underlying business claim has become true.
Figure 2. Divergence before convergence and MoSCoW
Source: Author's original diagram, synthesised from the sources cited in the surrounding discussion.
2.3 From design exploration to scientific learning
Design Thinking alone is insufficient for venture validation. Johansson-Sköldberg, Woodilla and Çetinkaya (2013) criticise managerial versions that are weakly connected to deeper design research, while Micheli et al. (2019) note major disagreements about Design Thinking's attributes, applications and outcomes. Carlgren, Elmquist and Rauth (2016b) also report implementation challenges in experienced firms. A colourful workshop can create enthusiasm while leaving market, price, adoption and operational assumptions untested.
Lean Startup addresses a different part of the uncertainty. Ries (2011) emphasises validated learning through rapid experiments and iterative product development, while Blank (2013) contrasts searching for a business model with executing a fixed plan. More importantly, Camuffo et al. (2020) provide experimental evidence from 116 Italian startups: entrepreneurs trained to formulate predictions and test hypotheses were more precise in deciding whether to persist or pivot than those relying on more intuitive approaches. The implication for Dhruvi Infinity is that a validation cycle should require an explicit hypothesis, metric and minimum threshold before evidence is collected. Otherwise, a founder can reinterpret any result as support.
The Design Thinking and Lean perspectives are therefore complementary. Design Thinking broadens understanding and creates alternative frames and concepts. Experimental validation narrows uncertainty by confronting a selected assumption with observable results. The existing Proceed, Revise, Pause and Reject decisions then transform evidence into accountable action. Rejection is not system failure; it is a successful prevention of unjustified investment.
2.4 MoSCoW belongs after concept selection
MoSCoW classifies scope as Must Have, Should Have, Could Have and Won't Have this time. The Agile Business Consortium (2026) describes it as a means of managing priority and expectations within a timeframe, with Must Haves forming the minimum usable subset. In the current workspace, MoSCoW is valuable because it constrains the solution concept and identifies the smallest credible scope for testing or delivery.
However, prioritising features before selecting and framing a concept creates false precision. It can lead founders to debate whether a dashboard is a Must Have while still lacking evidence that the underlying user problem matters. The proposed sequence is therefore: understand people; frame the problem; generate alternatives; select a provisional concept; then apply MoSCoW to that concept. “Must Have” should mean essential to the experiment or viable outcome in the defined timeframe, not “the founder likes it most”. This ordering connects creative divergence to disciplined convergence.
3. The integrated product journey
3.1 Discover people: evidence before persona theatre
The first conversational phase should gather who experiences the situation, when and where it occurs, what people currently do, what outcome they seek and what source supports each claim. This is consistent with the Double Diamond's Discover phase, which begins by understanding rather than assuming the problem (Design Council, n.d.). Questions should adapt to information already present in the founder's answers or an existing BusinessIdea. Repetition is not merely annoying; it signals that the assistant is processing text rather than maintaining a coherent model.
The product must distinguish genuine user research from plausible storytelling. An AI-generated persona can help a founder consider questions, but it is not an interview participant. A generated quotation is never an observation. If no research exists, “no evidence yet” is an honest and useful state. The assistant can recommend an interview, observation, landing-page test or review of support data, but the user must supply the resulting evidence and provenance.
The live information panel should therefore group facts by status. A founder-confirmed description of the target segment is different from a direct observation, and both differ from an AI suggestion. The interface may show a gentle confidence cue, but it should avoid an opaque confidence score that suggests statistical validity. The purpose is epistemic clarity: readers should know why a statement is present and who is responsible for it.
3.2 Define the problem: synthesis with founder confirmation
During Define, the assistant synthesises the confirmed material into a concise problem statement containing the user, context, difficulty, existing behaviour, desired progress and relevant constraint. It also highlights contradictions—for example, describing the customer as a low-income student while proposing a high-price enterprise subscription. The founder can edit or reject the synthesis. Only explicit confirmation makes it the reviewed problem frame used downstream.
The distinction between extraction and confirmation is crucial. Large language models can summarise a conversation, but their output may omit a qualification or overstate what a user meant. A deterministic server policy should decide whether the required fields exist, while the founder decides whether the content is accurate. The assistant can say “I believe I have enough information to prepare a review”; it should not autonomously create a BusinessIdea.
3.3 Develop: create and compare alternative concepts
The Develop phase displays the founder's original concept alongside additional alternatives. Each concept should state the mechanism, intended user, value proposition, key dependency and fastest learning method. The AI may help extend the option space, but the founder can add, merge, reject or rewrite concepts. The comparison view should reveal trade-offs rather than hide them behind a single score.
For example, an automated SaaS product may offer scale but require costly integration; a concierge service may be less scalable but learn faster; a template product may launch cheaply but deliver less differentiation. Selection criteria can be weighted conversationally, yet the saved record should preserve the reasons and constraints, not only a numerical total. This provides a defensible explanation if later evidence causes the founder to revisit a previously rejected option.
3.4 Prepare to learn: prototype and hand-off
Once the founder selects a provisional concept, the assistant helps identify the riskiest assumption and proposes the smallest ethical test. Stanford d.school's no-build approach emphasises learning without constructing the full product (Stanford d.school, 2018). Suitable methods include a paper prototype, clickable mock-up, concierge workflow, simulation, pilot, pre-order page or manual service. The choice depends on the claim. A usability prototype may test comprehension but cannot demonstrate willingness to pay; a sign-up page may test expressed interest but not long-term retention.
At review readiness, the founder sees the extracted facts, provenance, alternative concepts, selection rationale, riskiest assumption and proposed first test. The user can edit any item and then select Create business idea. A transaction creates exactly one BusinessIdea and the initial Validation & Delivery workspace, using idempotency to prevent duplicates. The new idea receives a clear Validation & Delivery origin badge while retaining a separate planning-framework label where relevant. Design Thinking is the intake method, not a fifth builder framework.
Figure 3. Conversational intake phases and creation gate
Source: Author's original diagram, synthesised from the sources cited in the surrounding discussion.
3.5 Continue through evidence-based delivery
The canonical workspace then presents an end-to-end journey: Discover, Define, Develop, Prototype/Test, Decide and Deliver. The first three phases can display the reviewed intake summary rather than asking the user to enter the same information again. Existing ideas entering through the ordinary per-idea link should remain supported. For those ideas, the journey begins with “review discovery assumptions” rather than falsely marking research complete.
The workspace turns the selected concept into ordered scope, validation cycles and evidence. Each cycle records the assumption, hypothesis, participant or sample plan, prototype or test method, metric, threshold, observations, interpretation and learning. Completed cycles are immutable. Imported evidence remains unconfirmed until the founder explicitly verifies its source. Decisions are recorded as Proceed, Revise, Pause or Reject, and a revision creates a new version rather than rewriting history. A delivery brief then captures scope, exclusions, risks, dependencies, success metrics and milestones. Approval is possible only when server-owned readiness rules are satisfied; later source changes mark the approved brief as stale without altering its historical snapshot.
This continuity is academically important. Design Thinking's iteration becomes an auditable learning path rather than an endless loop with no decision consequences. The founder can return to Define or Develop after contradictory evidence, but the application retains what was believed, tested and decided at each point.
4. Conversational AI as facilitator rather than decision-maker
4.1 The appropriate role of AI
A conversational interface can reduce the cognitive burden of a complex methodology. Instead of confronting the founder with a dense form, it asks the single most valuable next question, explains why it matters and updates a visible checklist. It can recognise information supplied in an unusual order and avoid asking again. It can also offer examples at the exact field where the user is working.
The assistant is particularly useful for transformation tasks: converting a narrative into tentative structured facts, identifying an ambiguous customer definition, proposing a clearer hypothesis, generating concept alternatives or suggesting an appropriate metric. These are advisory acts. Consequential acts remain outside its authority. The AI must not fabricate evidence, confirm an imported source, record an experimental outcome, select the concept, make the final validation decision, approve a brief or mark the workspace ready.
This allocation addresses automation bias and generative-AI risk. NIST's Generative AI Profile treats trustworthiness as a lifecycle concern requiring structured risk management (Autio et al., 2024). ISO/IEC 42001 similarly frames responsible AI through an organisational management system concerned with risks, opportunities, transparency, traceability and continual improvement (ISO/IEC, 2023). Dhruvi Infinity does not need to claim conformity to apply these principles. It can document the assistant's intended purpose, allowed actions, prohibited actions, evaluation results, incident handling and human oversight.
4.2 Stable context and preview-before-apply
Every meaningful form and field should have a stable identifier, form identifier, phase, section, record version and help key. When the founder invokes “Explain”, “Reframe”, “Expand”, “Challenge assumptions”, “Generate alternatives” or “Suggest a metric”, the assistant receives this bounded context. It should not guess which field is active from the entire page.
Generated text appears in a preview or difference view with Insert, Replace, Append, Copy and Discard controls. Nothing changes until the founder explicitly applies it through the normal authorised endpoint. Optimistic locking prevents a stale AI response from overwriting a newer edit. The UI should ignore late network responses when the user has moved to another field, and all accepted content should follow the same audit and authorisation rules as manual editing.
This design follows a basic human-centred principle: system behaviour should remain understandable and controllable. It also makes AI use academically inspectable. Researchers or product owners can measure which actions were requested, which suggestions were accepted, how much founders edited them and where errors occurred without exposing private prompts or provider internals.
Figure 4. Human, AI and system responsibility boundary
Source: Author's original diagram, synthesised from the sources cited in the surrounding discussion.
4.3 Deterministic completeness behind probabilistic language
The language model may identify that a message appears to contain a target user, problem or constraint. However, the definition of “enough information” should be a versioned server-owned registry. Each requirement has a stable key, a rationale, accepted provenance classes and a deterministic satisfied/missing state. AI extraction proposes candidate values; the founder confirms content; the policy determines readiness.
This hybrid approach avoids two extremes. A static questionnaire is predictable but insensitive to context. An unconstrained AI interview is flexible but may repeat questions, omit requirements or declare completion inconsistently. Combining probabilistic extraction with deterministic policy provides conversational adaptability while preserving testability and accountability.
5. Evidence provenance and knowledge integrity
5.1 Four classes of knowledge
The application should store at least four knowledge classes: observed evidence, founder assumption, AI suggestion and founder-confirmed fact. These are not levels on a simple quality ladder. A founder-confirmed fact means the founder agrees that the statement represents their position; it does not mean the market claim is objectively true. An observation may be genuine but drawn from a tiny or biased sample. An AI suggestion may be useful while remaining unverified.
W3C's PROV Data Model defines provenance in terms of entities, activities and agents involved in producing information, enabling assessments of quality, reliability and trustworthiness (W3C, 2013). Dhruvi Infinity need not implement the entire standard to adopt its logic. Each important claim can record who or what produced it, when, through which activity, from which source and whether another entity was derived from it. A problem frame derived from three observations and two assumptions should retain those links.
For user-supplied evidence, the system can record source type, date, URL or attachment, author or participant pseudonym, collection method and founder confirmation. Sensitive personal data should be minimised. Interview notes should use consent and anonymisation appropriate to the context; the application should not encourage founders to upload unnecessary personal identifiers.
Figure 5. Evidence provenance model
Source: Author's original diagram, synthesised from the sources cited in the surrounding discussion.
5.2 Evidence must be designed before it is interpreted
The validation form should separate the test plan from the result. The founder states the hypothesis, metric and pass threshold before running the experiment. This reduces hindsight reinterpretation. When results are entered, observations are kept separate from interpretation and learning. For example, “18 of 100 visitors submitted an email” is an observation; “customers value the proposition” is an interpretation whose strength depends on the sample, traffic source, page design and threshold.
The decision record should cite the evidence used and explain why it supports Proceed, Revise, Pause or Reject. The application can flag inconsistency—such as proceeding after a pre-defined threshold failed—but it must not block a justified decision if the founder records the rationale. Good governance makes exceptions visible rather than pretending they never occur.
5.3 Immutable history and truthful staleness
Completed validation cycles, final decisions and approved delivery briefs should be immutable snapshots. New learning creates a new version. This preserves the sequence from belief to test to evidence to decision and protects against retrospective editing. If the underlying problem, target users, solution scope, evidence or milestones change after brief approval, a source digest can mark the brief stale. Staleness does not erase or mutate the approved document; it signals that the historical approval no longer represents the current source state.
This is more than a technical integrity feature. It teaches founders that knowledge is time-bound. A decision may have been reasonable using the evidence available in one cycle and inappropriate after later learning. Versioned history supports reflection, supervision, due diligence and organisational memory.
6. Learning experience, interface design and system architecture
6.1 A journey map that explains order and purpose
The existing blank Validate phase can confuse a novice because “Create a validation cycle” does not explain what to do first. A persistent journey map should display Discover, Define, Develop, Prototype/Test, Decide and Deliver, with expandable actionable steps. Each step shows why it matters, current state, missing prerequisite and one recommended next action. The map should guide rather than falsely lock useful review areas.
The first validation cycle can be offered as a resumable wizard: choose the riskiest assumption; write a falsifiable hypothesis; define users and sample; select a prototype or test; set metric and threshold; state timeline and evidence-collection plan; review. Experienced users retain access to the complete form. This progressive disclosure supports novices without constraining experts.
6.2 Database-backed guidance as part of the product
Information icons should open substantial field-specific guidance rather than generic tooltips. Each guide can include a learning objective, explanation, why the field matters, method, template, example, evidence expectations, common mistakes, related sections, source links and suggested AI prompts. A wide accessible off-canvas panel allows the founder to read without losing the active workspace. “Ask AI about this” transfers the exact phase, field and help key to the assistant.
The guidance should be database-backed, versioned and editable by a superuser through a controlled publishing workflow. This makes the product maintainable as pedagogy and practice evolve. Draft content is hidden from ordinary users; published content overrides static fallback; missing help keys appear in an administrative coverage audit. Because guidance can influence consequential decisions, revision history and source attribution are as important as visual editing.
6.3 Desktop-like dynamics with server authority
Purposeful JavaScript can make the Rails application feel like a local desktop workspace: auto-growing text areas, conflict-safe autosave, live readiness refresh, keyboard navigation, message retry, concept-card comparison, off-canvas tutorials, preview-before-apply AI drafts and offline recovery. Long-form fields should begin at a useful height and grow until a sensible viewport cap, avoiding the narrow internal scrolling shown in the original interface.
Dynamic behaviour must not move authority into the browser. The database remains canonical; every write is authorised; related requests are serialised; stale responses are cancelled; optimistic updates have rollback; and conflicts produce an explicit HTTP 409 experience. Sensitive founder content should not be stored as the only copy in local storage. Reduced-motion preferences, focus management, Escape handling, readable labels and keyboard operation should be tested. W3C's Web Content Accessibility Guidelines 2.2 provide a relevant baseline for perceivable, operable, understandable and robust interaction (W3C, 2023).
6.4 One connected information architecture
The standalone product should add a second entrance, not duplicate the existing domain. The intake session stores messages, extracted facts, provenance and concept alternatives. Founder confirmation creates one BusinessIdea. That record owns or connects to the existing ValidationDelivery workspace. SearchResource registers the public product and terms including Design Thinking, problem framing, prototype, validation, evidence, MoSCoW and delivery readiness. WorkflowHelp owns published learning content. Stable field metadata connects workspace controls to help and AI actions.
This separation creates clear ownership: intake is resumable conversation state; BusinessIdea is the canonical venture record; ValidationDelivery owns experiments and delivery artefacts; WorkflowHelp owns pedagogy; SearchResource owns discovery. It also avoids contaminating the Innovator Founder Visa workflow or overloading the four existing planning-framework values.
Figure 6. One connected product architecture
Source: Author's original diagram, synthesised from the sources cited in the surrounding discussion.
7. ISO alignment and responsible governance
7.1 ISO 9241-210: human-centred design throughout the lifecycle
ISO 9241-210:2019 provides requirements and recommendations for human-centred design activities throughout the lifecycle of interactive systems (ISO, 2019a). For this product, alignment means more than adding a customer-persona field. The design should be based on explicit understanding of users, tasks and environments; founders and representative users should be involved in evaluation; designs should be iterated using user-centred evidence; the whole experience should be considered; and relevant disciplines should contribute.
Practical evidence of alignment would include research with novice and experienced founders, observation of where they misunderstand evidence or readiness, accessible prototypes tested across device sizes, task-completion data and documented iteration. The contextual help editor should be tested with the people who must maintain it, not only the founders who read it. Likewise, superuser workflows, conflict recovery and print/PDF output form part of the total experience.
The application should describe this as “designed with reference to ISO 9241-210” unless a formal conformance assessment has been completed. A product team cannot infer certification from incorporating several good practices.
7.2 ISO 56002: an innovation-management system perspective
ISO 56002:2019 offers guidance for establishing, implementing, maintaining and continually improving an innovation management system. It is intentionally generic and applies to different organisation types, innovation types and approaches, including startups and design-driven innovation (ISO, 2019b). Dhruvi Infinity can operationalise part of this logic by connecting opportunity discovery, concept development, experiments, decisions, milestones and review.
The most useful contribution is management discipline. Innovation is not a one-off creative event: it requires context, leadership, resources, knowledge, measurement and improvement. The application's immutable histories, evidence links, readiness rules and guidance revisions create management information. Aggregated carefully, they can show where founders repeatedly stall, which help content is ineffective, how long validation cycles take and whether decisions are supported by pre-defined evidence. Private venture data should not be exposed or combined without a legitimate basis.
ISO 56002 does not prescribe Design Thinking, MoSCoW or the exact validation workflow. Therefore, the standard should be treated as an organising reference, while the application's methods remain explicit design choices requiring their own evaluation.
7.3 ISO/IEC 42001: governance of the AI assistant
ISO/IEC 42001:2023 specifies requirements for an Artificial Intelligence Management System and uses a continual-improvement approach to AI risks and opportunities (ISO/IEC, 2023). Applied proportionately, it suggests several controls for the assistant: documented intended use; defined human oversight; data and privacy rules; evaluation of extraction and suggestion quality; model/provider change management; logging that avoids raw sensitive content; incident and complaint handling; and periodic review of risk.
The field-action matrix provides a practical control surface. Low-consequence actions such as explanation and examples can be widely available. Drafting and reframing require preview. Evidence, final concept selection, decisions, brief approval and readiness are prohibited AI writes. Quotas control cost and abuse but are not a substitute for governance. Tests should use deterministic stubs rather than live provider calls, and the user interface should not expose raw prompts, token counts or internal model details.
Figure 7. Complementary ISO governance lenses
Source: Author's original diagram, synthesised from the sources cited in the surrounding discussion.
7.4 Standards as sources, not marketing badges
Standards add value when they influence verifiable work. Each claimed alignment should link to a requirement, design control and evidence artefact. For example, “iterative human-centred evaluation” links to moderated founder tests and recorded revisions; “AI traceability” links to action type, context, generated draft, user disposition and model-policy version; “continual improvement” links to review metrics and corrective actions.
This source-conscious approach prevents standards theatre. The public product page can explain that the workflow is informed by recognised human-centred, innovation and AI-management principles, but it should not display certification marks or claim compliance unless independently justified.
8. Critical limitations and evaluation strategy
8.1 Design Thinking can still become ritual
Adding phase labels does not guarantee empathy, creativity or learning. Founders may complete an interview field without speaking to anyone, generate alternatives only to satisfy the system, or choose the original concept regardless of comparison. AI may make weak content appear professional and thereby increase overconfidence. Design Thinking can also privilege immediately visible user preferences while underweighting regulation, technical architecture, ecological impact, business economics or non-user stakeholders.
The product should counter these risks through provenance, examples of weak and strong evidence, explicit “no evidence yet” states, contradiction prompts and small external tests. Yet it must preserve founder agency. Excessive gates can turn learning into compliance and discourage experimentation. A single-concept exception, editable outputs and transparent readiness rules provide necessary flexibility.
8.2 Validation evidence has scope limits
A prototype test answers only the question it was designed to answer. Five positive usability sessions do not establish a large market. Landing-page conversion does not guarantee retention. Interview enthusiasm does not equal payment. Evidence records should therefore state claim type, method, sample, limitations and applicable decision. The assistant can challenge overgeneralisation, but only the founder and reviewers can judge whether the evidence is adequate for the level of commitment.
Commercial validation should eventually include market size, competitor response, channel economics, price, unit economics, operational capacity, legal constraints and financing. The Validation & Delivery Builder provides a disciplined bridge to these analyses; it does not replace them.
8.3 Evaluate learning quality, not interface activity
Success should not be measured by message count, AI word volume or time spent in the app. A balanced evaluation should combine four lenses. First, human-centred experience: completion, comprehension, accessibility, error recovery and perceived control. Second, process quality: proportion of claims with provenance, number and distinctness of alternatives, frequency of problem reframing, use of pre-defined thresholds and time from assumption to evidence. Third, decision quality: evidence-linked decisions, justified pivots, rejected false positives, brief staleness and downstream rework. Fourth, AI governance: extraction errors, unsupported claims, suggestion acceptance and editing, prohibited-action attempts, complaints and model-version regressions.
Outcome evaluation should compare cohorts or staged releases rather than assume improvement. A suitable study could compare the existing direct-to-workspace path with the new human-centred intake, while controlling for founder stage and prior experience. Researchers could assess whether users define clearer problems, generate more distinct concepts, pre-register stronger experiments and make more evidence-consistent decisions. Qualitative interviews would remain necessary because a low completion rate could indicate excessive friction or appropriately difficult reflection.
Figure 8. Balanced product evaluation scorecard
Source: Author's original diagram, synthesised from the sources cited in the surrounding discussion.
9. Conclusion
The strongest academic design for Dhruvi Infinity is not to bolt a separate Design Thinking product onto the existing application. It is to use Design Thinking as the missing discovery and divergence layer of one evidence-based journey. Discover and Empathize establish who experiences the situation and what is genuinely known. Define produces a founder-reviewed problem frame. Develop and Ideate create meaningful alternatives before selection. Prototype prepares the smallest credible test. The existing Validation & Delivery workspace then prioritises scope, tests assumptions, records evidence, preserves decisions and produces an approved or explicitly stale delivery brief.
The conversational assistant makes this sophisticated process approachable, but its authority must be constrained. AI can structure, explain, challenge and suggest. The founder confirms facts, selects the concept, supplies evidence and makes decisions. Deterministic server policies control completeness, authorisation, immutability and readiness. Provenance prevents assumptions and synthetic content from masquerading as research.
ISO 9241-210, ISO 56002 and ISO/IEC 42001 provide complementary governance lenses for human-centred design, innovation management and responsible AI. They should shape observable controls and evaluation evidence rather than become unsupported badges. If implemented in this way, the Validation & Delivery Builder can become more than a form or AI copywriter. It can function as a learning infrastructure that helps founders remain creative while becoming progressively more honest about what they know, what they assume and what they must test next.
References
Agile Business Consortium (2026) 'What is MoSCoW prioritization?'. Available at: https://www.agilebusiness.org/resource/what-is-moscow-prioritization/ (Accessed: 2 August 2026).
Autio, C., Schwartz, R., Dunietz, J., Jain, S., Stanley, M., Tabassi, E., Hall, P. and Roberts, K. (2024) Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. NIST AI 600-1. Gaithersburg, MD: National Institute of Standards and Technology. doi: 10.6028/NIST.AI.600-1.
Blank, S. (2013) 'Why the Lean Start-Up changes everything', Harvard Business Review, 91(5), pp. 63-72. Available at: https://hbr.org/2013/05/why-the-lean-start-up-changes-everything (Accessed: 2 August 2026).
Brown, T. (2008) 'Design thinking', Harvard Business Review, 86(6), pp. 84-92. Available at: https://hbr.org/2008/06/design-thinking (Accessed: 2 August 2026).
Buchanan, R. (1992) 'Wicked problems in design thinking', Design Issues, 8(2), pp. 5-21. doi: 10.2307/1511637.
Camuffo, A., Cordova, A., Gambardella, A. and Spina, C. (2020) 'A scientific approach to entrepreneurial decision making: evidence from a randomized control trial', Management Science, 66(2), pp. 564-586. doi: 10.1287/mnsc.2018.3249.
Carlgren, L., Rauth, I. and Elmquist, M. (2016a) 'Framing Design Thinking: the concept in idea and enactment', Creativity and Innovation Management, 25(1), pp. 38-57. doi: 10.1111/caim.12153.
Carlgren, L., Elmquist, M. and Rauth, I. (2016b) 'The challenges of using Design Thinking in industry: experiences from five large firms', Creativity and Innovation Management, 25(3), pp. 344-362. doi: 10.1111/caim.12176.
Design Council (n.d.) Framework for Innovation. Available at: https://www.designcouncil.org.uk/resources/framework-for-innovation/ (Accessed: 2 August 2026).
Dorst, K. (2011) 'The core of Design Thinking and its application', Design Studies, 32(6), pp. 521-532. doi: 10.1016/j.destud.2011.07.006.
Girotra, K., Terwiesch, C. and Ulrich, K.T. (2010) 'Idea generation and the quality of the best idea', Management Science, 56(4), pp. 591-605. doi: 10.1287/mnsc.1090.1144.
International Organization for Standardization (ISO) (2019a) ISO 9241-210:2019 Ergonomics of human-system interaction - Part 210: Human-centred design for interactive systems. Geneva: ISO. Available at: https://www.iso.org/standard/77520.html (Accessed: 2 August 2026).
International Organization for Standardization (ISO) (2019b) ISO 56002:2019 Innovation management - Innovation management system - Guidance. Geneva: ISO. Available at: https://www.iso.org/standard/68221.html (Accessed: 2 August 2026).
International Organization for Standardization and International Electrotechnical Commission (ISO/IEC) (2023) ISO/IEC 42001:2023 Information technology - Artificial intelligence - Management system. Geneva: ISO. Available at: https://www.iso.org/standard/42001 (Accessed: 2 August 2026).
Johansson-Sköldberg, U., Woodilla, J. and Çetinkaya, M. (2013) 'Design Thinking: past, present and possible futures', Creativity and Innovation Management, 22(2), pp. 121-146. doi: 10.1111/caim.12023.
Liedtka, J. (2015) 'Perspective: linking Design Thinking with innovation outcomes through cognitive bias reduction', Journal of Product Innovation Management, 32(6), pp. 925-938. doi: 10.1111/jpim.12163.
Micheli, P., Wilner, S.J.S., Bhatti, S.H., Mura, M. and Beverland, M.B. (2019) 'Doing Design Thinking: conceptual review, synthesis, and research agenda', Journal of Product Innovation Management, 36(2), pp. 124-148. doi: 10.1111/jpim.12466.
Oxford Brookes University (n.d.) Reference and avoid plagiarism. Available at: https://www.brookes.ac.uk/library/how-to/reference-and-avoid-plagiarism (Accessed: 2 August 2026).
Ries, E. (2011) The Lean Startup: how today's entrepreneurs use continuous innovation to create radically successful businesses. New York: Crown Business.
Stanford d.school (2018) No-Build Hack. Available at: https://dschool.stanford.edu/tools/no-build-hack (Accessed: 2 August 2026).
Stanford d.school (n.d.) Design Thinking Bootleg. Available at: https://dschool.stanford.edu/tools/design-thinking-bootleg (Accessed: 2 August 2026).
World Wide Web Consortium (W3C) (2013) PROV-DM: the PROV Data Model. W3C Recommendation. Available at: https://www.w3.org/TR/prov-dm/ (Accessed: 2 August 2026).
World Wide Web Consortium (W3C) (2023) Web Content Accessibility Guidelines (WCAG) 2.2. W3C Recommendation. Available at: https://www.w3.org/TR/WCAG22/ (Accessed: 2 August 2026).
Discovered from Knowledge
More related reading
These picks share product, topic, series, or format signals with this article.
A complete overview of UK AI grants for startup founders in 2026, summarising Frontier AI Discovery, AI Champions, Sovereign AI Strategic Assets, BridgeAI and Innovate UK application requirements, with links to detailed guides for each funding route.
A practical, step-by-step walkthrough showing how a freelancer or agency runs a full year of operations using DII Accounts — from first invoice to VAT, reconciliation, and reporting.
A structured series that explains how entrepreneurial organisations operate under uncertainty, combining academic theory with practical founder decisions to build innovation, viability, and scalability.