#1 User journey and scenario building — Day 2
This blog is the first in a series documenting the Re:Permissioning the City(PtC) product development journey. In the spirit of “working out loud”, the series aims to share our ongoing progress, learnings, and reflections on building a digital permissioning system designed to unlock underutilised spaces in the city for civic use, through introducing participatory and distributed forms of spatial governance.
Day 2: User journey and scenario building
On days two and three, we focused on developing the user journeys. The emphasis was placed on creating tangible, realistic use case scenarios which would help us identify the gaps in our concept and challenge where we might be relying too much on theory and assumptions.
We created a template that divides the system into front stage(frontend) — covering user actions and visible interfaces — and back stage(backend), which handles the behind-the-scenes logic and processes supporting these interactions. We also listed some choices for scenario building, such as types of permissions, users, and spaces.
We decided to prioritise the event organiser and space stewards (space owners, managers, broader stakeholders like neighbours) and split up into two groups, with one group focusing on a scenario around a music event, which deals with pre-defined/automated permissions and an exception approval case, and the other on a food related event that deals with bespoke permissions. We chose music and food specifically as these scenarios are likely to introduce tensions or conflicts. Noise level issues would allow us to explore how we might use sensors to verify and give real-time feedback to space users, preventing the escalation of conflict, and food/cooking would allow us to dig deeper into the liability mechanisms around fire risks, safety and hygiene.
Through the user journey exercise, we were able to clearly distinguish the differences between the three types of permission processes: pre-defined/automated, exception-based, and bespoke permissions.
Pre-defined/automatic
When requesting permissions to use a space, users will be able to choose from an existing template of rules. Template A might be suitable for loud music events with more than 50 people, template B might be suitable for small cooking classes, and template C for book clubs. These templates of rules (or rulebooks) can be initially drafted based on general liability considerations (number of people, types of activity, etc), and further adapted and modified through usage in a particular space. The idea is based on a precedent-based model, similar to case law: if permission has been granted previously for a kind of event without issues, similar future events will also be automatically permitted. For most events that can be classified under certain types of activities, these pre-approved templates will enable instant permissions, simplifying and speeding up the booking process.
Exception-based
Exceptions are cases where users might request small exceptions which need human approval. In one of our scenarios, Pim, who was hosting a religious worship event involving music performance, wanted to request to increase the maximum noise levels allowed. This involves modifying a single clause in one of the template of rules. The request is processed by a ‘permissioning group’ — a group of people who have opted-in to act as a steward of a particular space, who have the responsibility to partake in decision-making as well as maintaining the space. The members of the permissioning group make a consensus based decision, whether to approve or disapprove this exception. They are also made aware that the adapted permission they grant will also become a template for future events.
Bespoke permissions
Bespoke permissions are reserved for rare cases where users are requesting permissions for a completely new type of activity which does not fit into any of the pre-approved templates. In our scenario, this was a proposal for a large local produce market held in a park. A request for bespoke permissions triggers a slightly more complex set of actions than the exception-based permissions. The event organiser will be prompted to construct a new template of rules based on the activity proposed. They will also fill out a self risk assessment form indicating their concerns and what they are excited about (the pros and cons). Submitting this request will trigger a notification to the permissioning group who will be given a due date to arrive at a consensus to approve or reject the new template. Once accepted, the event is permitted, and also future events with the same characteristics can use the template for automatic permission.
Principles and values
Through the user journey exercise which compelled us to sketch out the details of each action and process, we were also able to define the basic principles of the platform which reflect the underlying logic and values of our concept. They will be used to further define key concepts like the permissioning group, template of rules, feedback systems, incentives and liability mechanisms, and so on. These principles and values can be considered as version 1, which will be iterated later when we have more experience to draw upon.
Governance
Power and liability as inextricably linked: If you want to make decisions you need to share liability i.e. skin in the game
- Prioritise proximity to space and physical presence (linked to shared risk and liability)
- Giving away power is giving away liability (which is why space owners might want to share decision making/permissioning power)
Permissioning based on precedents (like case law)
- Every space starts with basic template of rules which are iterated thereafter
- Everything is allowed (within legal limits) until something happens to change the rules
- Templates need to be updated regularly (time limited templates)
Permissions are peer reviewed (e.g. permissioning group)
- Permissioning group performs the role of space stewards — responsible for maintaining permission templates, approving bespoke permissions
- Anyone can join a permissioning group
- Initial permission group can be formed through a combination of invitations (based on shared liability holders) and self opt-in through shared interests
- Deliberations within permissioning group prioritise consensus building — through dialogic processes (rather than majority rule)
- Permissioning group participants are given a choice to opt-out of a particular decision
Incentives
- Prioritise system level of risk and benefit sharing — to avoid rent seeking behaviours
- Prioritise generating system level of incentives/benefits (rather than personal/individual)
Feedback
- Based on incentives and positive feedback at the system level rather than penalties and punishment at the individual level
- Encourage feedback on rules/permissions not people and their conduct
Technology
- We adopt technology not to maximise efficiency and profit, but to enable greater flexibility and freedoms. We acknowledge that technology could be exclusionary, and while we may not be able to address this immediately, we are committed to designing systems that prioritise inclusivity and accessibility. By embracing open standards and decentralisation, we aim to create tools that empower communities rather than control them.
This blog was written by Eunsoo Lee in conversation with the core team of Permissioning the City and utilising the records of the workshop.
Team members who contributed to the workshop (in alphabetical order):
Calvin Po, Donghun Ohn, Eunji Kang, Eunsoo Lee, Fang-Jui ‘Fang-Raye’ Chang, Hyojeong Lee, Shuyang Lin, Theo Campbell
Wider advisory group:
Indy Johar, Hee Dae Kim, Gurden Batra, Charlie Fisher
Partners and funders:
NIPA(National IT Industry Promotion Agency), P4NE(Partners for a New Economy), Parti
