这为何对公共价值重要

如今每一个公共机构都运行着至少一项数字服务,而大多数领导者都能拿出一份商业论证,承诺更低的成本、更快的处理速度,以及更满意的公民。这些论证中太多只兑现了这三者中的第一个。一个数字化的流程,如果仍然把一个不典型的案例送经五个部门,并没有被转型;它仍然是同一个碎片化的流程,只是套上了一个更快的前端,而公民仍然体验着这种碎片化,只不过如今是在一个看起来简单的表格背后。

数字化的压力只增无减:预算更紧张,处理纸质表格的员工更少,而在网上银行与购物的公民,合理地期望从一次执照续期或一笔福利申请中获得类似的体验。与此同时,真正有一小部分公民无法、或不愿意完全在线上办理事务,而一项被草率推行的数字优先战略,会把一个柜台前的队伍,变成对恰恰是一项公共服务存在的意义所要触及的那些人的永久障碍。

这正是数字政府与公共价值理论直接交汇的地方。一项数字化转型项目,能够加强一项服务的运营能力——马克·摩尔战略三角的第三条边(见主题1.2——战略三角:合法性、价值与能力)——同时却悄悄侵蚀合法性与支持,如果那些最没有能力为自己发声的公民,被这次重新设计抛在了后面。领导者的任务不是在数字效率与包容性之间做出选择;而是设计一项让两者同时成立的服务,并用证据、而非假设,去了解这一点是否真的正在发生。

主题3.1把数字时代治理置于一套更广泛的行政范式类型学之中——层级、市场、网络与平台——并主张它的界定性举动,是重新整合早期改革浪潮所碎片化的东西(见主题3.1——公共行政体系与模式)。本主题把这套范式带入实践:一项服务如何围绕公民的需求来设计、一套数字优先的交付战略要求一个组织承诺什么,以及共享基础设施如何让许多服务不必各自重复发明同样的组件。

核心概念

数字政府,有时也称为电子政务,是使用信息技术来交付公共服务、并进行政府、公民、企业与政府自身员工之间原本需要一份纸质表格、一次柜台访问,或一通电话的交易。这个术语涵盖了从一个静态信息网站,到一项从头到尾完全在线完成的交易型服务的一切;本主题关注的是这个谱系中交易的那一端,以及良好的交易型服务所要求的组织变革。

服务设计是把一项服务的整体——数字界面、支撑它的后台流程、处理例外情况的员工,以及与数字渠道并列的实体或电话渠道——当作一次单一、连贯的体验来设计的学问,而非各自独立、恰好不至于严重冲突的项目。服务设计从运营管理中借用了一件核心工具——服务蓝图,它把公民所采取的每一步,与一个组织在幕后支持它所采取的每一步相对照绘制出来,使大多数数字失败真正发生的那些交接点变得可见。

以用户为中心的设计是嵌套在服务设计之内、范围更窄的学问,即围绕将要使用它的人的需求、能力与心智模型,来设计一次具体的互动——一份表格、一个页面、一项应用——通过与他们的直接研究来确立,而非在组织内部凭假设得出。以用户为中心的设计坚持认为,构建一项服务的人,在结构上是判断它是否可用的最差人选,因为他们早已知道每一个按钮的作用;只有与不知道这一点的人一起测试,才能弥合这个差距。

数字优先,有时被正式称为"默认数字化",是一种交付战略,在这种战略下,数字渠道被构建为完成一次交易的最佳、通常也是唯一被积极推广的方式,而其他渠道被保留给无法使用它的人。这项战略是一种真正的权衡,而非一种免费的效率收益:它把投资集中在一个渠道上,这能为大多数人产出一项显著更好的服务,但只有在这个组织对数字渠道触及不到谁同样刻意关注时,它才创造公共价值。

数字排斥,是指由于准入、技能、信心、残障、语言或境况的原因,即便一个数字渠道被提供出来,也无法通过它完成一次交易的状况——这是更广泛的数字鸿沟在服务层面的一个实例,后者是指跨越收入、教育、地理与年龄的更广泛的数字技术不平等准入模式。辅助数字服务,是为经历数字排斥的人有意提供的人力帮助——通过电话、面对面,或通过一个受信任的中介——被设计为服务中一流的组成部分,而非一个没有人为其规划能力的剩余备用方案。

