# Servant.io: ground-up UX audit and redesign action plan Independent, AI-assisted portfolio project. Reviewed baseline: October 15, 2026. Not affiliated with or endorsed by Servant. ## Outcome and boundaries Build a defensible case study showing what needs fixing, why, exactly how the interface changes, and what evidence would demonstrate improvement. Preserve the live website and existing slide deck. The deliverable is a coded portfolio concept, not a production launch. ## Timeframe 8 weeks, 160 planned focused hours, 20 hours per week, 42 ordered tasks. One designer/developer at 20 focused hours per week. Recruitment, feedback, and approvals can extend elapsed time. This is a task-level work budget, not a guaranteed delivery date. The earlier six-week scope covered design/research; this version adds a coded concept and interaction QA. Do not present these planned allocations as actual hours worked. ## What we are fixing - F1: Earlier AI wayfinding. The current homepage already has need-based routes lower down; test bringing an entry action into the opening view. - F2: Naming consistency. The reviewed homepage links to Kinvia, while the opened assistant still references FaithBase. Confirm the relationship with an owner; do not assert an unverified rebrand. - F3: More comparable services. The current page already has five engagements, outputs, and timelines. Add consistent needs and next steps; test comprehension rather than assuming the table is unusable. - F4: Explained guidance. Use transparent routing, a reason, alternative, back/restart, sources, and no-match states. The demo is not live generative AI or an official maturity assessment. - F5: Explicit handoff. Explain the next destination and whether context is shared. The concept sends nothing and creates no real booking. F1, F3, F4, and F5 are improvement hypotheses or proposed behavior, not established user failures. F2 is a directly observed content inconsistency. All priorities should be revisited after research. ## How to follow the plan Work through tasks in numeric order. The owner is the portfolio designer/developer, with participant or client input where specified. Each week depends on the prior decision gate. Record actual effort, evidence links, decisions, blockers, and status beside the planned hours. Recruit in parallel where indicated; the hour totals are active effort, not waiting time. ## Step 1 — Week 1: Establish the baseline (20 hours) Goal: Find out what the website actually does before deciding what is broken. Deliver: Evidence inventory, current journey, issue log, and a measurable scope. Completion gate: Every issue cites a location and observation; assumptions are explicitly labeled. ### Task 1.1: Define the project boundary — 2 planned hours Action: List the homepage, AI Strategy, readiness handoff, Kinvia handoff, Ask Servant, and contact journey. Write three visitor tasks: choose a service, compare options, and reach a person. Exclude rebuilding all company pages and production AI infrastructure. Deliverable / done check: Signed-off scope and three task definitions. Dependency: project scope and authorized public-page access. Status: planned, not a completed research claim. ### Task 1.2: Capture the current journey — 4 planned hours Action: At desktop and mobile widths, record the homepage → AI page → service choice → next step. Save dated screenshots, URL, viewport, and observation. Check external assessment and Kinvia links without submitting personal data. Deliverable / done check: Screenshot inventory and annotated current-state journey. Dependency: earlier tasks within this week. Status: planned, not a completed research claim. ### Task 1.3: Audit content and service accuracy — 4 planned hours Action: Inventory the five AI engagements, their published timelines, Kinvia, and the broader four service areas. Identify inconsistent labels, vague next steps, and unsupported proof. Separate current offers from older FaithBase references. Deliverable / done check: Source-linked content matrix with keep, clarify, and remove decisions. Dependency: earlier tasks within this week. Status: planned, not a completed research claim. ### Task 1.4: Run usability and accessibility checks — 4 planned hours Action: Walk the three tasks with keyboard only. Inspect focus, link purpose, headings, form labels, errors, contrast, zoom, motion, and mobile overflow. Record a reproducible defect instead of assuming noncompliance from appearance. Deliverable / done check: Issue log containing steps to reproduce and impact hypotheses. Dependency: earlier tasks within this week. Status: planned, not a completed research claim. ### Task 1.5: Collect an ethical baseline — 4 planned hours Action: If authorized analytics exist, record service-page visits, readiness exits, and contact starts/completions with date ranges. Otherwise mark them unavailable and run five baseline task sessions later in Week 2; never invent conversion rates. Deliverable / done check: Baseline sheet with denominators and known data gaps. Dependency: earlier tasks within this week. Status: planned, not a completed research claim. ### Task 1.6: Prioritize and start recruitment — 2 planned hours Action: Rank evidenced defects by impact and frequency. Keep improvement ideas separate. Draft outreach for five relevant mission-driven organization decision-makers and start scheduling. Deliverable / done check: Ranked backlog plus recruitment tracker. Dependency: earlier tasks within this week. Status: planned, not a completed research claim. ## Step 2 — Week 2: Understand the decisions (20 hours) Goal: Test whether our assumed problems are real for the people choosing services. Deliver: Research notes, problem statements, and prioritized requirements. Completion gate: Each design requirement traces to research or is labeled an untested hypothesis. ### Task 2.1: Write a neutral research guide — 3 planned hours Action: Create five screening questions and three baseline tasks. Ask participants to explain the existing AI options, choose a next step for a realistic situation, and find help or privacy information. Avoid showing the proposed solution first. Deliverable / done check: Screener, consent script, task guide, and note template. Dependency: Week 1 outputs and completion gate. Status: planned, not a completed research claim. ### Task 2.2: Recruit and schedule five participants — 3 planned hours Action: Recruit leaders or operations/communications staff from relevant organizations. Obtain informed consent for notes or recording. Use synthetic scenarios; do not request client, donor, or sensitive organizational data. Deliverable / done check: Five scheduled sessions and consent records; recruiting time is active effort only. Dependency: earlier tasks within this week. Status: planned, not a completed research claim. ### Task 2.3: Run five baseline interviews and tasks — 5 planned hours Action: Allow about 45 minutes per session plus immediate notes. Observe choices, hesitation, assistance, misinterpretations, and next-step confidence on the current website. Do not teach the navigation during tasks. Deliverable / done check: Anonymized observations, task completion counts, and participant quotes with permission. Dependency: earlier tasks within this week. Status: planned, not a completed research claim. ### Task 2.4: Synthesize the evidence — 4 planned hours Action: Group observations by decision point. Distinguish a directly observed difficulty from an interpretation. Note contradictions and sample limitations; five sessions are formative, not population-level proof. Deliverable / done check: Affinity themes and evidence-linked problem statements. Dependency: earlier tasks within this week. Status: planned, not a completed research claim. ### Task 2.5: Choose the redesign scope — 3 planned hours Action: Select the highest-value changes for service finding, comparison, product-versus-consulting distinction, and human help. Write an acceptance check for each. Drop ideas unsupported by the research. Deliverable / done check: Approved issue-to-change-to-test matrix. Dependency: earlier tasks within this week. Status: planned, not a completed research claim. ### Task 2.6: Agree content and evidence needs — 2 planned hours Action: Request current service descriptions, privacy language, and authorized case studies if this becomes a client project. In an independent project, label missing content and use source-linked summaries instead of invented client results. Deliverable / done check: Content ownership list and explicit evidence gaps. Dependency: earlier tasks within this week. Status: planned, not a completed research claim. ## Step 3 — Week 3: Structure the solution (20 hours) Goal: Define the destinations and rules before drawing the interface. Deliver: Sitemap, future journey, content model, routing rules, and low-fidelity screens. Completion gate: Every path ends at a meaningful next action; no maturity score is fabricated. ### Task 3.1: Map the information architecture — 4 planned hours Action: Keep the four company service areas discoverable. Design an AI hub with five consulting engagements, a separate Kinvia product route, and a direct person route. Label which links leave the site. Deliverable / done check: Sitemap and navigation labels. Dependency: Week 2 outputs and completion gate. Status: planned, not a completed research claim. ### Task 3.2: Map the future visitor journey — 4 planned hours Action: Draw entry → identify need → compare → explain recommendation → review source → next action. Include skip, back, change answer, no match, and human help paths. Deliverable / done check: Future-state task flow with recovery paths. Dependency: earlier tasks within this week. Status: planned, not a completed research claim. ### Task 3.3: Write the service content model — 5 planned hours Action: For each AI engagement define best for, what you receive, published timing, and next step. Link to the source and mark proposed copy. Add a consistent Kinvia-versus-consulting explanation. Deliverable / done check: Five service records and a product comparison. Dependency: earlier tasks within this week. Status: planned, not a completed research claim. ### Task 3.4: Specify transparent recommendation rules — 5 planned hours Action: Create a three-question starting-point guide. Route uncertainty to readiness, leadership alignment to workshop, planning to blueprint, delivery to sprints, adoption to education, and website questions to Kinvia. Safety/governance uncertainty overrides a build recommendation. Deliverable / done check: Decision table, reasons, alternatives, and scenario tests. Dependency: earlier tasks within this week. Status: planned, not a completed research claim. ### Task 3.5: Sketch desktop and mobile alternatives — 2 planned hours Action: Sketch two service-selection layouts and choose using the agreed tasks. Place the primary action early without removing the broader company offering. Deliverable / done check: Low-fidelity screens and a recorded design decision. Dependency: earlier tasks within this week. Status: planned, not a completed research claim. ## Step 4 — Week 4: Design the interface (20 hours) Goal: Make the proposed experience concrete and readable before implementation. Deliver: Responsive UI system, annotated screens, and a connected prototype. Completion gate: A first-time viewer can follow the service choice and understand prototype limitations. ### Task 4.1: Define accessible design tokens — 4 planned hours Action: Set typography, cream/ink/red colors, spacing, borders, focus treatment, and touch targets. Check normal text contrast against the selected backgrounds. Respect reduced motion. Deliverable / done check: Token sheet and checked color pairs. Dependency: Week 3 outputs and completion gate. Status: planned, not a completed research claim. ### Task 4.2: Design the homepage and AI hub — 6 planned hours Action: Create a direct-value hero, need-based entry points, five comparable service cards, broader service links, and separate Kinvia section. Use source-backed content, not invented social proof. Deliverable / done check: Desktop and mobile screen set. Dependency: earlier tasks within this week. Status: planned, not a completed research claim. ### Task 4.3: Design guide and helper states — 4 planned hours Action: Design all question screens, validation, back, result, why, alternative, source, and restart. Design a constrained helper with visible limitations and no-match behavior. Deliverable / done check: Complete interaction-state inventory. Dependency: earlier tasks within this week. Status: planned, not a completed research claim. ### Task 4.4: Design contact and trust moments — 4 planned hours Action: Show what would happen next, external destinations, privacy guidance, and a direct person option. For the portfolio demo do not collect contact data or claim a booking has occurred. Deliverable / done check: Trust copy and honest handoff states. Dependency: earlier tasks within this week. Status: planned, not a completed research claim. ### Task 4.5: Review the prototype against issues — 2 planned hours Action: Walk each issue ID through its proposed screen and acceptance check. Ask for design feedback; resolve missing content before coding. Deliverable / done check: Design review notes and a build-ready screen inventory. Dependency: earlier tasks within this week. Status: planned, not a completed research claim. ## Step 5 — Week 5: Build the responsive foundation (20 hours) Goal: Implement the website structure and comparison experience. Deliver: Working homepage, AI services hub, navigation, and source-linked content. Completion gate: Core content works at mobile and desktop widths without horizontal overflow. ### Task 5.1: Set up semantic pages and navigation — 4 planned hours Action: Build a skip link, header, mobile menu, main landmark, heading hierarchy, and footer. Create homepage, services, case study, and plan pages. Use local assets and avoid unnecessary tracking. Deliverable / done check: Navigable page skeleton with meaningful titles. Dependency: Week 4 outputs and completion gate. Status: planned, not a completed research claim. ### Task 5.2: Build the homepage and responsive layout — 6 planned hours Action: Implement the editorial hero, need-based routes, broader service links, and a clear independent-concept notice. Make layout adapt without hiding essential information. Deliverable / done check: Responsive homepage with usable primary actions. Dependency: earlier tasks within this week. Status: planned, not a completed research claim. ### Task 5.3: Build the service comparison — 4 planned hours Action: Render all five engagements from a single source of data. Add consistent best-for, deliverables, timing, and next step fields. Test expanding details on mobile. Deliverable / done check: Five functional service cards and accurate source links. Dependency: earlier tasks within this week. Status: planned, not a completed research claim. ### Task 5.4: Build the Kinvia distinction and trust content — 4 planned hours Action: Separate product exploration from consulting. Explain external links and prototype privacy. Add relevant source links; never present general agency metrics as AI-specific redesign outcomes. Deliverable / done check: Product route, trust section, and source inventory. Dependency: earlier tasks within this week. Status: planned, not a completed research claim. ### Task 5.5: Check foundation behavior — 2 planned hours Action: Verify navigation, all links, responsive overflow, keyboard focus, and readable zoom. Fix broken paths before adding interaction complexity. Deliverable / done check: Foundation QA log and resolved blocker list. Dependency: earlier tasks within this week. Status: planned, not a completed research claim. ## Step 6 — Week 6: Build the guided interactions (20 hours) Goal: Demonstrate the proposed decision journey, not just static pictures. Deliver: Working starting-point guide, constrained helper, and honest handoff. Completion gate: Each rule, recovery state, and disclosure behaves as specified. ### Task 6.1: Implement the three-question guide — 6 planned hours Action: Build native labeled radio groups, progress, inline error, next/back, answer preservation, result explanation, alternative, source link, and restart. Store answers only in session memory. Deliverable / done check: Interactive guide and branch test results. Dependency: Week 5 outputs and completion gate. Status: planned, not a completed research claim. ### Task 6.2: Implement the constrained helper demo — 6 planned hours Action: Provide service, Kinvia, and privacy prompts plus text input. Use deterministic responses from the verified content inventory. Clearly state this is not live generative AI; unsupported questions produce a no-match response and person option. Deliverable / done check: Functional scripted helper with known-topic and unknown-topic tests. Dependency: earlier tasks within this week. Status: planned, not a completed research claim. ### Task 6.3: Implement transparent next steps — 4 planned hours Action: Offer a local summary of the selected route and a clearly labeled link to the real contact page. No data is submitted and no message is said to be sent. Preserve a way to change the recommendation. Deliverable / done check: Contact-preview state, clear external link, and working back route. Dependency: earlier tasks within this week. Status: planned, not a completed research claim. ### Task 6.4: Add audit annotations and case-study links — 2 planned hours Action: Create an optional design-notes toggle linking implemented changes to issue IDs. Keep notes off by default so the concept can be presented as a product experience. Deliverable / done check: Reviewer mode and a readable case-study page. Dependency: earlier tasks within this week. Status: planned, not a completed research claim. ### Task 6.5: Test all rules and recovery paths — 2 planned hours Action: Test every service outcome, Kinvia, governance uncertainty, back/restart, empty input, unknown question, dialog Escape, focus return, and helper close. Document any failure. Deliverable / done check: Repeatable interaction checks with observed results. Dependency: earlier tasks within this week. Status: planned, not a completed research claim. ## Step 7 — Week 7: Validate and improve (20 hours) Goal: Find out whether the redesign helps, and correct the most serious failures. Deliver: Usability findings, accessibility review, revisions, and a retest log. Completion gate: No unresolved blocker in the primary task; research results are reported honestly. ### Task 7.1: Prepare a matched usability test — 3 planned hours Action: Use comparable scenarios to the baseline without revealing desired answers. Define unaided task success, comprehension, time on task, assistance, and critical errors. Counterbalance versions if the same users return. Deliverable / done check: Test protocol and predeclared success criteria. Dependency: Week 6 outputs and completion gate. Status: planned, not a completed research claim. ### Task 7.2: Run five redesign sessions — 5 planned hours Action: Ask five relevant participants to choose an engagement, distinguish Kinvia from consulting, explain the recommendation, and reach a person. Record observable behavior and consented feedback. Deliverable / done check: Five session records and task-level results. Dependency: earlier tasks within this week. Status: planned, not a completed research claim. ### Task 7.3: Analyze results and limitations — 3 planned hours Action: Compare baseline and prototype task counts using denominators. Treat 4/5 as a formative threshold, not an 80% population claim. Do not claim conversion lift from a prototype. Deliverable / done check: Findings table with severity, evidence, and limitations. Dependency: earlier tasks within this week. Status: planned, not a completed research claim. ### Task 7.4: Revise and retest the biggest failures — 5 planned hours Action: Fix the three highest-impact issues. Re-run failed tasks with at least two participants where possible. Keep a before/after revision log and unresolved issue owner. Deliverable / done check: Revised prototype and targeted retest evidence. Dependency: earlier tasks within this week. Status: planned, not a completed research claim. ### Task 7.5: Complete technical accessibility QA — 4 planned hours Action: Test keyboard-only flow, Escape/focus return, screen reader labels and announcements, 200% zoom, reduced motion, and small-screen layout. Run automated checks as a supplement, not proof of full WCAG conformance. Deliverable / done check: Accessibility checklist, defects, fixes, and remaining limitations. Dependency: earlier tasks within this week. Status: planned, not a completed research claim. ## Step 8 — Week 8: Package the portfolio story (20 hours) Goal: Show the decisions, implementation, and evidence without overstating the work. Deliver: Case study, screenshots, client/interview presentation, and release checklist. Completion gate: Every claim is sourced or evidenced, and your personal contribution is accurate. ### Task 8.1: Write the case study — 5 planned hours Action: Explain context, scope, role, method, observed issues, alternatives, chosen design, implementation, actual tests, limitations, and next steps. Distinguish your decisions from AI-assisted suggestions and code. Deliverable / done check: A narrative a first-time reviewer can follow. Dependency: Week 7 outputs and completion gate. Status: planned, not a completed research claim. ### Task 8.2: Capture and annotate final evidence — 5 planned hours Action: Capture matching before/after task locations on desktop and mobile. Label source, date, viewport, issue ID, change, and status. Remove personal data. Keep screenshots relevant to the point being made. Deliverable / done check: An annotated screenshot set and evidence captions. Dependency: earlier tasks within this week. Status: planned, not a completed research claim. ### Task 8.3: Prepare an eight-slide presentation — 4 planned hours Action: Use context, baseline, top issues, design rationale, interactive demo, test evidence, detailed plan summary, and next steps. Move the full task list into an appendix or linked plan. Deliverable / done check: Presentation outline and a 7–10 minute talk track. Dependency: earlier tasks within this week. Status: planned, not a completed research claim. ### Task 8.4: Verify and publish the concept — 3 planned hours Action: Check links, mobile layout, spelling, source accuracy, disclaimers, interaction tests, and open issues. Keep private until you deliberately choose to share the portfolio. Do not change Servant production systems. Deliverable / done check: Release checklist and a verified concept URL. Dependency: earlier tasks within this week. Status: planned, not a completed research claim. ### Task 8.5: Rehearse and define the real launch work — 3 planned hours Action: Rehearse the three demo tasks. Explain what is still unvalidated. Scope production CMS, privacy review, approved AI backend, analytics consent, CRM integration, and rollout separately with owners. Deliverable / done check: Interview-ready walkthrough and production backlog. Dependency: earlier tasks within this week. Status: planned, not a completed research claim. ## Using AI responsibly in the work 1. Audit: AI may draft issue categories or research questions. Verify every issue against a dated screenshot and observed behavior. Never generate fictional participant quotes or analytics. 2. Research: AI may help structure anonymized, consented notes. Do not upload identifying participant or client material without appropriate permission and a reviewed data policy. Keep raw evidence and human interpretation distinct. 3. Design: request multiple layouts and copy alternatives, compare them against the tasks, and document why you accept or reject them. Do not choose a chatbot simply because the topic is AI. 4. Build: use generated scaffolding and tests as drafts. Review semantics, privacy, state handling, error states, focus, and security. Record AI assistance and your personal contribution. 5. Product: the initial guide uses rules. The helper uses fixed content and an unknown-topic response. A real retrieval-backed assistant would require approved sources, answer citations, source freshness review, prompt-injection resistance, test sets, safe fallback, consented handoff, and ongoing monitoring. That backend is outside this prototype budget. ## Validation criteria (proposed, not results) - Five baseline sessions and five prototype sessions with relevant participants. Report counts and denominators, assistance, errors, and sample limitations. - Aim for at least 4 of 5 completing each core task without help: choose an appropriate engagement and explain it; distinguish product from consulting; find the person route and explain what is shared. This is an iteration threshold, not statistical proof. - Test every routing branch, back/restart, empty selection, unknown helper question, keyboard dialog behavior, and honest contact preview. - Review keyboard-only operation, screen reader announcements, labels, focus, contrast, zoom, reduced motion, and mobile layouts. No full WCAG conformance claim without a complete audit. - Business outcomes require an authorized production launch, agreed baseline, consented analytics, event definitions, denominators, and observation window. No conversion lift is claimed here. ## Tracking template For each task record: ID | planned hours | actual hours | owner | evidence link | decision | status | blocker | next action. For each issue record: ID | URL/component | screenshot/date/viewport | observation | impact hypothesis | priority rationale | proposed fix | acceptance check | validation status. ## Schedule risks Recruitment or approval delays extend elapsed time. Missing source content stays labeled; do not invent it. If a major test failure needs more work, reduce decorative scope or explicitly extend the plan. Production CMS, live AI, privacy/legal approval, analytics consent, CRM, deployment to Servant, and ongoing operations require a separately agreed backlog and owners. ## Current starter status Completed in the starter: a public-source review, selected desktop screenshots, initial hypotheses, the detailed plan, and a coded interactive concept. Not completed: participant research, actual analytics baseline, systematic mobile evidence, full screen reader/accessibility review, validated improvements, client endorsement, or production integration. Confirm technical QA separately in qa-report.md. The generated prototype is AI-assisted; only claim the contributions you actually make. ## Source register - https://www.servant.io/ — homepage, wider service structure, current AI entry routes and Kinvia link. - https://www.servant.io/ai-strategy — five engagements and published timelines; direct browser review also showed education routes and assistant opening. - https://www.usekinvia.ai/ — product positioning, treated as vendor claims. - https://grow.google/certificates/ux-design/ — UX process reference, not an endorsement or certification of this project. Public website baseline reviewed October 15, 2026. Re-check before presenting; product names and offers may change. ## Your first action Spend two focused hours on Task 1.1: write the exact scope and the three visitor tasks. Then spend four hours on Task 1.2: capture the current journey and annotate evidence. Do not assume this initial redesign is the final solution before research.