Car Insurance App - Part 2

The Kanban board workflow and User Stories

      In Part 1 we saw two important things to think about when starting a development project: Personas and the database.
      Once we have a clear definition of who is going to use the application and what they can do, we can start implementing our functionalities.
      One great way to visualize the tasks a team need to implement is the Kanban board.
      In this example I used a digital tool but a Kanban board can be set on a blackboard or on a wall.
      The idea is to show the tasks you have not started, tasks in progress and tasks that are done.
      From the developer perspective, each Kanban card is what we call User Story - it is a feature to be implemented.
      The Kanban is not used only by the IT department, it can be used by any professional or project. When a project is not related to IT, we say that each Kanban card is a work item.


      Card 1 - Database infrastructure

      You can use App Engine Studio or Studio to create your tables.
      Our database diagram in the previous article was a little bit formal, but it translates to ServiceNow like this:
      - A field type boolean is equivalent to: True/False
      - A field type char is equivalent to: String
      - The field Status will be of type: Choice
      We start by creating tables that does not have reference fields. In our case we start by creating the Vehicle table.
      The idea of the field Active in the Vehicle table is that, once an Admin change its value to False, it will not be available when the Agent is creating a record in the Proposal table.

      Card 2 & 4 - Persona: Insurance Agent

      Before presenting a design to the stakeholders, the developer should know in advance what order/position the fields should be displayed.
      Are there mandatory fields? A field should be hidden/shown depending on some condition?
      To simplify things here suppose there are no mandatory fields and all fields (except for the status_reason) can be shown to the Agent. Our screen layout will look like this:

UX Agent

      Card 5 - Persona: Car Insurance Employee

      The Agent can work on a proposal while the "Send to analysis" is not checked. Once this field is checked and the record Updated, it will be available only to the Employee.
      When the Employee is logged in, the design presented will look like this:

UX Employee

      Note that the Employee can't edit information provided by the Agent. The only available field is the Status reason. The buttons Approve and Reject are also available.
      Once the Employee approves or rejects the proposal, it becomes historical data and the Employee now can only consult the record:

UX Historical data

      Card 6 - Persona: Admin

      And now let's see the screen design for a logged in Administrator.
      The Administrator can maintain the Vehicle table by editing existing records and creating new ones.

UX Admin

      With this we have an example of how a workflow process can be implemented.
      We have a Persona called Agent who can create proposals within the system.
      A second Persona representing the Car Insurance Employee is responsible for the approval phase.
      We also have a third Persona - the Administrator - who can maintain system parameters like the Vehicle table.

      Each Persona performs different activities within the system. They have well-defined capabilities and facilitate the improvement of this process by allowing us to automate and develop new functionalities.

      Another benefit of ServiceNow custom applications is to avoid shadow IT. Now the Car Insurance company knows everything about this process: how it works, who carries it out and the revenue it generates.

      Thanks for reading.

What is Kanban? by Max Rehkopf
Shadow IT - Wikipedia