cityconnect
Cityconnect is a Priocity application concept that reached the design phase and could become a future product under Palisis. The platform explores how a city can manage its main attractions, public transportation, events, and other shared services while creating clearer work opportunities for the people who keep the city moving.
Client
Priocity
Year
2024
Project type
Service Design, Product UX/UI & Platform Concept
Credits
Douglas Lansky
Service Design
UX / UI
City Platform
Product Concept
Problem
Cities manage many connected experiences: attractions, museums, events, buses, public transportation lines, and the people who operate them. These systems are often fragmented, making it difficult to create a clear overview of what is happening and how different services support one another. Cityconnect explored how one platform could make a city’s shared infrastructure easier to organize, develop, and operate.
Role & Scope
I designed the product experience and service structure for Cityconnect, covering the UX/UI, platform direction, information architecture, and the relationship between city services. The work explored how the product could serve city authorities, operators, attraction managers, event teams, and the people responsible for creating and maintaining work opportunities.
Outcome
Cityconnect reached the design phase as a Priocity application concept. It created a possible foundation for a future Palisis product: a connected city platform for managing attractions, transportation, events, and the operational network behind them.
Timeline
Service exploration, platform strategy, information architecture, UX/UI design, and concept definition.
Context & Constraints
The challenge was to give a complex city ecosystem one understandable digital structure without hiding the different responsibilities and realities inside it.
◉
A city’s attractions, events, bus routes, and public transportation lines are connected but often managed in separate systems.
◉
The platform needed to serve both strategic city development and day-to-day operational work.
◉
Different operators and services require different tools while still contributing to one shared overview.
◉
The concept needed enough potential to become a future Palisis product while remaining grounded in the needs of a real city.
Process
01
Discovery & Problem
We began by looking at the city as an ecosystem rather than a collection of separate services. Attractions, transport, events, and employment all influence one another, but the digital experience rarely makes those relationships visible.
02
Research & Principles
The work was guided by three principles: make the city easier to understand, make operations easier to coordinate, and make the people behind the services more visible. The platform needed to support both a broad strategic view and focused operational tasks.
03
Ideation & Creation
I shaped Cityconnect as a platform concept that could bring city attractions, museums, experiences, buses, public transportation lines, and events into one connected structure. The goal was not to flatten each service, but to give them a shared layer for planning and management.
04
Service & Platform Design
The experience was organized around the different actors and services that make a city work. This included the ability to manage public-facing experiences as well as the operational and employment structures needed to deliver them.
05
Concept Evaluation
Cityconnect remained in the design phase, but the concept was evaluated as a possible future product direction under Palisis. The work helped clarify how existing platform capabilities could expand into a broader service ecosystem for cities and local authorities.
Design Decision
Separate Services vs Connected City Platform
The central question was whether city services should remain separate or be brought together through a shared platform that makes their relationships easier to manage.
Option A
Design separate tools for each city service
Option B
Create one connected platform with service-specific areas
Chose: A connected city platform
Cityconnect uses a shared platform structure while allowing attractions, transport, events, and operations to maintain their own needs. The connection creates a clearer overview without requiring every service to work in exactly the same way.
Design Decision
Citizen-facing Experience vs Operational Infrastructure
A city platform can focus only on what citizens see, or it can also support the people and systems that make those experiences possible.
Option A
Focus primarily on public-facing attractions and events
Option B
Connect public experiences with operational and employment systems
Chose: Experience plus infrastructure
The concept connects what people experience with the infrastructure behind it. Managing transport, events, attractions, and work positions together creates a more realistic foundation for how cities grow and operate.
Learnings
◉
Service design becomes more valuable when it makes invisible work visible. The city experience depends on many operators, planners, drivers, event teams, and managers working behind the scenes.
◉
A shared platform does not require identical workflows. The right foundation can support different services while giving them a common language and connected data.
◉
Complex products become easier to reason about when they are organized around real actors and responsibilities rather than only around features.
◉
A design-phase concept can still influence product strategy. Cityconnect opened a possible direction for how Palisis could support cities beyond individual attractions or ticketing products.
What I'd do differently
◉
I would validate the concept with a wider group of city authorities, transport operators, attraction managers, and event organizers before defining the first product scope.
◉
I would identify one concrete city workflow to pilot first, such as coordinating event transport or managing a network of attractions, before expanding into the wider ecosystem.
◉
I would map the relationships between services, people, and data in more detail to define which parts should be shared at platform level.
◉
I would create a clearer commercial and implementation path for a future Palisis version, including the first buyer, first deployment context, and minimum viable service set.
Next project
