Projects

Context

4Subsea develops monitoring and integrity-management software for the offshore energy industry — tools used by engineers responsible for assets in demanding, high-stakes environments. I have been the sole UX practitioner on the team, which means my responsibilities cover the full scope of UX: from individual component design to the overall structure and consistency of the platform. I have shaped the tool from its early engineer-designed beginnings through a number of iterations.

Challenge

The platform had grown product by product, without a unified design foundation to keep it consistent. The result was variation in interaction patterns, terminology, and navigation that created unnecessary friction for users. At the same time, the company was expanding its user base, which made addressing those inconsistencies more urgent.

Constraints

Working as a solo practitioner in an engineering-led organization means managing competing priorities. The users are experienced engineers with well-developed opinions about their tools, as well as limited availability for formal research sessions. Hence, research must be embedded into existing workflows rather than staged separately.

In addition, developer resources are extremely limited, and any time they devote to design implementation means less time they can spend on core functionality. So design must progress in small, spaced increments and through compromise.

What I Did

First steps

One of the early goals was to adopt and refine the company's first design system, bringing more consistency and an updated look across products. I then led an initial platform-level usability redesign focused on fixing some of the biggest usability issues with the platform.

Later steps

With the exception of localized page additions and redesigns, we maintained that overall design for several quarters while I focused on a more complete overhaul to address remaining issues, and dev returned to the backend. The refresh will be squeezed into and spread across several sprints the next couple of quarters.

AI

The design system and all page designs used to live in Figma, but both now reside in GitHub repos that I maintain. I converted them into HTML, CSS, and JavaScript files via Claude Code, worked for a couple of months to get everything looking as it should, constructed design.md and other guidance docs based on them, and now modify them and create new pages via iterations with Claude.

Compromise

It's worth emphasizing that every component on every page has been a compromise in design. Business objectives, user needs, consistency, and the need to minimize developer effort continually combine to dictate the result, with me judging when to push for high-priority items.

What I Learned

Compared to my other projects, the main learnings in this one were more on the team and organizational side than on the design one. When development resources are a severely limiting factor, UX becomes just as much a matter of communication and negotiation with your team, your stakeholders, and your leadership as it is of research and design.

Context

The client performs analyses that are critical to national security. A recent and significant increase in workload had created two related pressures: a need to increase throughput, and a need to get more value from the data already available.

My company had a set of backend tools that, combined, would support those needs. However, no user interface tied them together, and the analysts had no existing visualization or interface of any kind to build upon. So a cross-company team of developers, risk engineers, and myself had to create something new.

I was the sole UX person on the team, and my role covered the full range of UX activities on the project: all user research, interaction design, and prototyping.

Challenge

The key decision the risk analysts make is whether there is a likelihood of some security threat. Making that decision involves looking for patterns across different kinds of information existing in multiple heterogeneous sources. We had tools that could help with the synthesis of that information, theoretically enabling both better efficiency and higher informational value.

What we did not have was a window into that synthesis: a common, dynamic threat picture that would present multiple information sources and highlight connections between them that would otherwise go unnoticed.

Constraints

The client's requirements for the deliverable were specific and, in combination, demanding. The interactive prototype needed to demonstrate, credibly, that the proposed solution could reduce analysis time and improve risk detection. It also needed to look polished enough to convince the funding agency that the concept was feasible — not a rough sketch, but instead something that looked like a real product. And it needed to be able to demonstrate the solution concept within a few minutes.

The deadline left me with approximately 100 hours over the course of 5 weeks for all research, design, and prototyping work.

What I Did

The first step was to set client expectations. Their ambitions exceeded their timeline, so we worked with them to see this project as an initial step in a much larger effort — a means to form and demonstrate the concept for a solution.

The second step was tight scoping. Working with both the client and my own team, I defined a very specific scenario: a single incident, a sequence of activities the analyst would perform in response to it, and a clear endpoint. This level of specificity was essential given the time constraints. It meant I could focus my research on only those user actions, decisions, and needs that fell within that scenario. It also meant I could design only the portions of the interface that scenario would actually touch. And it meant I could add only as much interactivity as was needed to support a scripted demonstration.