政府即平台是技术评论家蒂姆·奥莱利于2010年命名并加以论证的一种模式,即一次性以高标准建立起少数几件共享的、可重复使用的基础设施——通常是身份验证、支付、通知与文件交换——使众多个别服务能够建立在它们之上,而非各自重建自己的版本。爱沙尼亚自2001年起建立、此后被多个其他国家采纳或改编的X-Road数据交换层,是这种模式在国家规模上被广泛引用的一个真实实例。让共享组件能够跨越组织边界安全地交换信息的数据共享与互操作性标准,本身就是一个重要主题(见主题5.4——公共部门数据、互操作性与开放数据);本主题把政府即平台当作一种服务设计与治理模式来处理,而这类组件如何被构建、购买或现代化的工程选择,则属于软件交付这一方面的主题(见主题5.3——公共部门软件工程与平台)。

数字身份是一项基础性的共享平台组件:一种经过验证的、可重复使用的方式,用以确立一位在线用户确实是他所声称的那个人,这一次性建立起来,使得一项税务服务、一项福利服务与一项许可服务,不必各自独立地解决身份验证问题。数字身份方案的范围,从集中式的国家身份号码,到几个独立验证方各自为一位用户担保的联合体系,而在二者之间的选择,带有一次纯技术评估会错过的隐私、韧性与信任方面的后果。

数字服务标准是一套编纂成文的原则,通常配有一道在一项服务能够上线或推广之前的独立评估关卡,越来越多的政府用它来要求交付团队达到一个共同的标准:从用户需求出发、与真实用户一起测试、迭代式地构建,并让服务对残障人士可及。它们既是一种治理机制、也是一种设计机制,因为它们赋予一个中央数字职能权力,能够阻止一项未能达到这一标准的服务上线——这通常是让一项标准变得不仅仅是一种愿望的唯一杠杆。英国于2011年成立的政府数字服务局(GDS),是一个被广泛研究的原型实例,展示了一个中央单位如何让各部门恪守恰恰这样一套公布的标准。

最佳实践

  1. 每一次服务重新设计,都从公民的需求出发,用他们自己的话来表达,而不是从机构的内部流程图出发。 在画出第一张线框图之前,先访谈或观察实际正在尝试完成这项交易的人;员工描述一个流程的方式与公民体验它的方式之间的差距,通常正是重新设计机会所在之处。
  2. 在承诺进行生产构建之前,先与真实用户一起制作原型并加以测试。 一份用真实用户群体中的十个人测试过的纸质原型,比一套直到发布之前都没有与任何人测试过的完成系统,能更快、更廉价地发现更多可用性问题。
  3. 采用一套拥有真正评估关卡的数字服务标准,而非一份没有人执行的核对清单。 只有当一项服务能够在上线之前被告知"不行"时,一项标准才能真正改变行为;公布这些标准,并赋予评估机构应用它们的权力。
  4. 从第一天起,就把辅助数字渠道设计为服务的一部分,像数字渠道一样获得资源支持并加以衡量。 把电话热线、社区外展工作者,或由受过培训员工支持的图书馆终端机,当作一个拥有自己服务水平的、经过设计的渠道来对待,而非投诉到来之后临时拼凑的一个应急阀门。
  5. 为每一项服务直接衡量数字排斥,而不是假设全国平均数适用于它。 无法在线完成一笔福利申请的人群,与无法在线续期一份营业执照的人群并不相同;衡量每一项服务实际的使用者与非使用者,并随着服务及其人群的变化更新这一估计。
  6. 一次性建立共享平台组件,并要求、而不仅仅是允许各项服务重复使用它们。 一个团队可以自由无视的共享身份或支付组件,恰恰会被交付压力最大的团队所无视,这会破坏它的意义;重复使用需要成为默认路径,而只有在真正不适用的罕见情况下,才有一套有据可查的例外流程。
  7. 为每一件共享平台组件指定一位具名的、负责任的产品负责人,并公布一份路线图。 一项没有明确负责人的共享服务,会积累起个别依赖它的团队无力修复的、未处理的缺陷与无法解释的停机,这比几乎任何其他事情都更快地侵蚀对复用的信任。
  8. 对面向公民的服务,使用小型的、被赋权的、跨职能的交付团队,而非庞大的顺序式项目。 一支把用户研究、设计、工程与政策专业知识结合在一起、以与敏捷软件开发相关的短迭代周期工作的团队,能够依据实时证据调整方向,这是一个围绕一份固定规格与单一上线日期构建的项目所做不到的。
  9. 公开发布正在运行中的服务的绩效数据,包括那些令人不快的数字。 关于完成率、等待时间与辅助数字服务需求的透明指标,能够在上线之后、内部注意力通常早已转向下一个优先事项时,创造持续改进这项服务的外部压力。
  10. 从第一个原型开始,依据一套公认的标准内建无障碍性,而不是在上线之前才补救它。 补救式的无障碍性昂贵、不完整,通常只有在一位残障公民根本无法完成一项法律要求的交易时才被发现。
  11. 保持非数字渠道开放,直到辅助数字服务的证据、而非计划中的一个截止日期,显示可以安全地淘汰它。 无论还有多少人依赖它,在一个固定日期关闭一条纸质或柜台渠道,会把一项交付里程碑变成一次排斥事件。
  12. 把一项最小可行服务、而非一款最小可行产品当作发布单位。 一项服务只有在它的辅助数字路径、它的例外处理,以及它的数据保护措施,与数字前端一起准备就绪时才是可以发布的,而不仅仅是顺利路径的界面能够运作。

