Skip to content
This repository has been archived by the owner on Mar 2, 2020. It is now read-only.

Commit

Permalink
Merge pull request #33 from AusDTO/fixes#32
Browse files Browse the repository at this point in the history
Narrowed conformance criteria, emphasised simplicity and eco rationale
  • Loading branch information
monkeypants committed Aug 5, 2015
2 parents 3b018cd + bb41a95 commit c340036
Showing 1 changed file with 7 additions and 3 deletions.
10 changes: 7 additions & 3 deletions principles/empathy.rst
Original file line number Diff line number Diff line change
Expand Up @@ -3,8 +3,12 @@ Developer empathy

**Design with developer empathy**

Developers are users too and the same principles of user-centred-design apply to the development and publishing of APIs – except that your user is a developer that wants to consume your API rather than an end user that is a customer for the government service or data. Most of the other criteria in this guide are traceable to this criteria.
When it comes to APIs, developers are your users. The same principles of user-centred-design apply to the development and publication of APIs (simplicity, obviousness, fit-for-purpose etc). Most of the other criteria in this guide are traceable to the principles of good design. Perhaps the most important criteria to be mindful of is *simplicity*: as with any other product, people simply won't use something if it is hard to use.

All Government APIs will be published to a central service register as described in Building and publishing APIs. The service register will provide a mechanism for developers to provide feedback on APIs. An API that is consistently rated as hard to use should be considered defective.
Hard-to-use APIs create bad public policy outcomes:
- Potentially significant economic value will remain undiscovered or unrealised
- Secondary markets that form around APIs (e.g. automated tax reporting software) will be less competitive, and therefore less efficient (API complexity creates barriers to market entry)

**Conformance Criteria:** less than 20% of feedback rates the API as poor.
To ensure dicoverability and accountability, all Government APIs will be published to a central service register (as described in Building and Publishing APIs secion [insert link]). The service register will give developers a mechanism to provide feedback on APIs. An API that is consistently rated as hard to use will be deemed defective and should be remediated.

**Conformance Criteria:** less than 20% of feedback rates the API as hard to use.

0 comments on commit c340036

Please sign in to comment.