Earlier this year, I had the chance to speak at Google Next '24 in Vegas. The topic? "Breaking Silos Worldwide."

While prepping, I started thinking about how we've been tackling this within  UNOPS (United Nations Office for Project Services ) – especially from a UX perspective. It's a common challenge: many organisations end up with a bunch of custom-built systems 

 various vendor solutions (SaaS or PaaS). This ends up creating a disjointed experience for users – they're constantly jolted as they switch between different applications.

We could just tell users to deal with it, right? After all, it's not like we have total control over everything. And honestly, that's probably the most common approach. But I think there's a better way.

A while back, I decided to fully embrace our main vendor ecosystem – for us, that's Google Workspace. It's the productivity suite for everyone at UNOPS, although we do use other vendor ecosystems like Atlassian and Salesforce.

For me, this "leaning in" meant finding ways to blur the lines between our in-house apps and Google Workspace. This started with adopting Google's toolbar design in our intranet:

We continued with other designs that aimed to match the Google Workspace feel:

I know, I know – it's easy to say these designs are just copying Google. But remember 

Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know.

If your users are already familiar with something, why make them struggle with something different? It might not be the most groundbreaking approach, but it 

. There are times when I deviate a bit from this, often by using Material Design. This is mainly because I'm aiming for some consistency, and let's be real – I don't have Google's research budget!

kay, now back to that "multiple ecosystems" thing...

Obviously, I'm not suggesting we force Material Design into Atlassian or Salesforce. When we're working directly within those ecosystems, we of course stick to their design language.

 working within a specific ecosystem, I think about "proximity." Certain groups of people use certain sets of applications, and some tasks naturally flow together. When those are more aligned with one ecosystem, it makes sense to adopt that design language for related products and tools.

In short, to create a more cohesive user experience within a multi-vendor environment, we've chosen to prioritise familiarity and consistency by aligning our in-house designs with our main vendor ecosystem, Google Workspace. This doesn't mean we blindly copy everything, but rather we strategically adopt elements to reduce user friction and create a sense of continuity across platforms.

Blurring Boundaries

Have you ever thought about how the way we design products is a bit like sculpting? It might seem strange, but hear me out.

Every time we add something to a product, we make it more complex. More complexity equals more mental effort for our users, also known as cognitive load. This cognitive load can be split into two types: intrinsic (the unavoidable difficulty of the task itself) and extraneous (the extra effort caused by how the information is presented).

When we make a product overly complex, we're likely adding to the extraneous cognitive load. This makes it harder for users to do what they want and makes the whole experience less enjoyable. The end result? Lower user satisfaction and less chance of our product being a success.

So, where does sculpture fit into all this?

Michelangelo famously said, "The sculpture is already complete within the marble block, before I start my work. It is already there, I just have to chisel away the superfluous material.”

Think of your product as that marble block, and your delete key as a chisel. You can chip away at your product to reveal its purest, most essential form – the core function without all the unnecessary extras.

Like Marie Kondo tidying up a house, ask yourself, "Does this feature truly serve the essential function, or is it just here because someone asked for it, or I thought it was cool?" The art lies in knowing what to remove.

Software, thankfully, is more forgiving than marble. We have version control and saved designs, so mistakes can be undone. If you get a little overzealous with your chisel, don't worry – it's not the end of the world.

I know what some of you are thinking. "But my product is super complex! And my stakeholders are impossible!"

For truly complex products, we need to accept that some level of intrinsic cognitive load is unavoidable. 

reminds us that every system has a certain amount of irreducible complexity. But that doesn't mean we can't make it better! We can use techniques like 