For the prototype itself, I used Figma and worked from a generic design system, which allowed me to save time that would otherwise have gone to building foundational components from scratch. The actual design work is confidential and cannot be shared publicly, but the outcome of the process was a successful demonstration that satisfied both the client and the funding agency.

What I Learned

This project involved the largest set of compromises I had faced up to that point in my career. Both the research and the design were far from ideal given the time available — user research was minimal, and design iteration was necessarily limited. However, the combination of early expectation management, tight scenario scoping, and a clear focus on a single use case produced something that satisfied the client.

The central lesson was one of scope: When time and money are limited, the most important thing is to define a very small, very specific target — and then hit it cleanly.

Context

Much of DNV's expertise reaches clients and the public through charts and diagrams: the uptake of alternative fuels in shipping, the effect of future regulations on a ship's emissions, the structure of the models used to assure complex systems. Those visuals are usually made by the subject experts themselves, who know the content intimately but are not necessarily trained in presenting it.

Between 2020 and 2022, I became a go-to person in several departments for two kinds of help: translating complex graphics into a form that both laypeople and experts could understand, and creating new visuals to convey complex concepts and processes.

Challenge

The original visuals often tried to show everything at once. Many data points competed for attention, unsorted categories made comparisons slow, colors were hard to tell apart, and secondary details such as medians or decorative 3D effects drew as much attention as the main point. Seeing a trend sometimes meant comparing two separate charts from memory.

The challenge was to make the most important information obvious at a glance, without losing the nuance the experts cared about.

Constraints

The content always belonged to the teams. Each redesign had to keep their data and the distinctions they considered essential, and their priorities sometimes shifted as we worked, so a design that was nearly finished could need rethinking.

The audiences were also mixed. A chart might be read by engineers and by people with no technical background, and conventions that are familiar to one group, such as box-and-whisker plots, can be opaque to the other.

What I Did

Every visual started with a conversation with the team about what they really wanted to say. Who is the audience? What specifically should they learn from this visual? What is the key information they need to get there? From that, I sorted the content into primary information, which belongs in the foreground, secondary information, which can sit in the background, and anything nonessential, which can go.

Then I looked for inspiration in references such as chart catalogs and visual vocabularies, and sketched. Most visuals went through many iterations, each shared with the team, as we traded off clarity against completeness. The last step was polish for print or release.

A few rules of thumb guided the work: be ruthless about unnecessary visual detail, because it competes for attention; use styling to separate foreground from background; use color, shape, and position to link related things without accidentally linking unrelated ones; avoid relying on color alone; and prefer bars and small multiples over pie charts and stacked bars, which make accurate comparisons difficult.

Eventually one department asked me to teach this. I gave a workshop on designing information that meets user needs, walking through the process and a series of before-and-after examples from my own work.

What I Learned

The hardest part of a visual is rarely the drawing. It is deciding what the visual should say, and that decision belongs to the people who own the content. Settling the message with the team up front made the iterations faster and the results clearer.

It also confirmed that the quickest way to make a visual clearer is usually to take things away. Almost every improvement in these examples came from removing, softening, or regrouping elements rather than adding new ones.

Context

WindGEMINI was an early-stage digital service at DNV GL that combined turbine sensor data with engineering models to flag problems on wind farms: drivetrain temperatures that might indicate faults, structural wear that could shorten a turbine's life, power curves pointing to incorrect settings, and production that fell short of what the wind should have delivered.

The tool worked, but it had a small user base and one main customer. I joined as UX lead from DNV GL's Digital Frameworks and Tools group, working alongside the product team, to help them understand who the tool was for and how to make it more valuable to them.

Challenge

The team wanted to verify their assumptions about their target users, understand those users' needs regarding real-time and projected turbine performance data, and assess how well the current tool met them. Just as important, they wanted to find related opportunities: other kinds of users, and other needs, the tool might serve.

That turned into a set of research questions. Who are the target end users, and what are their responsibilities? Are they the same people who make purchasing decisions? Who do they share their findings with? What turbine information matters most to them? What usability problems lower the tool's value, and which of their needs does it not meet?

Constraints

Wind farm performance analysis is a specialized field with few practitioners, so participants were scarce and their time was limited to about an hour each. Surveys, which would normally help validate interview findings, are of little use with a population that small.

