Northminster Presbyterian Church
A neighborhood church in Clairemont since 1953, rebuilt around the question a newcomer actually has: what happens if I show up?
Capability · AI Experience Design
AI is a capability,not the product by default.
Start with the business problem. Sometimes AI belongs inside the software. Sometimes it's mostly part of how we research, design, build and test it. Sometimes the right product barely shows AI to the people using it at all. We help you tell which is which.
Our founder has been working with these tools since late 2020, back when the outputs were rough and the hype was already deafening. What we've learned since: AI is remarkable at generating options, drafting artifacts and extending how much thinking a team can do — and genuinely bad at owning an outcome, reading a room, or being accountable when something goes wrong. The design opportunity lives exactly on that line.
That's why we don't assume a client needs agents, chatbots or an "AI transformation." Most don't. What most businesses need is software that solves a real problem well, and AI changes what's possible in two different places. It can live inside the product, doing work for the people who use it. Or it can live in how the product gets made, multiplying the research, design, engineering and testing an experienced team can apply. Many of the best outcomes lean on the second far more than the first.
Most 'AI features' shipping right now are a text box bolted onto an existing product with a sparkle icon next to it. Sometimes that's the right call. Usually it isn't. The better move is to ask what job the user is really trying to do, then decide where AI removes friction from that job and where it introduces new friction — hallucinated answers, unpredictable behavior, a lost sense of control.
When AI belongs inside the software
Good AI experience design is mostly about trust and control. Can the user tell what the system did and why? Can they steer it, correct it, and fall back to a reliable path when it's wrong? Get those right and AI feels like leverage. Get them wrong and you've built something impressive in a demo that quietly erodes confidence in production.
Often the most valuable AI barely announces itself. It prepares, sorts, flags and drafts in the background, and the person using the software simply finds their work easier. A product with no chat box at all can still be the most intelligent software in the room.
Design for the wrong answer
Traditional software is deterministic: given the same input, it does the same thing. AI isn't. It's probabilistic, occasionally confidently wrong, and that changes the design problem fundamentally. The interface has to assume the model will sometimes be mistaken and make that failure graceful instead of dangerous.
So we design the unhappy path first — how the user notices an error, how they correct it, how much they should trust a given output, what the safe fallback is. An AI feature that only works when the model is right isn't finished. The design that handles the wrong answer well is what separates a real product from a demo.
Keep the human in the loop that matters
The most durable AI experiences don't try to replace human judgment — they compress the time between a question and a good decision, and leave the decision with the person accountable for it. AI generates the options; the human sets priorities, makes the tradeoffs, and owns the result.
We design for that division of labor deliberately. Automate the toil, surface the options, and preserve human agency at the points that carry consequence. That's not a hedge against the technology — it's how you build something people actually trust enough to rely on.
Where it fits in the method
Every Artifact engagement runs on one method: Understand → Design → Build → Launch → Grow. These are the stages where AI Experience Design does the most work. See how we work.
- 01Understand
We start with the business problem and the job people are doing, then decide whether AI belongs in the product at all — and rule out the places it would only add risk.
- 02Design
AI behavior has to be felt to be judged, so we test working prototypes with real inputs instead of trusting static mockups.
- 03Build
Error handling, correction, trust cues and safe fallbacks get built as first-class parts of the software, not edge cases.
- 04Launch
We watch how people rely on the AI in practice and refine wherever trust and usefulness drift apart.
What you get
- An honest assessment of where AI belongs in your software — and where it doesn't
- Working prototypes of AI features you can actually feel, not just review
- Interaction patterns for trust, control, correction, and graceful failure
- Assistive and generative features designed around real user jobs
- Guardrails and fallbacks that keep the software reliable when the model isn't
- A clear division of labor between the software and the people accountable for decisions
Who it's for
- Teams under pressure to 'add AI' who would rather start from the problem
- Companies unsure whether a problem needs AI, better software, or both
- Leaders wary of shipping AI that looks impressive but erodes user trust
- Organizations that want AI to amplify their people, not sideline them
Proof, not promises
iThink Big
A live assembly program translated into a site that moves like the show and books like a business.
Major Electronics Company
An in-store AR experience showcasing the company's Connected Home products.
Common questions
- Does every product need AI?
- No. Plenty of the software we'd recommend building has little or no visible AI in it. Where AI helps is often in how the software gets researched, designed, built and tested, and in quiet background work the user never has to think about. We'll tell you plainly when a problem doesn't need it.
- Do you build the models, or the software around them?
- The software around them — the interface, the interaction patterns, the trust and control mechanics, and the integration — using capable model providers or your own data science team for the underlying models. Our value is making the technology useful, trustworthy, and genuinely helpful in context.
- Is it too early to invest in AI features?
- It's rarely too early to prototype and learn; it's often too early to bet the roadmap. We favor small, inexpensive experiments that show where AI earns its place before you commit serious engineering to it.
- How do you handle the risk of AI getting things wrong?
- By designing for it from the start rather than treating it as an edge case. We design the error and correction paths, the trust cues, and the safe fallbacks as first-class parts of the experience — because in a probabilistic system, the wrong answer isn't an exception, it's a certainty you plan for.
Get in touch
Wondering whether AI belongs in your software at all?
Tell us the problem. We'll tell you honestly whether software is the answer — and bring the strategy, design, engineering and AI to build it.