, adaptive, and predictive complexity (but that's a topic for another day).

As for those unreasonable stakeholders... well, let's just say my answer is probably best left unsaid.

The next time you look at your delete key, see it as a creative tool, not just a destroyer of digital worlds. You might be surprised at what you can sculpt.

Complexity & Sculpture

Conception, design and implementation of a toolbelt of interstitial tools, that exist between UNOPS (a UN agency) products, to support colleagues’ daily work.

The product is a direct response to the agency’s difficulty in realising its investment in knowledge due to disparate sources and an incredibly diverse user base. Tools included for the initial release- a product launchpad, an organisational knowledge finder (based on Google Vertex AI) with a virtual colleague (based on Google Vertex AI) and a centralised notifications/actions channel following in a subsequent release.

Enhance our colleagues ability to work by providing tools that are aware of our organisational context, within our application landscape but not part of applications.

by leveraging tools for improved utilisation of both in-house and SaaS applications, while also addressing tasks beyond the scope

Whilst remaining apart from applications tools can make use of integrations to interact with them and allow users to perform quick actions out with an application context.

Initially Toolbelt plans to address four key needs.

UNOPS has an extensive application landscape which is constantly evolving. Coupled with this UNOPS has an incredibly diverse workforce which is constantly evolving. New, and existing, colleagues find it a challenge to locate known applications and discover new ones.

Launchpad is a Toolbelt tool that supports application discovery and allows users to use predefined application lists or create their own custom lists. It supports a set of core applications that are important to the organisation but also allows users to add their own applications and other URLs.

UNOPS has a large unrealised investment in structured and unstructured data. This exists in a large number of disparate repositories across BigQuery, Drive, Atlassian Confluence & Jira amongst others. It is challenging for colleagues to know of the existence of these repositories, which repositories may contain the desired information and how to search for it.

Find is a Toolbelt tool that supports a single interface for colleagues to search for the desired information across the range of available repositories.

Having a "virtual colleague" to assist on the tedious tasks would free up time for more creative collaboration with human colleagues, strengthening relationships, and emphasising strategic thinking. This would enhance innovation and quality in the professional environment.

Omni is a Toolbelt tool that supports colleagues in a conversational manner with knowledge discovery, creative input and other convenient task completions.

Many applications within the UNOPS landscape require colleagues to perform actions when prompted. Common mechanisms of prompting are email and in-app notifications. Colleagues are experiencing increasingly overloaded inboxes and prompts can be missed. In-app notifications are by nature only discovered when a colleague is in the app.

Updates is a Toolbelt tool that provides a common point to surface prompts from many applications and a means to easily complete simple actions without navigating to the app. This can allow users to complete many actions without the additional cognitive load of application context switching.

Toolbelt & Virtual Colleague

An internal kit of tools that can be combined in order to support product management and product managers within a UN agency.

The toolkit consists of a mix of documents that tackle topics such as Design Sprints, Product Roadmaps, Design Critiques, Measuring User Satisfaction and High Performance Team techniques amongst others. The documents were written to concisely offer advice and guidance to product managers at a time were the product management practice was emerging. The documents continue to serve the purpose as aide-mémoires and practical guides for continued practice.

The advice given within the documents dovetails with other tools from the kit and with internal systems used by the organisation to manage its day-to-day digital activities. 

One of the larger tools is an end-to-end framework to support UNOPS’s emerging product management practice and product managers. This framework collates internal tools and articles that I’ve created alongside external tools and articles that I’ve found useful when coordinating product management activities within UNOPS.

The framework guides product manages through the five key stages of the product lifecycle. 

The framework is intended to be a light touch approach where buy is in voluntary and based on the value the framework brings rather than as a top down compliance mechanism.

Although the framework is presented as a checklist, it is not prescriptive and some of the steps are not mandatory, with the mandatory steps being easily distinguishable.

The checklist is broken up in to sections the five key stages and the product manager is invited to duplicate the Delivery and Iteration tabs as you need them to support iterations (V1,V2,V3...) of their Product. There is also provision within the tabs to allow for the repetition of sections such as Build(s) in Product Delivery. These are suffixed with (s) to act as a visual hint for the product manager.



Product Management Toolkit

This website, like a trusty map, uses a few digital breadcrumbs (cookies) to make your journey smoother. Don't worry, these aren't the kind that crumble on your keyboard – they're the kind that help us understand how you use the site and remember your preferences.

 These are like a compass, showing me which paths you take and where you spend the most time. This helps us improve the site and make sure it's always headed in the right direction.

 These remember your preferences (like your darkmode choices - don't worry we don't judge), so the next time you visit, everything will be tailored just for you – like finding your favourite trail marker already flagged.

You're the captain of your cookie ship! You can adjust your preferences through your browser settings or our cookie control panel. Just keep in mind, without these cookies, your journey might not be quite as personalised.

We take your privacy seriously and follow the GDPR regulations like a seasoned navigator. We only collect the data we need and keep it as safe as buried treasure.

If you have any questions about our cookie policy, feel free to drop me a 

Thanks for exploring my site (and reading this notice)!

Cookies

Cookie Crumbs: Just the Good Stuff

Why Leave a Trail:

Your Cookie Compass

Smooth Sailing with GDPR

Questions?