The direction of the work was also unusual. User research is well suited to building solutions that help people, but it is much harder when the goal is to find people in need of a solution that already exists.

What I Did

I started with a strategy that set out the goals, research questions, methods, and participant types, and then held semi-structured, one-hour interviews with current, former, and potential users at wind farm owners, operators, and consultancies, including Ørsted, Contour Global, and DNV GL's own consultants. Some interviews were generative, covering what people were trying to get done and how; others were evaluative, covering their experience with the tool.

The interviews showed that the core users were people at asset owners whose work depended on assessing turbine performance and health, and that they often built the case for buying the tool themselves, so marketing could be aimed at them directly. Those working as consultants needed to share their findings, which pointed to an export feature for graphs and tables. Nearly everyone found the tool too slow, too many clicks away from the important information, and its alerts too often wrong.

Most requests for new features involved diagnosing faults, which was outside the tool's intended scope. Turbine life, on the other hand, interested people at older farms and at banks that own farms, but those roles were too new to be easy to find. The main customer named a few specific measures, such as lost production factor and forced outages, that would let them drop a competing tool.

Design work during this phase was limited to revising individual graph types. Based on the feedback, I recommended a larger overhaul of the page layouts and interactions, and put together a plan for the following year: an ecosystem map of the wind power industry, interviews on the manufacturer and farm side, personas, cognitive task analysis, usability testing, and analytics to show which dashboards were actually used.

What I Learned

Searching for a market for an existing tool is a different exercise from designing a tool for a known need. Interviews were good at showing how current users worked and where the tool fell short, but finding new users meant looking for people whose roles were barely defined yet. A map of the whole ecosystem would have been a better starting point than a list of the people we already knew.

It also showed how quickly user requests can pull a product away from its purpose. Almost everyone wanted help diagnosing faults, and adding it would have made the tool more useful to them, but also less clear about what it was for.

Context

The team behind this project wanted to build a tool that would cover the full negotiation process between companies that have fuel and ships that need it, giving the parties involved a shared environment for reaching agreement. My role was to get the project off the ground: definition, research, concept development, and prototype testing.

Challenge

Ships at sea frequently need to negotiate unplanned fuel purchases with nearby suppliers — an activity that occurs over the phone or radio with regularity but has no dedicated tooling to support it.

Constraints

The target users for this project were highly specialized and relatively few in number, and also wary of what might read as a sales pitch. Access was consequently limited to a very small number of users for roughly an hour each. That is not an ideal research situation, but it was the realistic one, and it was considerably better than the alternative of continuing to work entirely from assumptions.

What I Did

On joining the project, I worked with the team to clarify their objectives and map their existing understanding of the current activity. This included producing a diagram of the customer journey as the team understood it at that point — the steps, the actors involved, the assumed pain points. I then compiled what we needed to know and what we needed to verify, which led to a set of initial questions to take to actual users.

Rather than attempting to get a complete account of the full negotiation journey in that limited time, I focused on gaining a high-level view of the key steps and then digging into the areas that seemed most challenging or painful. The method was semi-structured interviews combined with task analysis. The research made one thing clear: Building a tool intended to support the entire negotiation process from start to finish would mean competing directly with established tools like Outlook and Excel, which did not fit the team's timeline or available resources.

The same interviews that ruled out the broader scope also pointed toward something more tractable. Scheduling — a specific part of the negotiation process involving the coordination of times and locations across multiple parties and communication channels — was a huge hassle. The back-and-forth it required, spread across a number of different channels and involving a number of different stakeholders, was identified as a point of friction.

I proposed that the team focus specifically on supporting that activity rather than attempting to cover the full negotiation process. The research provided a clear rationale for the pivot, and the team accepted it.

Multi-party remote scheduling is a dynamic, time-sensitive activity that is difficult to convey through static mockups. To communicate the concept effectively, I built a visually simple but highly interactive prototype in Axure to demonstrate the essential mechanics of how the scheduling interaction would work. The prototype was shown first to the project team and then to the users who had participated in the earlier interviews.

The response was positive. Although I moved to another project at that point, the team continued in the direction the research and prototype had established. The designs produced during this engagement served as the foundation for the product that was eventually released.

What I Learned

