Platform of Trust Platform Design Guide
Developer PortalAPI DocsOntology
  • Purpose and scope
  • Developer eXperience Strategy
  • Suggest changes
  • API Requests
    • Request validation
    • Response codes used
    • Error handling
  • General API guidelines
    • Performance
    • Documentation
    • Data models used
    • Use HATEOAS
    • Use HTTP Methods
    • Dates and time
    • Naming conventions
    • Pagination, partial response and sorting
    • API Testing
  • API Headers
    • Mandatory elements & behaviour
    • Rate limiting information
  • API Security
    • Authentication and authorization
    • SSL everywhere - all the time
  • API versioning guidelines
    • Versioning Rules
    • Breaking changes
    • Non-breaking changes example
    • Retirement process
    • Add new API to documentation
    • Add new endpoint
  • API Migration Policies
    • Deprecating API
    • Sunsetting API
    • Blackout Testing
    • Migration Email Template
    • API Blackout Test Email Template
    • API Deprecation Email
    • Deprecating an older API
  • Ontologies
    • About ontologies
    • Web Ontology Language, OWL
    • Ontology editor
    • Edit ontology
    • Add new subclass
    • Naming convention logic
    • Extending the ontology
  • Design Guideline
    • Colors
    • Typography
    • Grids and Space
    • Input forms - Text field
    • Input forms - Text area
    • Buttons
    • Checkbox
    • Radio buttons
    • Date picker
    • Form control - Single select
    • Toggle
    • Pagination
    • Status pills
    • Tables
    • Effects
    • Dialogues
Powered by GitBook
On this page
  • Developer in the center
  • Enable flow state
  • Support workflows
  • Self-service tools
  • Be in the front-line in global level

Was this helpful?

Developer eXperience Strategy

The below principles define the strategy, high level guidance on Developer eXperience development. If you are wondering if your idea on DX development should be discussed further, then see if you can justify it with the below principles. If your idea implement the principles, then it probably is a pretty damn good idea and you should raise it in Slack.

Developer in the center

understand the needs and workflows of our customer. We need to know who the customers are, how they use our services, what kind of frameworks and tools they use, are they hobby developers, professional developers or something else? We do not proceed product-first, we value customer-first approach more.

Enable flow state

help developers be more productive and happy. Developers are hunting flow state all the time. That is when they are most productive and challenges gets solved. Our DX must enable their flow states and make it easier get into flow state after a break easily.

Support workflows

End-to-end support, understand how our customers use ourt platform in their daily work, what role it has, how we take away the pain.

Self-service tools

enable 24/7 usage,

Be in the front-line in global level

Requires experimentations and culture of fast failure. We can't be int he frontline if we do not take calculated risks and experiments. Our benchmark are the global leaders of API and platform economy.

PreviousPurpose and scopeNextSuggest changes

Last updated 5 years ago

Was this helpful?