A ground-up audit and coded concept exploring how first-time visitors could choose the right AI support on Servant.io.
Project type
Self-initiated redesign
Planned scope
8 weeks · 160 hours
Current stage
Initial coded concept
Research status
User validation pending
This is not client work or a launched redesign. The current artifact is an AI-assisted coded proposal. No participant research, business analytics, client endorsement, or conversion improvement is claimed. The full project plan describes the work still needed to make a defensible portfolio case study.
Make the next decision easier.
The original brief asked how Servant could communicate and use AI more clearly. A fresh review matters: the current website already includes need-based AI links, a readiness assessment link, five consulting engagements, and Kinvia.
The project therefore asks a narrower question: can clearer entry points, comparable service information, consistent product naming, and an explained next step help visitors choose support with less uncertainty?
Role and contribution
This concept and plan were generated with AI assistance. To present this as your portfolio work, document the research you conduct, alternatives you consider, decisions you own, changes you make, and tests you run. Do not claim authorship of unperformed work.
Scope: homepage AI wayfinding, AI service hub, product distinction, a starting-point guide, and a helper/contact preview. Broader company services remain discoverable through official links.
Observe before recommending
Keep what already works.
Reviewed on October 15, 2026 using public page content and browser observation. The existing site has a strong mission-led visual identity, a five-service AI table with timelines, a visible contact route, and an assistant with a privacy link. These are foundations to preserve, not missing features to invent.
OBSERVED · Current homepage, desktop browser capture. AI choice links appear later on the page. Click to inspect the evidence.OBSERVED · Assistant opening still references FaithBase while the homepage links to Kinvia. No user messages were submitted.
Screenshot captures use the browser’s default desktop viewport. The AI-page capture below is a full-page record. Exact pixel metadata is included in the generated evidence manifest. Images may include animated-background frames.
PROPOSED · F1: the opening view makes the next decision explicit. Compare with the current homepage above; usability improvement is not yet established.IMPLEMENTED DEMO · F4: a route, a reason, an alternative, and a source. This is fixed-rule guidance, not an AI maturity score.
Mobile concept evidence: homepage · service comparison. These are prototype checks, not participant validation. The matching live-site mobile baseline remains to be captured.
What changes—and how
Five focused improvements.
F1 · Hypothesis
Bring the choice forward.
Observed: the opening homepage is mission-led; need-based AI routes exist further down.
Proposed fix: an early, plain-language starting-point action plus visible service routes—not a replacement for all company services.
How: add three need-based entry cards, link each to an appropriate destination, preserve a direct consulting comparison, and keep broader service links. Build semantic navigation and responsive layouts.
Validate: ask participants to locate appropriate support from the homepage without help. Compare completion, first choice, and hesitation with the baseline.
Observed: the homepage’s product route says Kinvia; the opened assistant’s greeting and prompt mention FaithBase.
Proposed fix: consistent current naming and a clear product-versus-consulting explanation. Do not assume or assert a rebrand relationship without confirmation.
How: audit public labels, assistant prompts, destinations, and approved knowledge sources; confirm the naming with an owner. In this concept, use the product linked by the current homepage and explain the two routes side by side.
Validate: ask users to explain the difference between buying/exploring a website product and engaging a consulting team.
Observed: the current AI page already provides five services, outputs, and timings in a table. Whether visitors understand the right entry stage is not established.
Proposed fix: consistent “best for,” “what you receive,” “published timing,” and “next step” fields in mobile-friendly service sections.
How: use one content model for five service records; stack details on small screens, retain all essential information, and add explicit alternatives. Do not copy durations into promises or quotes.
Validate: give two contrasting scenarios and ask users to choose and explain a suitable engagement on desktop and mobile.
Observed: the live assistant offers starter prompts and an AI/privacy disclosure. Its answer accuracy and handoff behavior were not evaluated in this review.
Proposed fix: a transparent local starting-point guide and a bounded helper demonstrating source links, unknown-answer handling, and a person route.
How: use three questions with explicit routing rules, a reason, an alternative, back/restart, and a no-score disclaimer. Keep the helper deterministic in the prototype. A real AI implementation requires a separate approval and evaluation process.
Validate: test all routes and unsupported questions, then ask users to explain why the result was suggested and whether anything has been sent.
F5 · Hypothesis
Make the handoff explicit.
Observed: contact links and an external scheduling destination exist. The completion rate and causes of abandonment are unknown.
Proposed fix: explain the next action and external destination before leaving the concept. In production, obtain permission before attaching any user context.
How: show a route-specific next-step preview. Do not collect data, simulate a successful booking, or send an unsolicited message in a portfolio prototype.
Validate: users can locate a person route, identify where it goes, and accurately say whether their guide answers are shared.
AI as a tool, not a claim
Use AI with a review loop.
During the audit: use AI to draft an issue taxonomy and research questions, compare copy alternatives, and help structure anonymized notes. A person verifies every finding against page evidence. Do not upload participant data without consent and an appropriate data policy.
During design and development: use AI for alternative flows, interface copy, code scaffolding, edge-case lists, and test drafts. Record what was accepted, rejected, or changed and why.
In the product: start with explicit routing rules. Only add generative assistance when it solves a demonstrated need. Production work would need approved retrieval sources, cited answers, unknown-topic fallback, input/output safeguards, privacy review, consented handoff, and ongoing evaluation.
Not in this demo: model API calls, live retrieval, CRM integration, actual bookings, maturity scoring, or claims of verified answer accuracy.
Evidence before outcomes
How we’ll know it helps.
Run five formative baseline sessions and five prototype sessions using comparable scenarios.
Record unaided task completion, correct explanation of service choice, time, assistance, and critical errors.
Use at least 4 of 5 successful participants per core task as a proposed iteration threshold—not statistical proof.
Check keyboard flow, focus return, screen reader behavior, contrast, zoom, motion, and mobile layouts. Automated checks do not prove full accessibility.
Only measure real conversion after an authorized production launch with agreed analytics, consent, baseline windows, and denominators.
The prototype demonstrates a direction. It does not establish improved conversion, trust, accessibility conformance, or AI performance.
Servant homepage — current service areas, AI entry paths, and Kinvia link.
Servant AI Strategy — five engagements, published ranges, education routes, and live assistant opening.
Kinvia — product positioning; claims are the vendor’s, not independently validated here.
Google UX Design Certificate — a process reference: understand users, define, ideate, prototype, test. This project is not Google-certified or endorsed.
Completed starter deliverables: public-source review, selected desktop captures, an initial issue/hypothesis matrix, an eight-week task plan, and a coded concept.
Still needed: systematic baseline and mobile evidence, participant research, analytics access, owner-approved content, full accessibility testing, usability validation, iteration, and a real implementation handoff.
Preserved: the official website and prior slide deck remain unchanged. This concept is now included in the updated portfolio case study.