The most significant constraint throughout this project was user access. With such a small sample of participants, the findings could not be validated as thoroughly as would be ideal. Decisions made on the basis of that research therefore carried a degree of risk — which is a real limitation, but also a characteristic of early-stage innovation work, where waiting for a larger or more representative sample is often not a realistic option.

In this case, the risk proved acceptable. The direction the research pointed toward turned out to be viable, and the product that emerged from it was released. The central lesson is that limited user access does not eliminate the value of research. It simply requires being more deliberate about where to focus time and attention.

Context

A team at Yara had in mind a matchmaking service designed to support small coffee farms, connecting producers with buyers in a more direct and transparent way. My role was to lead the research effort: to map the field-to-cup journey, understand the actors involved, and determine where the team's concept might actually find a foothold.

Challenge

The opportunity space was not well defined, and the team was operating largely on assumptions about where in the coffee ecosystem a viable product might fit.

Constraints

The target users for this project, coffee buyers and roasters, were relatively accessible and generous with their time compared to many of the specialized professional communities I have worked with. The subject matter itself presented a different kind of challenge: The journey of a coffee bean from field to cup is genuinely complex, involving a large number of actors, geographies, and commercial relationships, each with its own logic. Mapping and making sense of that system was a satisfying research challenge — and one that was still well-contained enough to yield a coherent picture within a reasonable timeframe.

What I Did

The first step was to work with the team to clarify their objectives, align on what they hoped to learn, and surface the knowledge they already had. This involved documenting their understanding of the field-to-cup journey, their existing assumptions about actors and pain points, and the gaps in their information. The process also identified which actors in the coffee ecosystem the team had in mind as potential users. Based on access considerations, we decided to approach coffee buyers first. That decision shaped the initial set of research questions.

Through a combination of company sales contacts and my own networking, I identified and interviewed a number of people responsible for purchasing decisions at local coffee buyers. The method was semi-structured interviews combined with task analysis. The interviews produced a detailed picture of the field-to-cup journey and the actors involved at each stage, the pain points distributed across it, the key purchasing decisions buyers faced and the variables that shaped those decisions, and some early feedback on the feasibility of the team's concept.

The findings from this first round, however, did not reveal the kinds of clear opportunities for supporting coffee buyers that the team had hoped to find. The buyers had existing tools and processes that served their needs adequately, and the space for a new matchmaking service was not as open as the team had assumed.

While the first round of research did not confirm the team's original direction, it pointed clearly toward a different actor in the ecosystem: coffee roasters. The interviews with buyers had surfaced enough information about the roaster side of the relationship to suggest that the purchasing dynamics there might be more receptive to the kind of support the team had envisioned.

I conducted a second round of interviews focused specifically on purchasing activity within local roasters. This round identified a number of potential areas that might benefit from the kind of matchmaking and transparency the team had in mind. The team then entered an ideation phase, using the research findings as the foundation for generating and evaluating product concepts.

What I Learned

This was one of the more enjoyable projects I have worked on, both for the richness of the domain and for the way the research process itself unfolded, with one round of findings redirecting the effort toward a more promising area.

Context

The topic was sewer corrosion: the slow degradation of pipe infrastructure that, if left unaddressed, eventually leads to ruptures and the significant costs they bring. The goal was to help the people responsible for managing sewer systems understand the current state of their infrastructure, what their options were for addressing it, and how those options compared to one another. The strategy was an application that would simplify data entry and present the results in a way that would be understandable to non-expert users, not only the engineers who understood the underlying models but also the managers and decision-makers who needed to act on the outputs.

Sewers corrode over time and eventually fail. The people responsible for managing them need to make a set of interconnected decisions: how severe is the current corrosion, whether the present moment is a good time to invest in repairs, whether pipe replacement might be a better long-term investment than repair, and how long they can realistically delay a decision without incurring greater costs later. The company also wanted to surface a fifth option, the use of its own chemical treatments to extend pipe lifespan, as part of the comparison.

Challenge

An existing Excel-based tool covered all of the above, but it required a substantial amount of user input and produced results that were difficult to interpret even for subject-matter experts. The goal was to redesign it as an actual application — one that would be both more efficient to use and more legible to a wider range of users.

Constraints

