My Framer Site

Client

Deloitte UK

Info

Role

Product Designer

Timeline

3 weeks

Focus

Developer Tool

Tools

Figma

Team

Product Owner
Project Manager

Tech Lead

Developers

(Back/Front - End, QAs)

Context

The Project

Updating the colour guidelines to support best practices and provide flexibility for various products and contexts.

"How can we revise the application of Deloitte's branding colour palette for web use while ensuring all platforms remain consistent with the brand's visual language?

Outcome

The update decreased implementation time by 70%.
It ensured scalable products across all departments and reduced design decisions by all the company's designers, enhancing colour usage, flexibility, and consistency.

Part One:

Design Sprint

I led the assessment of the existing colour system and collaborated with cross-departments.

These pain points highlighted a fundamental issue: our colour system was creating barriers rather than enabling efficient, accessible design and development.

The feedback demonstrated an urgent need for a more structured, semantic approach that would serve both design creativity and development efficiency while prioritising accessibility from the ground up.

Week: 1

I initiated the project by analysing the current guidelines to evaluate their accessibility and the roles that we currently assign.

Also, I interviewed about 10 designers and 5 developers about the implementation and criteria for the colour choice, how the colour palette was being implemented, and any pain points they encountered regarding keeping consistency.

Week: 2

After collecting the findings from the user interview and identifying the main opportunities, my second task was to collaborate with Deloitte’s Branding team on how to adapt the current colour palette for web use.

The existing colour palette was first thought for a printing perspective and lacked the flexibility for web applications.

Week: 3

Once the overall basic designs were set, I ran 5 usability testing sessions to test if the features were usable and useful. Any insights and feedback on them considered and if needed changed before development and delivery.

User Research

I conducted task analysis research to understand the different tasks and steps Developers performed in the current platform. I also asked questions related to their goals and how they used the information within the platform.

100%

of Developers thought that the management of the new and existing enrolments were convoluted.

Streamlining the process of managing Projects and Providers would simplify the task and allow for more efficiency when checking their APIs' health and making necessary changes.

100%

of Developers expressed concern about not having ways to look into a project’s log or send requests to providers for testing environments.

Ensure developers can access features that facilitate their work when testing and solving environments' issues.

80%

of Developers mentioned that the layout was confusing, not responsive across both web and app platforms.

Provide a clear information architecture and assume that a responsible platform would allow for an accessible platform.

Part Two:

User Flow

Participatory Design

Part Three:

Feature #1

Dashboard

This design addresses developers' concerns about the Search Gateway platform and enhances overall usability, ensuring a more intuitive and practical user experience.

The Dashboard offers comprehensive real-time updates and clear overview information of the systems, allowing developers to see system status insights. It includes a streamlined search function for quickly locating existing environments.

Feature #2

Portfolio page

the Portfolio page delivers an at-a-glance view of providers and projects, facilitating quick access to frequently used enrolments, which supports the heuristic of recognition rather than recall by minimising the cognitive load required to retrieve this information.

Feature #3

Provider's Management page

The Provider's page aimed to deliver detailed information about each environment, including its usage statistics, integrated projects, and error information. It ensures users have immediate access to crucial data and the flexibility to adjust efficiently.

This page also enables direct editing within the Swagger interface, streamlining the process for developers.

Key Learnings

Rapid prototyping and testing

The developers received the new platform well. They thought having a web and app version was helpful, although they mentioned that we should rethink what features each version would include.

Also, the new user journey felt more intuitive, and less time was spent searching for issues and understanding their causes

Project Prioritisation

This project was an initiative outside the scope of the team's backlog, so from the start, we assumed it could be put on hold at any moment. We struggled to manage the time of some of the team's main stakeholders, and the project was red-flagged, which could lead to bottlenecks and delayed milestones

I had to act quickly to deliver a solution to showcase the potential impact and benefit of the improved experience and interface to the developer's work. This approach allowed me to navigate the complexities of the project first to achieve optimal outcomes by focusing on high-impact tasks first

Value of User Research

I initially aimed to maintain feature parity across both platforms, assuming this would ensure a consistent user experience. However, through user testing and feedback, it became evident that users preferred quick, on-the-go interactions such as checking API health status or lines of code on the mobile version while maintaining the comprehensive functionality and more detailed information on the web platform

Tailoring features to the strengths and context of each platform would improve user satisfaction and engagement and address the distinct behaviours and preferences across platforms

Rodrigo Fernando

Rodrigo Fernando

Rodrigo Fernando