# Servant.io — updated independent UX audit and coded concept Baseline reviewed October 15, 2026. Self-initiated, AI-assisted portfolio work; not commissioned, endorsed, or production work. ## Current status Completed starter outputs: public-source review, selected desktop captures, five findings/hypotheses, a responsive coded concept, a 42-task plan, and documented technical checks. User research, approved content, full accessibility testing, and usability validation remain planned. No conversion improvement is claimed. ## Scope Homepage AI wayfinding; five consulting engagements; product-versus-consulting distinction; a starting-point guide; scripted helper; explicit contact preview. The existing site already includes need-based AI links, readiness assessment, a five-engagement table with outputs/timings, contact routes, and a privacy link. ## Five findings ### F1 — Bring the choice forward. (IMPROVEMENT HYPOTHESIS) Observation: The mission-led homepage already includes need-based AI routes further down. Their placement is observed; difficulty finding them has not been established. Design response: Bring a plain-language entry action into the opening view, with direct service routes and broader company services still discoverable. Concept implementation: The concept gives visitors an early route choice and a three-question starting-point guide. Validation: Ask participants to locate appropriate support without help; compare completion, first choice, and hesitation with the existing site. ### F2 — Make product naming consistent. (OBSERVED INCONSISTENCY) Observation: The homepage links to Kinvia, while the opened Ask Servant greeting and suggested prompt still mention FaithBase. Their relationship is unconfirmed. Design response: Confirm naming with an owner, then align labels, assistant prompts, destinations, and approved knowledge sources. Concept implementation: The concept uses the currently linked Kinvia product route and explains product exploration separately from consulting. It does not assert an unverified rebrand. Validation: Check the content inventory and ask users to explain the difference between a website product and a consulting engagement. ### F3 — Make five engagements easier to compare. (IMPROVEMENT HYPOTHESIS) Observation: The AI Strategy page already provides five engagements, outputs, and published timings. The review does not establish that the table is unusable. Design response: Use consistent “best for,” “what you receive,” “published timing,” and “next step” fields, stacking details on mobile. Concept implementation: A shared content model renders all five services: readiness, workshop, blueprint, implementation sprints, and education/adoption. Published durations are context, not a project quote. Validation: Give two contrasting scenarios on desktop and mobile; ask participants to choose an engagement and explain their reasoning. ### F4 — Explain the recommendation. (PROPOSED BEHAVIOR) Observation: The live assistant has starter prompts and a privacy disclosure. Answer accuracy and handoff behavior were not evaluated; no live messages were submitted. Design response: Show a route, a reason, an alternative, a source, and recovery options. Distinguish local rules from generative AI or an official maturity assessment. Concept implementation: Three questions route to six possible destinations with explicit rules, back/restart, and a governance-uncertainty override. A scripted helper includes no-match handling and a person route. Validation: Exercise the rules and unsupported questions, then ask users to explain why a result appeared and whether any information was sent. ### F5 — Make the next step explicit. (IMPROVEMENT HYPOTHESIS) Observation: Contact links and an external scheduling destination exist. Completion rates and causes of abandonment are unknown. Design response: Explain the destination and what would happen to context before a visitor leaves. A real handoff would require permission before sharing information. Concept implementation: A route-specific preview points to an official destination. It sends nothing, attaches no guide answers, collects no contact details, and creates no booking. Validation: Ask participants to find a person route, identify where it goes, and accurately explain whether their answers are shared. ## Implemented prototype Dark/bone/red homepage; four service routes; Understand/Create/Enable animated process; shared Pause/Resume; service comparison with five records; three-question fixed-rule guide with reasons, alternatives, sources, back/restart; scripted helper with no-match fallback; honest next-step preview. No model calls, live retrieval, CRM, contact submissions, maturity scores, or actual bookings. ## Technical QA The recorded lab checks include 14 expected-result routing scenarios, all 54 valid combinations, six allowed destinations, guide validation/result, contact disclosure and focus return, helper fallback, mobile menu and layouts, expanded service/task details, Pause/Resume, and hero/background dimensions. These are implementation checks, not participant results. Full screen-reader, keyboard/focus, zoom, contrast, reduced-motion browser preference, matched live mobile baseline, and comprehensive destination testing remain outstanding. See servant-concept/qa-report.md for the exact scope and refinement history. ## Planned work 8 weeks, 160 planned focused hours, 20 per week, 42 ordered tasks. These are not hours already worked or a guaranteed completion schedule. - Week 1: Establish the baseline — 6 tasks. Evidence inventory, current journey, issue log, and a measurable scope. - Week 2: Understand the decisions — 6 tasks. Research notes, problem statements, and prioritized requirements. - Week 3: Structure the solution — 5 tasks. Sitemap, future journey, content model, routing rules, and low-fidelity screens. - Week 4: Design the interface — 5 tasks. Responsive UI system, annotated screens, and a connected prototype. - Week 5: Build the responsive foundation — 5 tasks. Working homepage, AI services hub, navigation, and source-linked content. - Week 6: Build the guided interactions — 5 tasks. Working starting-point guide, constrained helper, and honest handoff. - Week 7: Validate and improve — 5 tasks. Usability findings, accessibility review, revisions, and a retest log. - Week 8: Package the portfolio story — 5 tasks. Case study, screenshots, client/interview presentation, and release checklist. See servant-concept/project-plan.md and servant-concept/plan.html for all tasks, dependencies, deliverables, and gates. ## Validation plan Five formative baseline sessions and five prototype sessions, using comparable scenarios. Record unaided task completion, service-choice comprehension, time, assistance, and critical errors. At least 4/5 successful participants per core task is a proposed iteration threshold, not a result or statistical proof. Real conversion measurement requires an authorized production launch and agreed consent, analytics, baseline windows, and denominators. ## Contribution and learning AI supported audit structure, copy, implementation, and test drafts. This is a collaborative output. Document personal research, alternatives, decisions, edits, and tests before claiming them. The study develops evidence-led evaluation, information architecture, interaction design, explicit-rule guidance, responsive prototyping, and bounded QA. The key lesson is to re-check old assumptions and preserve what already works. ## Evidence and sources Seven dated captures and their limits: servant-concept/evidence/manifest.md. Public-source screenshots show observations; prototype screenshots show implementation, not validated improvement. A matched live mobile baseline remains outstanding. - https://www.servant.io/ - https://www.servant.io/ai-strategy - https://www.usekinvia.ai/ - https://grow.google/certificates/ux-design/ (process reference only; no certification or endorsement) The official site and prior slide deck remain unchanged.