Skip to content
Sahar Samavati
← All work
Work in progressGanje

Designing beyond the interface

Company / product
Ganje
Role
Product & Service Designer
Status
Work in progress

How do you design better products when the service underneath is fragmented? I developed a service architecture framework that connects operational realities, business requirements and product capabilities across Ganje's logistics services.

The challenge

Connected services, different realities

Ganje's logistics services belong to one ecosystem but have different actors, processes, rules and dependencies. Without a shared structure, dependencies and responsibilities are hard to see.

ReservationFirst-mileMid-mileLast-mileReturnsfailure scenarios and recovery paths (in progress)
The services in scope. First, mid and last mile were mapped; reservation and returns are next.

The framework

Ten dimensions, five questions

I studied “This Is Service Design Doing” and adapted its methods into a framework tailored to Ganje. It links what a service should achieve with how it actually runs and what needs to change.

Intent → people → operation → reality → change. Each service is read through the same ten dimensions.

  1. Why does it exist?

    • 01Service purpose & success criteria

  2. Who is involved?

    • 02Primary & supporting actors

  3. How does it run?

    • 03Business rules
    • 04Channels & touchpoints
    • 05Physical evidence
    • 06Required capabilities

  4. What is really happening?

    • 07Current challenges
    • 08Operational observations
    • 09Why each challenge matters

  5. What should change?

    • 10Opportunities for improvement

Method adapted from This Is Service Design Doing by Marc Stickdorn, Markus Hormess, Adam Lawrence and Jakob Schneider.

How it's applied

One service, read through the framework

I applied the framework to first-mile, mid-mile and last-mile services. The example below shows the method with a made-up scenario, so no internal findings are shared.

Illustrative exampleFictional scenario with generic actors. Not company data.

Scenario: “Pickup-point delivery”

Purpose
Get a parcel from a seller to a recipient's chosen pickup point, intact and on time.
Actors
Seller · Carrier · Pickup point · Recipient
Business rule
A parcel is released only after the recipient is verified.
Touchpoints
Seller app · Notification · Pickup counter
Physical evidence
Label · Receipt · Pickup code
Capability
Tracking · Verification · Notifications
Challenge
Recipients arrive before the parcel has been received.
Why it matters
Wasted trips and avoidable support contacts.
Opportunity
Notify only once the parcel is confirmed at the pickup point.

From service to product logic

Partner requirements became configurable rules

One concrete outcome: different partner requirements are now represented as configurable rules in the backend, instead of a separate fixed flow for every partner.

This was a product and engineering outcome informed by my service-design work. I did not write the backend code.

Before · a fixed flow per partner

  • Partner A
  • Partner B
  • Partner C
Every variation becomes its own process.

After · one structure, configurable rules

Partner A needs
Partner B needs
Partner C needs

Shared service structure

  • Extra ID field: on / off
  • Proof of handover: code / scan
  • Holding period: n days

→ partner-specific flows

Illustrative rulesRule names are generic examples.
Conceptual diagram. Partners and rules are generic examples.

Who did what

My part, the team's part, and what's open

  • I designed: the framework and its ten dimensions
  • I did: applied it to three services and identified challenges and opportunities
  • Built together: configurable partner rules (product & engineering)
  • Still open: service specs, handovers, failure and recovery, reservation and returns