EXPERIENCE DESIGN PRINCIPLES

With insights from the workshop, I derived 4 core principles for the design of the MVP phase of the project. The mobile experience would be based on the Control Desk application have to give back control to the farmers by offering key decision moments in the sale experience all the while connecting the 4 roles that made the flow of cocoa from farm to warehouse seamless and with fewer complications.

Design concept

After the workshop and diving into challenges we decided that the application had to be largely used as a utility artefact. The intent was to keep the workflow of the end user moving as they move themselves. The intention was to eliminate frequent usage of the desktop version which required the end user or service desk agent to gather all of the information and enter it via the desktop application.

INFORMATION ARCHITECTURE

Information architecture (IA) can be of 4 types: Narrow and Deep, Broad and Deep, Shallow and Broad and Shallow and Narrow. The intent of this application was to keep end users focused on a task and not keep them engaged. In other words its a utility application. For the structure of this application I borrowed from Control Desk’s web app and took in only that which was necessary for utility purposes.

With that, the structure became narrow and shallow - offering limited capacity of the Control Desk web app. The architecture looked at:

1. Creating a ticket, its process, following its journey until resolved or closed

2. Solutions and enabling access to them

3. Contacting support of the IT department within the organization

4. Requesting products or services from the ITSM system of the organization

It is important to note that though the IA largely looked at features discussed in the workshops, the stakeholders decided that the process for requesting services was too long drawn for the MVP and was best introduced in a subsequent update of the mobile application.

TASK FLOWS

The next step after setting up the information architecture was to take the job stories and create task flows that matched the experience principles. Task flows had to be kept linear for the most part as is synonymous with mobile usecases.

1. The task flow of raising an intent for the first time revealed the cleanest pathways to create a ticket, put information available at hand and solutions related to the incident.

2. The other scenario was to enable end users to look for solutions on their own before they raised a ticket. Solutions to problems known are part of the Control Desk product offering. Problems to which solutions are not available are categorised as such and were flagged into the system - though quite rare in the ITSM world.

3. Checking status updates of tickets raised and adding comments to follow up.

4. Changing the role from an end user that reports incidents to service desk agents that are responsible for moving tickets and proposing solutions.

SKETCHES

I started by writing requirements for raising an intent. Making paper sketches was the first step in visualizing what the screens for the intended activity could look like. Drawing the flow of information helped in assessing what kind of interactions would be necessary. Ofcourse the original web app was referred though because of its legacy. The process could not be wildly different as introducing new pathways would instead add to cognitive and motor loads.

Putting down each screen on post-its gave the ability to move around the process, check the task flows, information architecture and confirm it with the legacy process. After a rough analysis I put them up on a wall to get the bigger picture of the application. This helped drive the functionality and the width of the application set up with the IA.

Interaction Design

WIREFRAMES

In the wireframes shown is the key flow of Raising an Incident report. End Users report an incident in 3 simple steps. First, tapping on create a ticket asks the end user about who the ticket is for. Second, the end user enters details of the issue by selecting from a set of categories and writing a description. Based on the details a recommendation engine pulls out relevant solutions - if the problem has a solution then the flow ends. Third, if the problem persists a ticket can be raised with additional details like images or attachments with a priority level. Solutions could have shown in the end of the process, but in order to reduce tickets raised solutions were shown during the process.