与团队讨论的问题

我们是否用直接的证据、而非假设,知道谁无法使用我们量最大的数字服务,他们今天是怎么办的? 大多数组织能够详细描述自己数字渠道的表现,却只能笼统地描述、甚至根本无法描述自己的非数字用户。用这个问题查明,是否真的有人衡量过谁被排除在一项具体服务之外,而不是引用一项可能根本无法描述这项服务人群的全国性数字鸿沟统计数字。讨论一下,那些被排除的公民目前使用什么渠道,它是否获得了充分的资源支持,以及谁负责确保它继续保持这样。把一个背后没有证据支撑的自信答案,当作一个警示信号,而非一种安慰。

我们今天正在各自独立构建的技术资产中,有哪些本可以一次性构建为一件共享平台组件? 身份验证、支付、通知与文件上传,常常在个别服务内部被重复构建,即便同一个组织或行业内其他地方已经存在一个共享版本。用这个问题盘点一下重复正在发生的地方,并诚实地追问原因:真正的技术需求、历史遗留的偶然,还是一个团队对一项共享服务是否足够可靠、值得依赖的合理不信任。讨论一下,在技术上与组织上,首先整合最明显的重复需要什么。这既是一个治理问题,也是一个工程问题。

我们是否用与构建这项服务的人有实质差异的用户测试过它? 一个年轻、熟悉技术、精通组织内部行话的团队,会系统性地错过一位年长、信心较低,或母语非本地语言的用户会立即遇到的问题。用这个问题核查一下,用户研究期间实际在场的是谁,而不仅仅是运行了多少次会话。讨论一下,这项研究是否包括了残障人士、数字信心较低的人,以及母语不是该服务主要语言的人。如果诚实的答案是测试图的是方便、而非代表性,就把这项服务的可用性主张当作未经证实的东西来对待。

如果我们今天完全围绕公民的需求重新设计这项服务,我们会停止要求他们做什么? 大多数遗留数字服务,仍然要求公民知道该联系哪个部门、该引用哪个参考编号,或哪份表格对应他们的情况——这些组织性知识,一项设计良好的服务本应替公民承担。用这个问题梳理你服务当前的各个步骤,针对每一步追问,它的存在是为了服务公民的需求、还是这个组织的内部结构。讨论一下,后台需要做出什么改变、而不仅仅是前端,才能移除每一个未能通过这项检验的步骤。

我们的服务所依赖的每一件共享平台组件,由谁负责其可靠性、安全性与路线图,每一个依赖它的团队都能说出这个名字吗? 没有明确负责人的共享基础设施,往往是被动地维护的,由恰好在它出故障时最不忙的人来处理,这对越来越多把它视为关键的服务来说是一个糟糕的基础。用这个问题核查一下,依赖它的团队今天是否真的能够说出谁负责他们的身份、支付或通知组件。讨论一下,如果这件组件在一个高峰期——例如一个申报截止日期或一个福利支付日期——发生故障,在运营与公共问责方面会发生什么。

当我们把一项服务描述为"默认数字化"时,我们的意思是它是最好的渠道,还是我们实际上唯一投入资源的渠道? 这两者在一份战略文件中听起来一样,在实践中却截然不同:前者是一项合法的服务设计选择,配有一个获得资源支持的替代方案,而后者是一项披着服务设计理由外衣的削减成本决策。用这个问题审视你的组织最近一次重大的渠道转移决策,诚实地追问它实际上属于哪一种。讨论一下,什么证据能区分二者,以及这项证据是在决策做出之前收集的、还是仅仅在之后才收集的。

实践中的公共价值案例

