Client-facing Vocabulary
Department
Summary
Plain-language definitions of tech concepts for client conversations. Use when explaining UX, UI, web vs app, CMS, hosting, and more. For detailed process and policy, see the linked guidelines.
Table of Contents
| Section | |
|---|---|
| 1 | Summary |
| 2 | Purpose |
| 3 | Scope |
| 4 | Glossary |
| 5 | Related Documents |
Purpose
This document provides plain-language definitions so Sales, AE, and other client-facing roles can explain tech concepts confidently. Shared vocabulary reduces misunderstandings and long conversations without alignment.
| Outcome |
|---|
| Client-facing roles can explain tech concepts in plain language and spot when the client does not understand. |
Scope
This document covers:
| Included | |
|---|---|
| 1 | Design terms (UX, UI, wireframe, prototype, user flow, responsive, component, high-fidelity) |
| 2 | Tech terms (web, app, CMS, API, MVP, database, backend, frontend, authentication, 2FA) |
| 3 | Infrastructure terms (hosting, domain, DNS, cache, staging, production, DEV, HTTPS, SSL, MA, backup, server, CDN, load time) |
| 4 | Delivery terms (scope, deliverables, milestones, UAT, QA, bug report, deployment, go-live, rollback, downtime, change request, change order, kickoff, sign-off, handover, sprint, incident, migration) |
| 5 | Other (SEO, unit test, landing page, accessibility) |
For detailed process, policy, and pricing, see Scope Definition & Price Assessment Guideline, Maintenance & Hosting Guideline, UX Workflow, UI Workflow, and Client Acceptance (UAT) & Go-Live Guideline.
Glossary
| Term | Definition |
|---|---|
| 2FA | Two-Factor Authentication. A second step to verify identity (e.g. code by SMS or app). Adds security beyond password alone. |
| Accessibility | Designing so people with disabilities can use your product—screen readers, keyboard navigation, contrast, captions. Often required by law and improves usability for everyone. |
| API | A way for different systems to talk to each other and share data. E.g. your website syncing with a CRM or payment gateway. |
| App | Software installed on a device (mobile, desktop). Downloaded from an app store or installer. Pros: full device access (camera, push, offline), app store presence. Cons: installation friction, two codebases (iOS + Android), app store approval, higher cost. Choose when: heavy mobile use, need push/camera/offline, want app store presence. |
| Authentication | Verifying who a user is—usually with username and password. Different from authorization (what they’re allowed to do). |
| Backend | The server-side part of a system. Handles data, logic, and processing. Users don’t see it directly. Works with the frontend (what users see). |
| Backup | A copy of your data stored separately. Used to restore if something goes wrong. |
| Bug report | A structured report of an issue: what you did, what you expected, what happened. Include evidence (screenshot), steps to reproduce, and expected vs actual. See Bug Report Guideline. |
| Cache | Temporary storage of data to speed up loading. Browsers and servers cache pages. If you see old content after an update, clearing cache often fixes it. |
| CDN | Content Delivery Network. A network of servers that serves your static files (images, CSS, JS) from locations close to users. Speeds up load time globally. |
| Change order | A formal change to the agreed scope. Requires sign-off and may affect timeline and cost. See Contracting & Change Order Workflow. |
| Change request | A request for something new or different from the agreed scope. Not a bug fix. Becomes a change order when approved. |
| CMS | Content Management System. Lets non-technical users edit website content (text, images) without writing code. |
| Component | A reusable UI building block (button, card, header). Design systems use components for consistency. |
| Database | Where your data is stored—users, content, transactions. Runs on the server. Different from the frontend (what users see). |
| Deliverables | Concrete outputs we produce—wireframes, design files, working code, documentation. Each has a clear “done” definition. |
| Deployment | Pushing the built system to the server so it goes live. “We’re deploying” = we’re making the update live. |
| DEV | Development environment. Where we build and test during development. Not for client testing. |
| DNS | Domain Name System. Maps your domain (e.g. yourcompany.com) to the server where your site lives. When you buy a domain, DNS records tell browsers where to find your site. |
| Domain | The web address (e.g. yourcompany.com). Can be paid (you own it) or a free subdomain we provide. |
| Downtime | When the site or system is unavailable. We plan deployments to minimize downtime. |
| Frontend | What the user sees and interacts with—the website or app interface. Works with the backend (data, logic). |
| Go-live | Launch day. When the system goes from staging to production and becomes live for users. |
| Handover | The formal transfer of the project, access, and knowledge to the client at the end of the engagement. |
| High-fidelity | A design or prototype that looks close to the final product—real colors, typography, content. Used for stakeholder review before development. |
| Hosting | Infrastructure where your website runs—servers, environments. Has a creation date and expiration. Like renting space for your site. |
| HTTPS | Secure version of HTTP. Encrypts data between browser and server. The padlock in the address bar. Required for secure sites. |
| Incident | An unplanned event that disrupts service (outage, security breach). We track and resolve incidents, then report on cause and prevention. |
| Kickoff | The first project meeting where we align on scope, timeline, roles, and next steps. Marks the official start of work. |
| Landing page | A single page focused on one goal (e.g. sign up, download). Often used for campaigns or ads. |
| Load time | How long it takes for a page or asset to become usable. Affected by server speed, CDN, images, and code. |
| MA (Maintenance Agreement) | Maintenance support—unlimited bug fixes for a defined period. Separate from hosting. Paid annually. |
| Milestones | Checkpoints in the project timeline. Points where we review progress and decide on next steps (e.g. design complete, UAT ready). |
| Migration | Moving data or a system from one place to another (e.g. old site to new, one host to another). Requires planning and testing. |
| MVP | Minimum Viable Product. The smallest version that delivers core value. Launch fast, learn from real users, then iterate. |
| Production | The live environment. The real site users see. |
| Prototype | An interactive mockup users can click through to test the flow. Used for validation before development. |
| QA | Quality Assurance. The testing phase before release. QA checks that the system works as expected. |
| Responsive | Design that adapts to screen size—mobile, tablet, desktop. One site that works well on all devices. |
| Rollback | Reverting to a previous version if something goes wrong after deployment. Part of our go-live plan. |
| Scope | What we will build—features, deliverables, boundaries. Defined and signed off before work starts. |
| SEO | Search Engine Optimization. Practices to help your site rank in search results (Google, etc.). |
| Server | A computer that hosts your site or app and responds to requests. Can be physical or cloud-based. |
| Sign-off | Formal approval from the client at a milestone (e.g. design, UAT). Confirms we can proceed to the next phase. |
| Sprint | A fixed time period (e.g. 2 weeks) for work. Agile teams plan, build, and review in sprints. |
| SSL | Secure Sockets Layer (or TLS). The technology that encrypts HTTPS connections. “SSL certificate” = the certificate that enables the padlock and secure connection. |
| Staging | A copy of the site used for final testing before go-live. Mirrors production but is not public. |
| UAT | User Acceptance Testing. The phase where the client tests the system before go-live and decides if it meets acceptance criteria. |
| UI (User Interface) | What the user sees and interacts with—layout, buttons, colors, typography. The visual layer. We design this after UX. |
| Unit test | Automated tests that check individual pieces of code. Done by developers during build. Different from QA (manual testing) and UAT (client testing). |
| User flow | A diagram showing the path a user takes to complete a task (e.g. sign up → verify email → complete profile). |
| UX (User Experience) | How a user feels when using a product—ease of use, flow, clarity. We design the flow (UX) before the look (UI). |
| UX vs UI | UX = experience and flow. UI = visual design. UX comes first; UI follows. Both matter for a good product. |
| Web | A website accessed in a browser on any device. No installation required. Pros: works everywhere, easier to update, lower cost, SEO possible. Cons: limited device features (camera, push), may feel less “native.” Choose when: content-heavy, users find you via search, budget-conscious, quick to launch. |
| Web app | A website that behaves like an app—responsive, interactive, can work offline (PWA). No app store. Pros: no app store, single codebase, can add to home screen. Cons: not in app stores, some device features limited. Choose when: want app-like experience without app store, progressive enhancement. |
| Wireframe | A low-fidelity sketch of page structure, layout, and content hierarchy. No colors or final design. Like a floor plan for your website. |
Related Documents
| # | Document | Purpose |
|---|---|---|
| 1 | Scope Definition & Price Assessment Guideline | Deal flow, scope, proposal, contract |
| 2 | Maintenance & Hosting Guideline | Hosting types, MA pricing, renewal |
| 3 | UX Workflow & Process Guideline | UX process, wireframes, prototypes |
| 4 | UI Workflow & Process Guideline | UI process, design handoff |
| 5 | Client Acceptance (UAT) & Go-Live Guideline | UAT flow, go-live |
| 6 | Bug Report Guideline | How to report bugs |
| 7 | Contracting & Change Order Workflow Guideline | Change orders |