Narrowed conformance criteria, emphasised simplicity and economic rat…

…ionale

Have narrowed the conformance criteria slightly. We should probably sit down and work out our full set of criteria, with an eye to keeping it short and simple. This will also make it less burdensome for developers to provide feedback, and easier for agencies to run through the full conformance suite. Have also placed a stronger emphasis on 'simplicity', and given the public policy rationale as to why we want to make it easy for developers to use our APIs.

principles/empathy.rst

@@ -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.