一个区域交通管理局——虚构的,用于说明一种模式,而非对任何真实机构的报道——为年长与残障居民运行一项优惠出行证计划,通过一份必须连同支持文件一起邮寄、并手工处理的纸质申请表来管理。处理平均耗时六周,申请人常常寄错支持文件,因为表格的说明是用组织外部没有人真正使用的行政语言写成的,而不断积压的申请正在向民选董事会成员产出持续不断的投诉。

该管理局的新任数字负责人抵制住了那种显而易见的第一反应,即委托制作一个现有表格的在线版本。相反,团队花了三周时间,在申请人的家中与社区中心观察他们完成纸质流程,才写下第一行数字规格。他们发现,纸质表格最大的问题不在于它是纸质的;而在于它假设了申请人并不具备的知识、按一个不符合人们自然收集文件顺序的次序列出支持文件,并且除了打电话给一个不堪重负的呼叫中心之外,没有任何方式能够查询申请状态。

重新设计的服务,把大多数申请人转移到了一份在线表格上,该表格按人们自然拿到手的信息顺序索要信息,用平实的语言解释为什么需要每一份文件,并让申请人能够随时查询状态——但团队把辅助数字渠道当作一个同等重要的设计问题、而非事后补充来对待。他们与该地区的社区中心网络建立了伙伴关系,其中好几个本身就是已经得到年长居民信任的社会部门组织,培训那里的员工帮助居民在一台共享终端上填写同样的数字表格,而不是退回纸质流程,并保持一条真正的纸质渠道开放,其资源配置水平依据被衡量的需求、而非需求会简单消失这一假设来设定。

在身份验证方面,该管理局重复使用了国家政府已经为税务与福利服务建立的一个数字身份组件,而非自建一个——这是一项明确的政府即平台选择,节省了数月的开发时间,并给了申请人一种他们中一些人已经在别处用过的验证体验。上线十八个月之后,在线申请的处理时间从六周降到了四天;辅助数字服务与纸质申请如今是总量中的少数、但仍然每年有好几千份,却被以与数字渠道相同的服务水平目标加以追踪,该管理局能够用实际测量的数据、而非一项估计,准确汇报仍有多少居民依赖每一个渠道,以及原因是什么。

四种部门视角

地方政府

地方政府交付政府中量最大、最面对面的服务——福利、住房、垃圾处理、图书馆、社会照护——这使它成为数字排斥最显眼、也最容易把事情做错、代价最高昂的层级,因为最可能需要面对面办理一项地方服务的人群,往往正是最不可能对上网感到自在的人群。地方政府的优势是近距离:社区中心、图书馆与地方志愿组织已经作为一个受信任的辅助数字网络存在,前提是这个政府机构设计服务时与它们合作,而非绕开它们。它的劣势是规模:一个单一政府机构很少有预算或工程能力自行构建共享平台组件,因此它复用一项区域或国家身份、支付或通知服务、而非构建一个更弱的地方等价物的能力,在很大程度上决定了它能够交付什么。

国家政府

国家行政部门通常是唯一拥有足够规模来证成构建真正共享平台基础设施——身份、支付、通知——的政府层级,原则上也拥有强制要求跨部门复用它的权力。在实践中,这项权力常常受到争议:一个中央数字单位要求复用的授权,常常与一个部门的预算权、交付截止日期,以及对依赖它无法控制的基础设施的合理怀疑相冲突,这呼应了范式类型学中层级与平台协调之间更广泛的张力(见主题3.1——公共行政体系与模式)。那些维持着一个对标准与平台复用拥有真正权威的中央数字职能的国家——OECD的《数字政府指数》在成员国与伙伴国之间追踪的一种模式——往往展示出更少的重复系统与各部门之间更一贯的服务质量,尽管这份指数也显示,即便在资源充足的政府之间,这种权威的建立也并不均衡。

社会部门与非营利组织

非营利组织与社区组织在数字政府中扮演着两个截然不同的角色,把它们混为一谈会造成真正的伤害:它们常常是被政府服务排除的公民最后依靠的辅助数字渠道,吸收着一项从未被正式委托或资助的成本与照护义务,同时它们也越来越被期望以一套由同样的用户期望所塑造的标准来构建自己的数字服务,却只有一个政府部门工程预算的一小部分。一个政府机构已经悄悄开始依赖其提供辅助数字支持的社会部门组织,理应获得一段明确的、理想情况下获得资助的关系,而不是被假设善意与使命契合会无限期地吸收这份需求。

多边与国际

