Ways of Working

The Data Privacy Ways of Working Principles describe how british petroluem stakeholders can work together to process personal information in a trustworthy manner and to conform to bp’s data privacy requirements.

Tools : Sketch

Role : Sole Product Designer

Duration : 3 months

Product Scope

The Data Privacy Ways of Working Principles app had to be designed to replace a lengthy, text-heavy PPT with an intuitive, role-based digital experience for bp employees. Its goal is to make it easier for stakeholders to quickly identify their role and understand the corresponding data privacy responsibilities.

The app centralizes the principles into a structured, searchable, and accessible interface—eliminating the friction of navigating through static slides. By tailoring content to user roles, it ensures employees can confidently act in alignment with bp’s data privacy requirements, regardless of location or device.

Decoding the Requirements

The project began with a detailed review of the existing Ways of Working Principles presentation. This PPT, while comprehensive, was heavily text-based and difficult for employees to navigate. The goal was to translate its dense role-based guidelines into an intuitive, interactive application. This required identifying the key user roles, mapping their specific responsibilities, and defining how the content could be reorganized for quick, role-specific access—without compromising on accuracy, clarity, or confidentiality.

To achieve this, I dissected each section of the PPT, breaking down complex legal language into simpler, actionable insights that could be transformed into structured, app-friendly formats. I paid close attention to the relationships between roles, accountability areas, and activities to ensure no content was lost in translation. This analytical groundwork served as the foundation for creating a solution that not only preserved the integrity of sensitive information but also elevated the accessibility and usability for every employee interacting with it.

Stakeholder Interviews

Given the legal complexity of the Ways of Working Principles, the original PPT was filled with domain-specific jargon and overlapping terminology. This made it challenging to interpret and map accurately into an app format. To address these uncertainties, I compiled a detailed list of clarifying questions for the Product Owner—who was also the primary user of the tool. Their input was critical in validating the content, resolving terminology conflicts, and ensuring the solution aligned with BP’s legal and data privacy standards. Due to the project’s confidentiality, direct access to other users was not possible, making the Product Owner’s perspective all the more vital.

Terminologies and Definitions

Are Guidelines and Standards interchangeable, or do they have distinct meanings?
Could you explain the difference between Principles and Policies as used in the PPT?
What are Accountability Areas?
What does ICO stand for in this context?

Maintenance and Governance

How frequently is the content updated, and who is responsible for maintaining it?
Are any of these principles legally binding, or are they recommendations?
Are there sensitive or restricted terms that must be omitted or anonymized in the app?

Audience and Scope

Who is the intended audience for this tool—only internal BP staff, or external stakeholders as well?
Which terms are global BP standards, and which are specific to certain regions or departments?

User Roles and Activities

Is a persona the same as a role? If not, what is the difference?
What are the listed activities? Do they each have associated action items?
What are sub-activities, and how do they relate to the main activities?

Structure and Content

Should the app display all principles at once, or guide users step-by-step?
What is the expected level of detail per principle—full legal text, or simplified summaries?
How should conflicts between overlapping principles be presented to the user?

Accountability and Mapping

How is the mapping of role → accountability area → activities captured (table, diagram)?
Are any activities shared across multiple roles, and does the PPT indicate priority/ownership?
What is a RACI model (responsible/approver/informed)? How is it mapped?

Personal Growth

Standing Firm on Process

Championing Direct Access for Better Outcomes

When a legal PM, bound by rigid and inside-the-box thinking, refused to let me interview the Product Owner, I recognized the risk—design decisions would be made on incomplete or incorrect information. The PM answered on behalf of the PO and expected me to proceed, but I knew this would compromise the solution’s effectiveness and user alignment.

I stood my ground, patiently explaining the value of direct stakeholder engagement and the necessity of following a user-centered design process. Through persistence, clear reasoning, and escalation when needed, I gained direct access to the PO. This not only led to accurate insights and stronger alignment, but also reinforced the importance of design integrity in delivering impactful outcomes.

