Evolution of roles: Retain Cloud enterprise

A legacy product of 20+ years of age was replatformed and redesigned from on-premise to cloud SaaS.

The initial 'MVP' was a mammoth project spanning almost two years and involving dozens of people: Back and front-end developers, quality assurance, DevOps, technical authors, UX designers and researchers.

Then we moved to the next phase of development: implementing 'enterprise' features.

I've decided to zoom in on one enterprise featureset I designed as part of a team.

User needs

The core functionality of the product is to assign resources (usually people) to jobs (also known as projects or matters) as bookings.

The fundamental need for this featureset was to create a precursor to a booking. Where a booking could represent a 'final' commitment to work, there are various reasons why a booking could not yet be finalised, needing the precursor step:

  1. Several options or groups of options for bookings might need to be compared before finalising (known as scenarios)
  2. Depending on the governance of the organisation, the user might not have permission to create a booking but requests one for someone else to approve (known as booking requests)
  3. Groups of resources need to be found based on sets of criteria, where one user type creates requests, and another creates the resulting bookings (known as team requests or demand capture)

In the legacy platform these 3 journeys were implemented as distinct features, sets of features, or separate areas of the application. It was clear to me that not all of these features could be developed in our time frame, and in any case, there was plenty of overlap between them.

Constraints

We determined that like every booking, every role should be associated with a job assigned and proposed that the new features for roles should live within the 'Jobs management' tab of the application, although this was later expanded so that roles could also appear in a graphical 'calendar view'.

This featureset and others were developed as part of a funding round within our larger organisation, so we were constrained by a hard deadline at the end of which we had to demonstrate a range of features including this featureset.

Process

  1. Consolidation
  2. Workflow mapping
  3. User testing
  4. Feature prioritisation
  5. Component mapping
  6. Design process improvements
  7. Start of development
  8. Quality assurance
  9. Release

1. Consolidation

I proposed a way in which these needs could be combined into one new entity: a role, which could be grouped with other roles but each role would have its own status.

I created an overview including flow charts to help determine whether all or most of the functionality of several legacy features could be simplified into one 'master' process using Miro.

consolidation Overview in Miro

The overview includes the following details:

entity relationship ER diagram detail in Miro

With the entity relationship diagram I showed how a role could be related to other entities in the application in order to meet all the needs satisfied by the legacy features:

2. Workflow mapping

In a follow up exercise I looked at the workflow in more detail, zooming in on actions that could be performed and corresponding screens in the application to steps in the workflow. Actions that could be performed would be determined by the user type or 'Actor':

workflow mapping Workflow mapping in Miro

3. User testing

High fidelity screenshots which had previously been tested under the theme of 'scenarios' were adapted to the proposed workflow by the team.

prototype Prototype in Sketch

Participants were screened and shown a different prototype workflow depending on whether they fit the 'Requester' or 'Planner' persona.

The user testing lead us to streamline the navigation of the featureset by tweaking UI copy, moving buttons to more expected locations, and improving the visual hierarchy of items.

4. Feature prioritisation

After consolidating the original features together, we needed to split them apart in an order and size that made sense for development and testing:

  1. Create and edit
  2. Contextual information
  3. Workflow
  4. Actors

Contextual information: This is the data surrounding roles, some coming from calculated fields to determine e.g. the cost and revenue of roles. Another example of calculated data would be comparing roles with the assigned resource's existing bookings.

Workflow: This is about the stages or statuses a role moves through from a draft to a completion, the creation of a live booking.

Actors: This introduced the separation of permissions for creating and completing roles, with associated new role statuses like 'requested' and 'rejected'.

5. Component mapping

To assist developers, the team mapped out all components that would need to be added to our existing component library by breaking down a new page design into its component elements and supplying styling details needed for implementation.

We also provided descriptions for components which would eventually be incorporated into the live React Storybook component library. Our visual reference within the design team, a Sketch style library, was also updated.

component mapping Component mapping in Miro

6. Design process improvements

The final design artefacts we created for developers and QAs referred to were markdown files with a combination of description and images to describe new UI elements and interactions.

Originally designers wrote text descriptions on each feature, but over time this became cumbersome for the teams, in particular QA who needed to be able to easily refer to the descriptions of already implemented features to check for regression. It was also difficult to keep track of feedback and follow up questions on designs.

Incorporating feedback from the team, I migrated the design documents for this featureset to a new wiki of markdown files stored in git. The git process, in particular pull requests, allowed us to capture feedback from the team and go through a formalised approval process by development and QA before a design document was 'live'.

Design documents, originally describing the entire featureset, became more standalone to streamline the development of each individual feature and migrated to a new process to make them easier to read and manage: a set of wiki pages stored in git.

design wiki Design wiki page in Azure DevOps

Release

Previous releases had been heralded with very dry 'release notes' type emails to clients. I suggested that we develop an illustration style and library to produce simple illustrations to give users a graphical overview of new features.

illustration actors Release illustration for actors

UI UI for editing a group of roles

User testing doesn't stop at the release: further user testing will be conducted ahead of the design and development of complementary features to this featureset.

Lessons learnt

Error handling: During the quality assurance phase, many questions came up around the topic of error handling. Although we had a basic framework for handling errors, it was not granular enough to catch differences between issues with concurrent user editing and lack of security permissions, for instance. Additionally, the user friendliness of the saving mechanism for a group of roles, while some actions such as a status change can be completed independently, needs further work.

Ease of navigation: The functionality for roles added two layers of navigation into the application. Although our URL handling meant that you could get directly to the role group with a link, other methods e.g. through context and drop-down menus were perhaps unnecessarily slow, requiring too many steps.

Agile vs waterfall: Working to a deadline where we were committed to developing certain features meant that we were not very flexible when it came to incorporating the results of user testing or responding to any other client suggestions or frustrations along the way. It also meant that instead of our original goal of many small releases, we had several very large and complex releases. We resolved to work differently for future releases.

Next steps

The next release would work towards showing roles in the plans page, a graphical calendar view.

illustration roles in plans Release illustration for roles in the plans page