Request for Proposals
WayKeeper Service Design, UX Integration, and Tenant Packaging for OS-CONNECT
A practical front door for Washington’s pedestrian accessibility data infrastructure, and a repeatable service model for future states, regions, countries, funders, and implementation partners.
Table of contents
Use this RFP to understand the opportunity, scope, deliverables, and response requirements.
1. The opportunity
Washington built the data. Now people need a clear path into it.
Washington has completed the first full-scale deployment of OS-CONNECT: a complete statewide sidewalk inventory and pedestrian accessibility mapping dataset, hosted within the Transportation Data Equity Initiative infrastructure. The work created a reusable public asset: data, QA/QC reports, routing and analysis tools, update pathways, and the foundation for ongoing stewardship.
The immediate need is practical. Washington jurisdictions, residents, planners, transit agencies, contractors, advocates, and community partners need a clearer way to find the right resource, understand what they are looking at, and act on the data.
2. Vision and strategic premise
Design for Washington now, and for future tenants who need living pedestrian and bike-way data.
Washington is the first full-scale deployment case. The immediate need is to make OS-CONNECT easier for Washington jurisdictions, residents, planners, transit agencies, contractors, and advocates to find, understand, and use.
At the same time, TCAT and TDEI are preparing for future tenants that may want to adopt the same infrastructure. Future tenants may include states, countries, regional agencies, MPOs, transit providers, or other public-sector partners that need a complete pedestrian accessibility data system.
The longer-term vision is that every state and nation should be able to maintain its own living dataset for pedestrian and bike ways, supported by an ecosystem of tools to consume and use the data, maintain and update the data, and provide stewardship and guardianship over time.
Use the data
Routing, walksheds, dashboards, public-facing tools, planning workflows, transit access analysis, and local prioritization.
Maintain the data
Local updates, contractor close-outs, community comments, field validation, QA/QC, and periodic refreshes.
Steward the data
Documentation, policy kits, governance supports, funding stories, support pathways, and public accountability.
3. What the system includes
One data infrastructure, many users, tools, dashboards, stories, and support pathways.
OS-CONNECT is not only a dataset. It is the first deployment of a broader pedestrian accessibility data infrastructure. The selected partner should help make this system legible to users, future tenants, funders, donors, elected officials, and implementation partners.
OS-CONNECT dataset
Sidewalks, crossings, curb nodes, pedestrian pathways, and connected accessibility data.
QA/QC reports
Completeness, quality checks, feature counts, topology findings, and local review guidance.
OS-CONNECT Viewer
Jurisdiction and public access to mapped pedestrian infrastructure data.
AccessMap
Traveler-facing routing based on pedestrian network conditions and mobility preferences.
Walksheds
A planner-facing tool to calculate reachable areas to or from destinations at selected travel-time thresholds and modeled traveler profiles.
Where to Live / Livability tool
A public-facing comparison tool that helps people compare access to amenities, services, transit, and daily needs from two or more locations.
AVIV ScoutRoute
Accessibility Verification Improved Validation: structured field validation, community campaigns, contractor updates, and infrastructure-linked comments.
Analytics products
Safe Routes to School, access to transit, access to goods and amenities, Where to Live / Livability comparisons, health/environment correlations, and more.
Office hours and pilots
Guided support for jurisdictions and partners moving from data review to use.
Policy kits and stories
Materials that help local advocates and bureaucratic change-makers explain nondriver access and make local action visible.
4. The challenge
The infrastructure is powerful, but the pathways into it are not yet clear enough.
No clear starting point
Users need to know where to begin, which link applies to them, and what to do next.
Disconnected workflows
The Viewer, reports, tools, support, comments, and pilots need clearer handoffs.
Fragmented identity
The same system appears under multiple names and visual languages, making it harder to explain.
Unpackaged service model
Future tenants need to understand what they can adopt, what it costs, and what support is included.
The selected partner should treat visual identity as a tool for clarity and trust. The core task is to reduce friction and make the system operationally legible.
5. Desired outcomes
Four outcomes, one coherent system.
1. Usable Washington front door
A WayKeeper landing experience at waykeeper.tdei.us that helps Washington users find data, reports, tools, support, pilots, policy kits, and next steps.
2. Shared workflow architecture
Clear journeys and handoffs for jurisdictions, residents, planners, transit partners, contractors, advocates, and TCAT support staff.
3. Accessible identity and content system
A neutral, high-contrast, repeatable visual and language system that clarifies how WayKeeper, OS-CONNECT, TDEI, AccessMap, Walksheds, the Where to Live / Livability tool, AVIV ScoutRoute, dashboards, and policy kits relate.
4. Tenant and supporter packaging
A service model that explains what future tenants, funders, donors, and implementation partners can adopt, support, or fund.
6. Required scope of work
Applicants should price each workstream separately and explain dependencies.
| Workstream | Required work | Expected output |
|---|---|---|
| 1. Current-state service and asset inventory | Inventory tools, URLs, repositories, dashboards, user stories, pilots, reports, media exposure, documentation, support pathways, and implementation dependencies. | Asset inventory, gap analysis, ownership/dependency map, and prioritized opportunity list. |
| 2. Washington user journeys and front door | Design a role- and task-based WayKeeper entry point for jurisdictions, residents, planners, transit providers, contractors, advocates, data/API users, supporters, and future tenants. | Information architecture, page map, content structure, and build-ready or built front door. |
| 3. Workflow architecture | Map and redesign flows for Viewer use, QA/QC interpretation, completeness explanation, comments, local updates, field updates, Walksheds, AccessMap, pilots, office hours, SCLIO, and multi-jurisdiction requests. | Service blueprint, user-flow diagrams, handoff map, and implementation backlog. |
| 4. Dashboard and use-case architecture | Inventory and organize dashboard concepts and user stories, including Safe Routes to School, access to goods and amenities, Where to Live / Livability, access to transit, specialized transit, health/population correlation, environmental access, and emergency resilience. | Dashboard taxonomy, status map, user story matrix, and recommended page templates. |
| 5. Identity, naming, and content system | Clarify naming architecture and visual consistency across WayKeeper, OS-CONNECT, TDEI, AccessMap, Walksheds, AVIV ScoutRoute, dashboards, and policy kits. | Accessible visual system, naming architecture, content style guide, and lightweight brand guidelines. |
| 6. Tenant service model and supporter packaging | Create a service model for future states, countries, regions, agencies, donors, supporters, and implementation partners. | Service packages, pricing logic, cost-driver framework, tenant onboarding journey, supporter pathways, and proposal/collateral templates. |
| 7. Implementation-ready handoff | Prepare assets for TCAT developers and partners to implement and maintain. | Static site or prototype, design tokens, reusable components, resource config, content files, README, and roadmap. |
7. Priority workflows
The RFP is organized around tasks, not only audiences or product names.
Jurisdiction self-orientation
Open Viewer link, read QA/QC report, understand completeness, inspect known places, choose a pathway, request support.
Community and contractor comments
Attach observations to a sidewalk, curb, crossing, path, or place so barriers, disruptions, improvements, and temporary or permanent changes are operationally visible.
Planner analysis
Run or request Walksheds, use dashboard outputs, interpret modeled traveler profiles, and connect analysis to local priorities.
Regional and transit access
Support agencies whose work spans multiple jurisdictions, including transit, specialized transportation, MPOs, counties, and cross-boundary service providers.
Policy kit use
Help local bureaucratic change-makers, advocates, and nondriver coalitions use shared materials with electeds, agency leaders, and legislators.
Future tenant inquiry
Help a new state, nation, or region understand readiness, collection needs, service packages, persistence, and remapping requirements.
8. Future tenant service model
Applicants should help package the infrastructure for future states, countries, regions, and agencies.
The selected partner will not be responsible for setting final prices. The selected partner should help TCAT define service packages, pricing logic, cost drivers, assumptions, one-time versus annual services, and a clear tenant onboarding journey.
Discovery and readiness
Needs assessment, existing data review, imagery/source review, use-case prioritization, pilot geography, implementation roadmap, and cost assumptions.
Baseline collection and publication
AI-assisted extraction, human/AI vetting, schema alignment, Viewer publication, initial QA/QC reports, and tool integration.
Supported adoption
Onboarding, report interpretation, office hours, guided pilots, local update pathways, dashboards, community feedback, and training.
Persistence and stewardship
Hosting, APIs, Viewer, QA/QC reports, AccessMap, Walksheds, update workflows, comments, issue tracking, dashboard support, reporting, and stewardship planning.
Statewide or regional refresh
Imagery review, model retraining, inference, QA/QC, local review, publication, tool rebuilds, and refreshed reports.
Supporter and donor pathways
Ways for donors, funders, and supporters to sustain public-interest data infrastructure, community validation, accessibility testing, pilots, and dashboard development.
9. Policy kits and public narrative
Make nondriver experience clear, visible, and actionable.
WayKeeper should make room for policy kits that any jurisdictional bureaucratic change-maker, advocate, or community partner can use with local elected officials, agency leaders, legislators, funders, and public audiences.
These kits should help users change the narrative around nondrivers: from isolated complaints about individual barriers to a clear public-interest case for connected pedestrian and bike-way infrastructure, accessibility, safety, transit access, health, community participation, and public accountability.
Local story kit
Plain-language materials that explain what nondrivers experience and why connected pedestrian data matters.
Data-to-action kit
Templates that connect Viewer findings, QA/QC reports, Walksheds, AccessMap examples, and local comments to decisions.
Decision-maker kit
Briefs, talking points, slides, and one-pagers that local champions can use with electeds, agency leaders, funders, and legislators.
10. Required deliverables
Applicants should explain how each deliverable will be produced and handed off.
- Current-state inventory of tools, dashboards, repositories, URLs, user stories, pilots, proof points, documentation, and support paths.
- Role and task matrix for Washington users, future tenants, donors, supporters, and implementation partners.
- Service blueprint and workflow maps for priority user journeys.
- Information architecture for waykeeper.tdei.us.
- Build-ready or built public landing page with role-based navigation.
- Plain-language content system and FAQ structure.
- Accessible design system with neutral visual identity, color, typography, tokens, and reusable components.
- Naming architecture explaining WayKeeper, OS-CONNECT, TDEI, AccessMap, Walksheds, the Where to Live / Livability tool, AVIV ScoutRoute, dashboards, policy kits, and tenant services.
- Tenant service package model with pricing logic and cost drivers.
- Policy kit architecture and templates.
- Implementation handoff package, including README, content files, resource configuration, and backlog.
11. Optional add-ons
Applicants may propose additional capacity as separate line items.
Lightweight CMS
Support for TCAT staff to update pages without developer intervention.
Usability testing
Testing with disabled users, screen-reader users, jurisdiction staff, planners, transit partners, and advocates.
FAQ and guide buildout
Content for QA/QC reports, completeness, pilot joining, multi-jurisdiction access, imagery, and remapping.
Dashboard landing pages
Templates for Safe Routes, transit access, access to goods and amenities, Where to Live / Livability, health/environment, and emergency resilience dashboards or tools.
Policy kit templates
Editable one-pagers, slide templates, briefing language, and local story patterns.
Supporter collateral
Materials for donors, funders, and implementation partners.
12. Timeline
Applicants may propose an alternate timeline, but should provide shippable checkpoints.
13. Proposal requirements and evaluation
Please price core deliverables separately and identify assumptions clearly.
Include in your proposal
- Your read on the problem and proposed approach.
- Work plan, milestones, and timeline.
- Separate pricing for each required workstream and optional add-on.
- Day rates, estimated effort, named team members, and roles.
- Relevant examples of civic UX, accessibility, public-sector data tools, service design, documentation, or complex product ecosystems.
- Accessibility approach, including screen-reader, keyboard, contrast, plain-language, and usability testing practices.
- Developer handoff approach.
- Approach to future tenant service packaging and cost-driver modeling.
How proposals will be evaluated
Workflow clarity
Can you reduce user friction and make next steps obvious?
Accessibility fluency
Do you design for disabled users from the beginning?
Civic and data-product experience
Have you worked on public-interest tools, maps, data portals, or government workflows?
Implementation realism
Can TCAT developers and partners actually use your handoff?
Service packaging
Can you translate a complex public-interest system into credible service packages for future tenants and supporters?
Focus and value
Do you avoid over-scoping brand work and prioritize functional outcomes?
14. Resource inventory
The selected partner will receive a fuller resource inventory at kickoff.
Applicants should assume that resources include existing public tools, reports, dashboards, repositories, pilots, media, policy materials, and support workflows. Exact URLs and repository references will be confirmed during kickoff.
| Resource type | Examples | Expected vendor action |
|---|---|---|
| Tools and platforms | OS-CONNECT Viewer, TDEI Portal/API, AccessMap, Walksheds, Where to Live / Livability tool, AVIV ScoutRoute | Inventory, organize, and define front-door handoffs. |
| Reports and data products | QA/QC reports, completeness outputs, topology/connectivity findings, release metadata | Define plain-language pathways and report-reading guidance. |
| Dashboards and analytics | Safe Routes, transit access, goods/amenities, Where to Live / Livability, emergency resilience, health/population correlations | Create taxonomy, status model, and page templates. |
| Stories and proof points | Goldendale/Gorge Transit, specialized transit facilitators, community events, Safe Routes, emergency resilience, media exposure | Organize evidence into reusable story and support pathways. |
| Policy kits | Briefs, talking points, slides, local story templates, nondriver narrative materials | Create structure and templates for local use. |
| Support pathways | Office hours, pilot intake, SCLIO, help documentation, FAQ | Design task-based support flows. |
Boundary: what this RFP does not ask you to do
This RFP does not ask the selected partner to rebuild AccessMap, Walksheds, the Where to Live / Livability tool, AVIV ScoutRoute, TDEI, the OS-CONNECT Viewer, or the data pipelines. The work is to design and, where scoped, implement the front door, shared language, workflow architecture, design system, service packaging, and handoff materials that make the existing and emerging ecosystem easier to use.