Features Ideation

After multiple discussions and clarifications with the Product Owner, I translated broad requirements into a set of purposeful features that would define the product’s first iteration. This stage involved evaluating the business goals alongside user expectations, identifying gaps, and prioritizing features that would deliver the most immediate impact. I considered how each feature would support discoverability, personalization, and ease of use while ensuring the platform remained scalable for future enhancements.

The resulting feature set included persona-specific filtering to surface the most relevant results, a clear hierarchy for categorizing activities, search and sorting functions for quick navigation, and engagement-driven modules such as “Recently Viewed” and “Recommended for You.” Functional add-ons like in-app downloading and bookmarking further improved convenience, while attention to hierarchy and labeling ensured information was always clear and accessible. Together, these features created a cohesive ecosystem aimed at driving both adoption and long-term engagement.

A robust, intelligent search that retrieves results instantly, even from deeply nested sections. Supports keyword matching, role-based filtering, and relevance ranking to ensure users can locate the exact information they need without sifting through unrelated content.

Sort Functionality

Flexible sorting options such as “Most Recent,” “Most Viewed,” or “Alphabetical” to let users control how content is presented. This enables quick prioritization of the most relevant updates or frequently accessed material.

Accountability Areas Filtering

A persona-specific filter system that allows users to instantly narrow results based on their accountability areas. This reduces cognitive load by hiding irrelevant data and presenting only the responsibilities tied to their role.

Download and Share

Simple tools for exporting resources in multiple formats (PDF, Excel, or image) and sharing them securely with colleagues, ensuring offline accessibility and easy collaboration.

Persona Distinguishing

Clear visual and functional cues to differentiate between user personas. This includes color-coded indicators, icons, and tailored navigation, ensuring each persona interacts only with relevant content.

Benchmarking

Leveraging prior experience across five other projects in BP’s legal domain, I conducted a targeted benchmarking exercise. This involved studying both BP’s existing legal products and other comparable solutions in the market to identify recurring patterns, strengths, and usability gaps.

The insights from this analysis provided a clear understanding of established design norms, content structures, and interaction models within the legal domain. This ensured the new product aligned with BP’s ecosystem while introducing improvements for clarity, efficiency, and ease of use.

Note: Due to legal compliances, the benchmarking references cannot be displayed here.

Conceptual Flows

Before diving into wireframes or visual design, it was crucial to establish a clear understanding of how different user types would navigate the application and interact with its features. The conceptual flows mapped the journey from the user’s entry point to the completion of key tasks, highlighting decision points, role-based content, and interdependencies between features.

This early mapping not only clarified the product’s structure but also ensured alignment between stakeholder expectations, technical feasibility, and the envisioned user experience.

While creating these flows, new detailed questions emerged around feature behavior, role-specific permissions, and the sequence of certain actions. These questions led to further discussions with the Product Owner, ensuring that the flows were grounded in accurate requirements and reflected the realities of the legal and compliance framework.

Personal Growth

Designing Within Constraints

Turning Technical Limitations into Creative Opportunities

This project was to be developed in Power Apps—a platform known for its speed and simplicity, but also for its strict technical limitations due to its drag-and-drop nature and predefined UI components. Before designing, it was critical to first understand the tool’s capabilities and constraints to ensure that my solutions were both creative and feasible.

As the sole designer on the project, I took the initiative to deep-dive into Power Apps. I researched independently, reached out to the design community, and actively sought peers with prior experience on the platform. This led me to connect with an expert designer with over 20 years of Power Apps experience. Through these conversations, I gained valuable insights, practical tips, and a clear understanding of the design levers I could work with. Equipped with this knowledge, I was able to design an experience that maximized the platform’s strengths while working around its limitations—without compromising on usability or visual appeal.

Information Architecture

After getting answers to the questions raised during the conceptual flows stage, the next step was to define a clear and logical structure for the application’s content. The Information Architecture mapped out how information would be organized, labeled, and accessed—ensuring that users could intuitively find what they needed without unnecessary clicks or confusion.