多边发展机构在很大程度上把数字政府当作一个发展与公共财务管理问题来对待:例如,世界银行的GovTech项目,把技术驱动的公共行政改革,当作中低收入国家政府效能的核心,而非仅为较富裕国家保留的一项奢侈品。数字身份常常是这项工作的先锋,因为一个可靠、包容的身份平台,是在规模上交付几乎任何其他数字服务的前提条件,而它的设计选择——集中式还是联合式、生物识别还是凭证式——带有发展伙伴与纯粹交付效率一并权衡的金融普惠与公民自由后果。印度的Aadhaar生物识别身份系统,是同类计划中规模最大的一个,展示了这样一个平台所能实现的覆盖范围,以及它在国家规模上引发的、有争议的隐私与排斥权衡。跨境互操作性,仍然是这个规模上更难解决的问题:一位公民经过验证的数字身份,很少能干净利落地跨越一条国界迁移,这限制了这种平台模式目前能够超越单一辖区延伸多远。

常见失败模式

悄悄排斥人的纯数字交付。 一个组织把一项服务重新设计为数字优先,依据渠道转移量来衡量成功,却只在上线之后才发现有多少公民根本无法完成这项交易。美国2013年的Healthcare.gov上线,是这种模式一个有据可查的公开实例:一个强制性的在线登记流程,在负载之下、在现实世界的可用性测试之下,恰恰在公民最需要它的时刻失效了,而这次修复需要一次紧急动员外部技术人才。这项代价不仅仅是那些被直接排除的公民;还有当一个旗舰数字项目明显地辜负了它本应服务的人时,随之而来的合法性侵蚀。

没有人被要求使用的平台。 一个中央职能构建了一件真正良好的共享身份、支付或通知组件,但采用率仍然是可选的,于是交付压力最大的团队,构建了自己更弱的等价物,而非与自己无法控制、也无法影响的基础设施相集成。这项代价,在多年间累积成恰恰是这个平台本应防止的那种重复的、不一致的局面,而这件共享组件本身,却因为得不到本应证成其预算的使用量与投资而陷入饥饿。

在界面处止步的服务设计。 一个团队对一份表格的界面应用了真正的以用户为中心的设计技能,却让它背后碎片化的后台流程完全未加改变,产出了一种一直到一个案例偏离顺利路径之前都看起来连贯的公民面向体验——这与范式类型学中更普遍描述的那种数字外衣模式相同(见主题3.1——公共行政体系与模式)。这项代价是,一项服务在演示中测试得很好,却恰恰在拥有最复杂、也常常最紧迫需求的公民真正遇到它的地方失败。

把辅助数字服务当作一个四舍五入误差来对待。 一份数字优先商业论证,详细地为数字渠道的成本建模,却给"其他渠道"分配了一条象征性的、资源不足的预算科目,假设辅助数字服务的需求会是小规模且暂时的。这项代价以呼叫中心排队、社区组织吸收未获资助的需求,以及一个持续存在、这个组织自己的数据从未被设计得足够清晰以便加以纠正的被排除人群的形式浮现。

在最后才补救的无障碍性。 无障碍性被当作一项在上线前不久才执行的合规检查,而非从第一个原型就存在的一项设计约束,于是问题被发现得很晚、修复成本高昂,有时在上线之前根本没有被修复。这项代价不成比例地落在了试图完成一项法律要求交易的残障公民身上,常常以一次代价高昂的重新设计、一项监管投诉,或两者兼有而告终。

成熟度模型

子维度 启动 发展 标准化 管理 协同
服务设计实践 数字项目从既有表格与内部流程出发,而非用户研究 部分项目开展用户研究,非正式、没有一致的方法 一套共同的服务设计方法与服务蓝图,对面向公民的重新设计是强制性的 对照用户需求的服务质量在上线后被衡量,并驱动迭代 服务设计与用户及交付伙伴以一个持续的周期共同产出
数字优先交付与辅助数字服务 各渠道被临时地数字化,没有关于谁被落下的战略 存在一项数字优先战略,但辅助数字服务是非正式的、未获得资源支持的 辅助数字服务被设计并资助,作为每一项数字优先服务的一部分 数字排斥按服务被衡量,并对照一个目标汇报 辅助数字服务的提供与社区及社会部门伙伴共同设计
政府即平台的采用 每一个团队都构建自己的身份、支付与通知组件 存在一些共享组件,但复用是可选的、不一致的 复用共享平台组件是强制性的默认选项 平台组件拥有指定的负责人、公布的路线图与可靠性目标 平台投资与路线图与使用它们的团队、以及在相关的地方与其他公共机构共同治理
设计中的无障碍性与包容性 无障碍性直到后期测试才被考虑,如果曾被考虑过的话 无障碍性在上线之前依据一套公认标准接受核查 无障碍性从第一个原型开始就被内建,并与残障用户一起测试 无障碍性表现与其他服务指标一并被衡量并汇报 无障碍性标准与残障人士组织共同制定并审查