Some degree of data entry was unavoidable. The underlying estimates required information from the user, and there was no way around that. The challenge was to make that entry as efficient and as low-friction as possible. Equally important was making the outputs of those estimates comprehensible to users who did not have deep familiarity with the domain models behind them.

What I Did

I focused on a set of design strategies to address both concerns:

• Chunking the data entry process into smaller, more clearly bounded steps, rather than presenting it as a single undifferentiated form.
• Using selection interfaces (dropdowns, sliders, and option groups) wherever possible rather than requiring users to type in values, which reduced input error and cognitive load simultaneously.
• Supporting situation awareness by making four things clearly visible: the current state of the system (corrosion level and rate of change), the future state (estimated remaining system life), the available options (costs and lifespan implications of replacing, repairing, or applying chemical treatment), and the time constraints on the decision.

The designs were produced in Sketch and went through a number of iterations before reaching a final state. The final deliverable covered both mobile and desktop breakpoints, as the company had a preference for optimizing the experience for mobile use, reflecting where and how the target users would most often be accessing the tool.

The project also required applying the company's existing branding and style guide, which I rebuilt in Sketch and adapted as needed for the conventions of a web application context, where the original guide had not been designed with that environment in mind.

What I Learned

Looking back at this project, there are a number of design decisions I would approach differently today. The desktop version in particular has a wizard-style look and feel that steps the user through a linear sequence of inputs, which I now find somewhat limiting as a design pattern for this kind of tool. It works, but it constrains the user's ability to move freely between sections or revisit earlier inputs in response to later ones. The data visualizations, also, could be more refined and more precisely calibrated to the information the user needs to act on.

Context

This was part of a multi-company, multiyear research project for the EU that focused on tools for improving drone use in search and rescue (SAR) during crisis situations. Drones are increasingly used in SAR operations, providing aerial coverage, thermal imaging, and real-time video that can make the difference in locating a missing person.

In practice, though, their use can be haphazard, because (at the time) field commanders directing SAR efforts had no direct view of where the drones were operating or what they were recording. That information reached them indirectly, via radio from drone operators positioned elsewhere on the scene. The result is a significant gap in situational awareness at precisely the level where overall coordination decisions are being made.

My company (SINTEF) was part of the consortium building this solution, and I led the design of the command console for it. My responsibilities covered needs identification, requirements generation, human-factors considerations, wireframing, and evaluation. End users were involved throughout the project, contributing through interviews, workshops, participatory design sessions, and usability tests.

Challenge

Our goal was to provide first responders in search-and-rescue operations with a system through which they could locate the drones operating on scene, direct their movements, and monitor their feeds. We wanted to give field commanders a direct, real-time picture of the aerial assets under their coordination rather than a secondhand account of what those assets were observing.

Constraints

The project team included approximately a dozen partner organizations — a mix of academic institutions, corporate partners, small and medium-sized enterprises, and research groups distributed across Europe. The coordination challenges that come with that kind of distributed, multi-stakeholder structure were considerable.

A separate challenge was the nature of the domain itself. Search-and-rescue events occur infrequently and unpredictably, which made it difficult to observe them in realistic conditions or to test design solutions in the field. The team had to be both strategic and opportunistic — building research plans that could adapt to whatever opportunities arose, while also looking ahead to scheduled events, such as product demonstrations and first-responder training exercises, that would provide access to real users in relevant contexts.

What I Did

The project followed a user-centered design process structured across a couple of years and divided into two broad stages: research and iterative design.

The research stage began with a domain analysis: reviewing previous projects, studying existing systems, talking with field experts, stakeholder workshops. Then I built a map of the interactions between different roles in a typical SAR operation. It showed how information flowed between them, what decisions each role was responsible for, and where breakdowns in coordination tended to occur. The output of this stage was a set of user requirements for the system interface.

The design stage proceeded over a number of iterations, each separated by workshops and evaluation sessions with users. The deliverables included usage scenarios developed to focus and constrain the design effort, as well as wireframes, mockups, storyboards, paper prototypes, and working prototypes.

What I Learned

Early in the project, my team discovered that the implementation being developed by the technical partners had diverged in a number of ways from the UX designs, which required additional effort to diagnose and correct. This served as a clear illustration of the importance of establishing explicit communication channels between design and development in any distributed project team — not as a formality, but as an active and ongoing practice.