Introduction

For the USCT use case, we conducted various discussion/feedback sessions with an expert from GIZ and designers who has experience in designing social welfare services from Gofore. These discussions and feedback sessions will continue throughout the project and it will directly affect the wireframes.

 Goals

The discussion aimed to understand possible Civil Servant work processes, limitations, UI patterns and actions. For our project, we are creating a generic flow of civil servants for a non-tech decision-maker persona(Our first persona based on functional scope). Because of the project's vision and simulation aspect of the work, we are trying to be as generic (while being realistic on some level) and informative as possible. This is a unique project with lacking examples, hence we are gathering as much information, examples and inspiration to build it.

• A Logical and generic process that civil servants follow

• User Flow + feedback

• UI patterns

• Different roles 

• Limitations

Outcomes / TakeAway

• There are many points that may affect the UI, experience and flow

  • Regulations specific to a country and legal Framework

  • Socio-Economic conditions in the country

  • Different roles and limitations for Civil Servants

  • Limitations for the citizensSome of the information civil servants can access can be limited based on their role. (Opportunity: showcase security level of the information)

• Some of the tasks for civil servant may require higher level authorization

• Categorizing and assigning citizens to a group is not something that is currently used for example social welfare programs in Finland based on the discussion. But it is something that is considered for future application.

• Citizens can change their information on where the data is pulled from, they need to interact with the agency. (for example, if they want to change their home address and the information is pulled from “A” service, they need to change the information through “A” service)

• Citizen can edit their program-related data. (For USCT: bank information or preference payment method can be an example)

• For user flow: flow itself can be “action related”. (Example: If the goal is “adding missing Information” Instead of accessing an Info page directly, users can go through one or two steps to concentrate on only missing information and directions to the info page from there.

• For Civil Servants, discussed example UIs are usually filled with data and information, not user friendly. Terminology is quite confusing

• Based on the role of the civil servant and program editing and actioning on an item can be limited, and may need a request from other roles/agencies/organisations/offices.

• The complaint/contact system is where the interaction between civil servants and citizens mostly happen on the USCT case.

Additional Takeaway can be also seen in “General Notes”, “General Questions”, and page specific “Consider” sections of the figma page: GovStack USCT Analyses and Research .