检查清单

  • 在明确规定一次重新设计之前,先观察或访谈正在完成当前流程的真实用户。
  • 与代表完整人群的用户一起制作原型并测试,包括数字信心较低的人与残障人士。
  • 采用一套在上线之前拥有独立评估关卡的数字服务标准。
  • 与数字渠道一并、而非在其之后设计并资助辅助数字渠道。
  • 为这项具体服务衡量数字排斥,而不仅仅是对照一项笼统的全国性估计。
  • 在构建新组件之前,识别出哪些平台组件(身份、支付、通知、文件交换)已经存在可供复用。
  • 为服务所依赖的每一件共享平台组件指定一位负责任的负责人,并公布一份路线图。
  • 从第一个原型开始,依据一套公认标准构建并测试无障碍性。
  • 公布正在运行中服务的绩效数据,包括完成率与辅助数字服务需求。
  • 依据安全需求水平的证据、而非一个固定的日历日期来设定一条非数字渠道的淘汰时间。
  • 确认后台流程已经被重新设计,而不仅仅是面向公民的界面。
  • 审查目前在组织内部与外部,谁正在吸收未获资助的辅助数字服务需求。

关键资料来源

  • 蒂姆·奥莱利,《政府即平台》,《创新:技术、治理、全球化》(麻省理工学院出版社,2011年)——共享、可复用政府基础设施这一论证的起源。
  • 帕特里克·邓利维、海伦·马杰茨、西蒙·巴斯托与简·廷克勒关于数字时代治理的论述(完整引文见主题3.1——公共行政体系与模式)——本主题实践所处的这套范式。
  • 经合组织,《2023年数字政府指数》——在成员国、加入国与伙伴国之间对数字政府基础进行的比较性基准评估。
  • 世界银行,GovTech全球伙伴关系——跨收入水平的技术驱动公共部门改革。
  • 英国政府数字服务局,《政府设计原则》——一个国家数字服务标准设计原则的已公布实例。
  • 尼尔森诺曼集团关于服务蓝图绘制与2013年Healthcare.gov上线的研究——应用性的服务设计与可用性方法论,以及一个有据可查的失败案例。

参考文献

  1. E-government — Wikipedia — https://en.wikipedia.org/wiki/E-government
  2. Service design — Wikipedia — https://en.wikipedia.org/wiki/Service_design
  3. User-centered design — Wikipedia — https://en.wikipedia.org/wiki/User-centered_design
  4. Digital divide — Wikipedia — https://en.wikipedia.org/wiki/Digital_divide
  5. Digital identity — Wikipedia — https://en.wikipedia.org/wiki/Digital_identity
  6. Government Digital Service — Wikipedia — https://en.wikipedia.org/wiki/Government_Digital_Service
  7. X-Road — Wikipedia — https://en.wikipedia.org/wiki/X-Road
  8. Aadhaar — Wikipedia — https://en.wikipedia.org/wiki/Aadhaar
  9. Digital era governance — Wikipedia — https://en.wikipedia.org/wiki/Digital_era_governance
  10. Agile software development — Wikipedia — https://en.wikipedia.org/wiki/Agile_software_development
  11. Tim O'Reilly, 'Government as a Platform' — Innovations: Technology, Governance, Globalization / MIT Press — https://direct.mit.edu/itgg/article/6/1/13/9649/Government-as-a-Platform
  12. 2023 OECD Digital Government Index — OECD — https://www.oecd.org/en/publications/2023-oecd-digital-government-index_1a89ed5e-en.html
  13. GovTech: Putting People First — World Bank — https://www.worldbank.org/en/programs/govtech
  14. Government Design Principles — GOV.UK / UK Government Digital Service — https://www.gov.uk/guidance/government-design-principles
  15. Service Blueprinting in Practice: Who, When, What — Nielsen Norman Group — https://www.nngroup.com/articles/service-blueprinting-practice/
  16. HealthCare.gov's Account Setup: 10 Broken Usability Guidelines — Nielsen Norman Group — https://www.nngroup.com/articles/affordable_care_act_usability_issues/