Special attention was given to role-based segregation of content, ensuring each user persona could easily navigate to their relevant accountability areas, activities, and supporting resources. This foundation served as the blueprint for navigation design, feature placement, and content hierarchy throughout the application.

Low Fidelity Wireframes

With the feature set defined, I translated the concepts into low-fidelity wireframes to visualize the application’s structure and interactions before committing to detailed design. The goal was to focus on layout, navigation flow, and information hierarchy—ensuring that every screen aligned with both user needs and technical constraints. These wireframes served as a collaborative tool, enabling quick iterations based on feedback from stakeholders and developers, and reducing the risk of rework later in the design process.

Personal Growth

Driving Implementation Excellence

Going Beyond Design to Make It Happen !

Armed with insights from my Power Apps research and expert guidance, I designed the most refined and user-friendly UI possible within the platform’s constraints. Where limited customization was allowed, I used it strategically to elevate the experience. However, when the designs were handed over, the developer claimed several elements— including the standard bp font used across all applications—were “not possible” in Power Apps.

Knowing these features were possible, I refused to compromise. I dove into detailed coding research, uncovering exact methods to achieve the intended designs in Power Apps. Then, going beyond my role as a designer, I literally taught the developer how to implement the code—step by step—so they could tweak and customize the application to match the vision. This hands-on intervention ensured the final product didn’t just resemble the concept; it fully embodied it, setting a higher standard for what’s achievable within platform constraints.

Visual Design

Once the wireframes were validated, I moved into the visual design phase, bringing the application to life with branding, typography, and color choices that aligned with BP’s design system. I had to work within the BP design library, set of guidelines, and established design system, ensuring every component adhered to brand standards while still feeling fresh and user-friendly.

This stage focused on creating a polished, intuitive interface that not only met functional requirements but also reinforced trust and clarity for users. Every element—from spacing and alignment to color psychology—was carefully considered to ensure accessibility, consistency, and a seamless user experience across devices. The visual design also balanced creativity with the technical limitations of Power Apps, ensuring that the final UI could be implemented without compromising the design intent.

Challenges

Blocked from Stakeholder Access

At the very start, a legal PM shut the door on my ability to speak with the Product Owner—insisting all communication go through them. Every answer came filtered, and I could feel the risks mounting: key details lost in translation, assumptions replacing facts. Instead of accepting the constraint, I made my case—calmly, persistently, and with evidence of how direct engagement would protect the project’s success. After several rounds of pushback and a well-timed escalation, I earned direct PO access. From that point, our conversations brought clarity, accuracy, and alignment that would have been impossible otherwise.

Designing on an Unfamiliar Platform

The catch? Everything had to be designed in Microsoft Power Apps—a platform I’d never touched, bound by strict BP brand rules and frustratingly rigid customization options. It could have meant stripping away the very interactions and polish that make a product intuitive. Instead, I treated the platform like a puzzle, exploring every function, learning its quirks, and stress-testing its limits through rapid prototyping. I found ways to bend constraints without breaking compliance, delivering a design that felt seamless to users even within the platform’s guardrails.

Developer Pushback on Feasibility

Midway in, the developer told me several design elements—including BP’s own brand font—were “not possible” in Power Apps. I knew that wasn’t the whole story. I dug in, experimenting with alternatives and uncovering workarounds they hadn’t tried. Once I had proof, I didn’t just hand over the solution—I walked the developer through the process, effectively teaching them how to make it work. That moment flipped the tone of our collaboration: instead of compromise, we delivered a final product that matched the vision down to the details

Simple build, complex battles—worth every one :)

The app itself was straightforward in architecture and functionality, but the process was a different story. It tested my patience, persistence, and ability to advocate for design integrity. I learned to stand firm for what truly serves the user, while mastering a completely new platform.

In the end, I walked away not just with new technical skills, but with a stronger voice as a designer—confident, resilient, and proud of the work delivered.