.svg)
When large organizations like UN agencies start to shift their internal and external software development processes to product processes, UX is often called to create a baseline of the current situation. In 2026, we travelled through almost all areas of such an organization and helped understand user experience: from client-facing legacy software to travel and expense management, procurement and communication.
Bringing Human-Centered Design to the inside of large organizations
Glashaus' mission had three levels. First, we assessed the experience of internal users (staff) and external users (delegates and technical experts). Second, we showed how UX insights can guide product development alongside technical and business requirements. Third, to make this shift last, we built interest and basic capacity in the teams to run early-stage user research themselves, and to know where and when to bring these insights into decisions.
How might we anchor user-centered approaches to software development in large and complex UN organizations?
Systematizing user experience: how Personas and Journeys open the field for a debate on user-centered decision making
Many UN organizations are in the middle of a shift from projects to products. Teams are organized around deep subject-matter expertise, and every system has to serve many collaborating teams across departments, sometimes across agencies. In a setting this complex, we started by creating shared sources of truth for discussion and decision-making: mapping the needs and pain points of different Personas in the context of their Jobs-to-be-done, and showing how their experience unfolds along their User journey within each tool.
To start understanding an experience, we ran individual show and tells. Usually online interviews, where our interviewees shared their screen and showed us their day to day work with the tool in question. This helped us understand how users were using the tool in question currently. While showing their processes (and often impressive workarounds), discussions about needs and pain points started naturally and we could capture context information: “where, when and how do users access a software?” often makes a big part of their experience.
The Personas we created were often organized on a first level around job functions that shaped how and why they access the tool. In a next step, it was very insightful to ask: what other groups exist? Depending on the software, other dimensions matter just as much. How do staff and external users approach the tool: are they fluent in AI prompting, or new to it? And how long have they been using it? Early adopters experience a tool very differently from someone who has worked in the same routine for decades.
When we mapped the interaction of different users in Journeys we could clearly show each step, and thus make the experience visual and understandable from different standpoints in the organization: What are users trying to accomplish here and what are their difficulties?
Finally, we always end by highlighting opportunities for change to leadership and offer frameworks to prioritize and manage opportunities, like the MoSCoW framework or simple impact/effort matrices.
In 11 months, we gave many problems a name, backed by evidence:
Across every system we studied, one pattern kept surfacing: fragmentation. A single process spread across several systems, inboxes, spreadsheets and people, none of which holds the whole picture, and wherever we looked, it had the same effects: Users become the integration layer. They copy the same data from one system to the next, track status in tagged emails, and send screenshots to move a request along. It gets difficult to see where things stand. Trust erodes, and workarounds turn into shadow tools that nobody planned. Knowledge ends up in people rather than systems: to find a document, you have to know the year it was issued. Making this pattern visible, with evidence from every corner of the organization, gave teams and leadership a shared starting point for what to fix first.
With this long term engagement, we created the expectation to have user experience evidence before and during decisions. Teams were equipped to prioritize user needs as well as their own quick wins in software redesigns. For leadership, we could clearly separate software problems from policy problems that needed to be addressed outside of software and design reviews.
Our organizational capacity building services help organizations see their systems through the eyes of the people who use them. We map how staff and external users actually work, turn pain points into prioritized opportunities, and coach your teams to run early-stage user research on their own. It's ideal for:
We customize every project to your needs. Whether you need evidence for one system or a starting point for user-centered ways of working - we'll help you scope the right approach.
"Most problems in large organizations are already known. Our job is to give them a name, back them with evidence and make them open to discussion." — Charlotte, Research & Strategy Lead | Glashaus Innovation
.png){kind=icon}