Skip to content

services-context.md

Latest commit

 

History

History
136 lines (87 loc) · 3.75 KB

services-context.md

File metadata and controls

136 lines (87 loc) · 3.75 KB

Services context

This repository is written for a professional services design practice, not a single in-house product team.

All guidance here assumes design work is delivered across multiple clients, scopes, and constraints, often without formal authority or long-term product ownership.

This context matters. How design works in services is materially different from how it works in a single, internally owned product environment.

What we mean by “professional services”

In a services context, design work is characterized by:

  • client-owned products, systems, and decisions
  • time- and scope-bound engagements
  • varying levels of client maturity and readiness
  • multiple stakeholders across organizational boundaries
  • designers influencing outcomes without direct authority
  • tradeoffs shaped by contracts, governance, and risk tolerance

This repository reflects those realities.

How to read and use this repository

All practices, guides, and examples should be understood as:

  • adaptable patterns, not fixed processes
  • context-aware, not one-size-fits-all
  • portable, not tied to a single organization or product

Designers are expected to exercise judgment when applying this material, adjusting for:

  • project type and phase
  • access to stakeholders and users
  • delivery constraints
  • regulatory and policy environments
  • client expectations and decision-making structures

Nothing in this repository should be interpreted as mandatory for all engagements.

Project types referenced in this repo

Some documents include a project type to clarify applicability. Common types include:

  • discovery-only
    Short, bounded engagements focused on understanding, framing, and recommendation

  • delivery
    Design and build work with defined outcomes or milestones

  • O&M (operations and maintenance)
    Ongoing service stewardship, iteration, and support

  • hybrid
    Combined or evolving discovery and delivery work

  • varies
    Broadly applicable across project types

Project type is descriptive, not prescriptive. It signals context, not permission.

Authority and influence

Many practices in this repository assume designers are:

  • advising rather than deciding
  • facilitating rather than owning
  • recommending rather than directing

Guidance emphasizes:

  • influence through craft, framing, and facilitation
  • transparency about tradeoffs
  • collaboration across power and organizational boundaries

Where authority is required, it is typically client-held.

Constraints are real

This repository intentionally acknowledges constraints, including:

  • limited time and budget
  • partial access to users or data
  • fixed scope or fixed timelines
  • legacy systems and tooling
  • regulatory and compliance requirements

Design quality in services is achieved within constraints, not by ignoring them.

Examples and templates

Examples and templates in this repository:

  • are sanitized and generalized
  • remove client-identifying details
  • are shared to illustrate approaches, not to be copied verbatim

They should always be adapted to fit client language, goals, and constraints.

Why this context is explicit

Without this context, design guidance often drifts toward:

  • in-house product assumptions
  • idealized authority
  • unrealistic levels of access or control

Making the services context explicit protects:

  • credibility
  • client trust
  • design judgment

It also makes this repository more honest and useful to others working in similar environments.

In summary

This repository exists to support high-quality, responsible design practice in professional services.

It favors:

  • clarity over certainty
  • judgment over prescription
  • adaptation over enforcement

Use it as a guide, not a guarantee.