Brief

Create a highly secure user portal that relates to the end-to-end complaint process, starting from the complaint form. The Portal will seamlessly integrate with the internal Complaints Management System (through an API) to maintain existing working practises.

Plan

The project had already been divided into phases by the client, and the first phase was due to be delivered after just two months from the project starting date. I so decided to spend the initial two weeks to understand which one were the core areas of the portal, the main goals, targets and outline biggest challenges.

With that understanding I was going to be at least able to plan the work properly and then set-up a full discovery and design phase.

This would have been followed by a build phase, quite blurred with the design phase due to the complexity of the workflow of the form (a core part of the site) and due to the required complex testing to validate the work. This process was then going to be reiterated for every phase.

Discovery

To create a solution I always start from the why so from understanding the key areas as much as I can. I do this at the beginning of every project during the discovery phase.

Discovery / key areas, goals and target

Because all the information displayed on the portal were connected to one or multiple complaints from the user I started with the assumption that the complaint form was the key area for this product, being the area that collects user data to be used by LGSCO (Local Government and Social Care Ombudsman). This assumption was validated by information provided by the stakeholders during the first discovery meeting.

The form was not only the core of this product but also, because of this, the focus of the first phase.

For these reasons, I worked closely with the stakeholders to understand the user flow on the form and the reasons behind each step (if required by processes already in place, technical reasons or assumptions).

To understand better the form itself, and the decisions to be made to define a good flow, I worked with the stakeholders to define the goals for the portal, the target audience and the main reason for the user to be on their portal.

/ goals /

• Improve user experience in submitting and managing a complaint with LGSCO
• Streamline workflow to gather complainant data and make them available LGSCO internal complaint management system
• Reduce the number of support calls

/ target /
Every Citizen that couldn’t resolve an issue with organisations providing local public services   

/ JTBD /
When the council didn’t decide correctly with an issue I raised I want to easily make things right so I can get my issue solved.

Discovery / project plan simplification

By working to define each required step and logic for the form I quickly realised the complexity of the workflow required to provide both good and clear user experience and correct and clean data to the organisation. 

Because the first phase of the project was supposed to deliver a complete complaint form and a new full UI, due to lack of time to do quality work, I decided to propose two options:

• To merge phase 1 and 2, so moving the live date in the future but still working on both phases (so saving time in going live with an extra phase) 
• To focus the first phase only on producing a robust complaint form to work as the ground level for the other phases to follow, with just basic UI and so minimal front-end work required. This was so allowing to have the right time to design, test and build a process to gather data from the complainants and send them in the right order to LGSCO

The Client supported the last option so I started to focus my attention on the form flow and logic, always keeping in mind the wider goal.

Discovery / complaint form

To define logics for the form I reviewed LGSCO internal practices, user common behaviours (gathering data from LGSCO user requests data and experience) and user needs.

I identified the sign-up flow to be the most complex part of the form in terms of related logic, due to a required pre-selection of users. Related to that I have also to consider the complex data flow, considering that portal member data were mixing with form data and all of them are considered sensible data.

Discovery / wireframe – prototype

Initially, to present and work on this form flow I used a flow map of the full process, and also some simplified flow maps for specific and selected areas, and later I used Axure to create an interactive prototype with the full logic. The flow map first and the Axure prototype later allowed me to do some initial testing and user usability testing.

Because we decided with the developer manager to use a ready tool as a form base level, I used the map and the prototype to share the requirements with the developer and work together with him to complete the form flow directly on that tool.

I made this not only to simplify the process, because the form tool was easier to use to create a prototype, but also to allow the form to generate real data (a key part and main purpose of the portal).

This approach, of merging the design and build, it’s not commonly used by me and actually I am usually against it, but in this case, due to what I explained before, it raised too be the best option for this phase.

To help everyone in the team to work on the form I also created a few simplified site maps with some user flow elements.

/ first usability testing /

Once a complete version of the first iteration of the form was ready, I use that to do a first user usability test, with a small internal group of 20 people, by providing them with a few simple tasks and basic background:

[ background : This is a form to complain about local authorities. ]

• The task to complete are:
• Create an account
• Submit a complaint
• Preview that complaint you have just submitted

This test highlighted a few issues in the flow that made the process unclear to the user (even if correct from the organisation point of view). Thanks to those data I was able to adjust the flow by adding the needed steps to make the form accessible.

/ client testing /

When the form structure was working as expected I worked with the stakeholders to organise an internal user testing with the client team. This allowed me to get some data from a wider usability test group at first and then valuable feedback on any odd and unexpected behaviour of the form.

Discovery / full portal structure – phase 2

While the client internal testing was being done, I started to work with the stakeholders to define requirements for the full portal functionalities.

I used the initial requirements provided by the client to create a basic and plain wireframe to be used a starting point. Once the main functionality needed by the users and LGSCO had been defined I updated the wireframe to reflect them and do initial testing.

Prototype / UI – phase 2 

Once the wireframe was tested I started to create the full portal UI starting from the form. 

To start I first analysed LGSCO branding to define colours (with the correct contrast) and their hierarchy of use. This then allowed me to define the basic common elements of the portal, such as buttons, text and navigation.

With this ground level, I analysed every kind of questions present in the form, and I made the UI for each one of them following the best accessibility practises and considering the existing structure of the current tool used for the form. 

After creating the form UI I moved to the other pages of the portal that allow the user to track complaint progress and to manage their account.

With the complete mock-up, I created a fully interactive prototype to be tested first internally and then by the client’s team. I also used some web tools to test the initial accessibility of the portal, and I also worked with an accessibility expert to improve grey areas. 

After collecting and analysing key data from these testing I updated the prototype.

Front-end Development – phase 2

Once the Prototype was fully tested and approved by the stakeholders I worked closely with the front-end developers. I first used the prototypes and the sketch file to provide them with a full picture of the structure and the requirements as well as a simplified site map to guide them.

During the build, I help them find solutions and make adjustments when needed. When the front-end was fully completed I run again some WCAG tests on it. Some of them included keyboard navigation and navigation for blind users using voice over.

Discovery – phases 3 to 6

Because the first two phases had now a clear structure I organised a face-to-face discovery workshop with the stakeholders to define more in detailed following phases. To do this I gathered information from previous phases, to give an overview of the ground level for the following one, as well as goals and target information.

I then created a flow chart with all the info gathered for each phase at the time and I used that as a guide during the workshop.

During the workshop I used a whiteboard and post-its, guided debates and some sprint exercises, to define, together with the stakeholders, key elements of each phase:

• Where did the need come from (so a strong reason to have that functionality)
• Why was the portal the best place to house that functionality
• The characteristic of the functionality
• The possible challenges of the functionality (written in the How Might We format by the workshop participants during the workshop)

I then translated all the workshop into a virtual whiteboard using mural ( this also allowed me to easily continue the discovery process in remote ).

Back-end Development – phases 2

I am currently working together with the developer manager and LGSCO partner agency from their internal complaints management portal to define and structure the API required for the user portal to work correctly.