This project focused on improving how users publish, overwrite, manage, and understand architecture views across different lifecycle states inside a complex enterprise modeling environment.

The goal was not only to improve usability, but to make complex lifecycle behavior more predictable, reduce publishing uncertainty, and help the team focus the first iteration on the workflows that created the highest trust risk.

My Role: Senior UX Designer

Responsibilities: UX Strategy, User Research, Workflow Definition, Interaction Design, Enterprise UX, System Logic Thinking, Usability Validation

Platform: BlueDolphin Enterprise Architecture Platform

Users: Enterprise Architects, Business Analysts, Technical Consultants, Process Managers

BlueDolphin users worked with complex architecture views that were frequently shared, updated, published, and reused across teams.

One of the biggest UX challenges was the lack of clarity around publishing behavior and historical states.

Users were often unsure about:

• What happens when publishing a view with the same name
• Whether an official view would be overwritten
• Whether historical versions could still be accessed
• How archived or deleted objects should behave inside older views
• Which version represented the latest trusted source

This became especially critical because these views were often referenced by multiple teams and departments simultaneously.

The challenge was not only visual.

It was connected to governance, trust, lifecycle management, historical traceability, and collaboration across teams.
A small publishing mistake could affect how multiple teams understood the same architecture view.

The project, therefore, became a combination of UX design, workflow thinking, and system-level decision-making.

Why This Was Challenging
Unlike consumer products, enterprise architecture workflows often involve governance rules, shared ownership, historical dependencies, and organizational trust.
Even small publishing mistakes could affect multiple teams and long-term architectural understanding.

The goal of the project was to create a more understandable and predictable lifecycle experience for enterprise architecture views.

This included:

• Clarifying editable, published, official, and historical states
• Improving overwrite workflows
• Supporting history visibility and traceability
• Reducing confusion around archived and deleted objects
• Creating more consistent behavior across BPMN, ArchiMate, and other view types
• Helping users feel safer when managing shared architecture content

Before moving into detailed workflows, I planned a lightweight discovery phase to better understand how different enterprise users interpreted publishing behavior, historical states, overwrite risks, and official architecture views.

Since the project timeline was relatively limited, the goal was not to conduct a large-scale formal research study. Instead, I focused on workflow interviews that could provide quick validation and help reduce ambiguity before design work started.

I interviewed 5 users from different companies and experience levels who actively worked with architecture views and publishing workflows.

The conversations focused on:

• User responsibilities and goals
• How architecture views fit into their daily workflows
• Publishing expectations
• Overwrite concerns
• Collaboration risks
• Historical visibility
• Trust signals
• Governance understanding
• Lifecycle expectations

In parallel, I also reviewed existing workflows, product behavior, and internal discussions to better understand where ambiguity and friction were already occurring.

A lightweight discovery process focused on understanding workflow risks, validating assumptions, and identifying the workflow areas that needed the most attention.

The process focused on:

• Discovery conversations
• Workflow review
• Identifying recurring concerns
• Prioritizing key workflow challenges
• Defining the design direction

The following interview structure was used during exploratory user conversations.

This section was intentionally kept lightweight and conversational rather than structured as a formal usability test.
The goal was understanding expectations, trust behaviors, workflow concerns, and mental models around publishing and lifecycle management.

Interview Script

Hello, first of all, thank you for taking the time to be here today.

My name’s [moderator], and I’m part of the UX team working on BlueDolphin.

I’ll be guiding today’s session, and a few of my colleagues may also join silently to help take notes and better understand the discussion.

Today’s session is focused on understanding how users think about publishing, version history, and official architecture views inside the platform.

We are not testing you in any way.

Our goal is simply to understand your expectations, workflows, concerns, and decision-making process while interacting with these types of views.

The session will take approximately 45 to 60 minutes.

With your permission, we may record the conversation internally for research analysis purposes only.

Please feel free to speak openly throughout the session. There are no right or wrong answers.

Participant Profiling

Before discussing the feature itself, we first tried to better understand the participant’s role, workflow behavior, collaboration model, and relationship with governance processes.

The goal was not only to collect feedback about the feature, but also to identify recurring patterns across different user types and organizational responsibilities.

This helped us understand:

• Which concerns were role-specific
• Which pain points appeared consistently across multiple user groups
• Which workflows required the highest level of trust, traceability, and publishing clarity

To protect enterprise confidentiality, participant names, company names, and some workflow details were anonymized or generalized. The role types and behavioral patterns are preserved, but sensitive organizational details are intentionally not shown.

Participant Profiling Questions

• What is your current role within your organization?

• How long have you been working with architecture or transformation platforms?

• How frequently do you create or modify architecture views?

• How frequently do other teams consume or depend on your views?

• Which of the following best describes your primary workflow?
  – Creating and editing architecture views
  – Reviewing and validating changes
  – Governance and approval processes
  – Reporting and stakeholder communication
  – Cross-team collaboration
  – Documentation and traceability

• Would you say your daily workflow is more:
  – Individual
  – Team-based
  – Cross-departmental

• How critical are your views for organizational decision-making?

• Have you experienced situations where teams relied on outdated, overwritten, or unclear architecture views?

• How do publishing mistakes typically affect your workflow or your teams?

• How important are trust, traceability, and publishing visibility in your daily work?
  On a scale from 1 to 7 (1 = not important, 7 = very important)

Questions

Publishing Behavior

When you publish a view, what do you usually expect to happen?

Have you ever worried about overwriting something unintentionally?

How would you expect the system to communicate publishing risks?

How important is publishing clarity and overwrite visibility to you?
On a scale from 1 to 7 (1 = not important, 7 = very important)

Official Views

What makes a view feel “official” or trustworthy to you?

How do you normally differentiate between working drafts and finalized architecture views?

Have you experienced situations where teams referenced outdated or incorrect views?

How important is having a clear official state indicator?
On a scale from 1 to 7 (1 = not important, 7 = very important)

Historical States

If a view changes over time, what would you expect from the history system?

Would you expect older versions to remain accessible?
On a scale from 1 to 7 (1 = not important, 7 = very important)

How would you expect deleted or archived objects to behave inside historical views?
On a scale from 1 to 7 (1 = not important, 7 = very important)

How important is historical traceability for your workflow?
On a scale from 1 to 7 (1 = not important, 7 = very important)

Collaboration & Governance

How do multiple teams usually collaborate around architecture views in your organization?

What kinds of publishing mistakes create the biggest risks?

How do governance rules affect your daily workflow?

Closing Script

Thank you again for taking the time to participate today.

Your feedback is extremely valuable and helps us better understand how users interpret publishing behavior, history management, and trust inside architecture workflows.

The insights collected during these conversations will directly influence how we simplify and improve the experience moving forward.

If we have any follow-up questions later in the process, would you be comfortable with us reaching out again?

Thank you again for your time and feedback.

User roles showed different levels of sensitivity toward publishing, history, and governance. Governance Leads and Portfolio Managers placed stronger importance on traceability, official state clarity, and overwrite protection, while Business Analysts needed more contextual support around what was latest, approved, or safe to use. This helped clarify that the design could not be optimized for one user type only.

Many users appeared to mentally separate architecture views into different states:

• Working views
• Published views
• Official views
• Historical references

However, the system did not always communicate those distinctions clearly enough.

This often created uncertainty during collaboration and review workflows.

Conversations consistently highlighted workflows involving:

• Overwrite protection
• Official view visibility
• Publishing confirmation
• Historical understanding
• Archived or deleted object behavior

These areas consistently generated the strongest feedback and discussion in conversations, helping prioritize the final UX direction.

Users also approached the same workflow differently depending on their role.

Governance-focused users such as Enterprise Architects, Architecture Leads, and Portfolio Managers cared more about traceability, overwrite protection, and official state visibility.

Meanwhile, less technical users such as Business Analysts and Process Managers needed clearer communication and more reassurance around what was safe to edit, publish, or trust.

Another interesting observation was that when view states were unclear, users often relied on view names or additional clarification from teammates to avoid mistakes.

One of the biggest insights was that users were not necessarily asking for more functionality.
They mainly wanted workflows that felt more predictable, transparent, and trustworthy.

In many cases, simpler and more understandable workflows created more trust than feature-heavy publishing logic.

Based on that insight, the work was split into two phases.
V1 focused on the workflows that created the biggest trust, visibility, and usability concerns.

V2 was reserved for more advanced scenarios, additional lifecycle behaviors, governance-related edge cases, and lower-priority workflows that could be explored after the core experience became clearer and more predictable.

Users were primarily looking for:

• Predictability
• Transparency
• Historical confidence
• Safer publishing behavior
• Clearer ownership states

The problem was less about missing features and more about workflow clarity and publishing confidence.

Key Insights

• Users feared unintentionally overwriting trusted organizational views
• Historical visibility was strongly connected to governance confidence
• Reducing ambiguity was often more valuable than adding additional functionality
• Simpler workflows often created more trust than feature-heavy solutions
• Different roles had different trust needs around the same workflow

These insights helped shape a more focused V1 direction centered around clarity, predictability, and lifecycle transparency rather than feature expansion.

Based on recurring patterns, several UX hypotheses were formed.

Hypothesis 1
Reducing workflow ambiguity creates more value than introducing additional publishing complexity.
Users were not necessarily asking for more features. Instead, they wanted workflows that felt more predictable, transparent, and trustworthy.

Hypothesis 2
Focusing on the highest-priority workflow concerns first creates a stronger foundation than trying to solve every edge case at once.
The initial direction focused on the workflows that created the biggest trust, visibility, and usability concerns, while lower-priority edge cases could be explored in later iterations.

One of the most important parts of this project was defining clearer lifecycle logic for architecture views.

Instead of treating publishing as a single isolated action, the workflow was approached as a connected system of states.

The logic needed to support:

• Editing
• Publishing
• Officialization
• Historical tracking
• Governance visibility

After defining the lifecycle logic and reviewing the research findings, I focused on the workflow scenarios that created the biggest trust, visibility, and collaboration risks for users.

These scenarios helped shape the first UX direction and the V1 priorities for the project.

Some of these scenarios;

Scenario 1
Publishing a view with an existing name
One of the biggest UX risks occurred when users attempted to publish a view using an already existing name.

The system needed to communicate:

• Whether an overwrite would occur
• What would happen to the existing official view
• Whether history would remain accessible
• How users could recover previous states

The challenge was balancing flexibility with trust and safety.

This workflow consistently surfaced as a high priority concern during discovery conversations.

The final direction focused on reducing uncertainty rather than adding unnecessary workflow complexity.

Scenario 2
Understanding historical architecture states
Users wanted confidence that older architecture decisions would remain understandable over time.
Historical visibility was especially important during:

• Audits
• Governance reviews
• Cross-team collaboration
• Long-term architecture evolution

The UX challenge was helping users understand:

• What changed
• When it changed
• What remained official
• How archived objects should behave historically

This area was repeatedly discussed as a high-priority concern during conversations, especially among users working in governance-heavy environments.

Scenario 3
Archived or deleted objects inside older views

One particularly complex edge case involved deleted or archived objects appearing inside historical views.
Users still expected historical views to preserve context and relationships accurately.

This required balancing:

• System consistency
• Historical integrity
• User understanding
• Technical limitations

The V1 approach focused on improving clarity first before introducing more advanced recovery behaviors.

One important design decision was avoiding unnecessary workflow rigidity.

Adding too many approval layers or governance restrictions risked slowing down experienced users and increasing operational friction.

Because of this, I focused more on contextual visibility, publishing confidence, and lifecycle clarity rather than introducing heavier control mechanisms.

Several UX decisions focused on reducing ambiguity rather than increasing feature count.

Instead of trying to solve every possible workflow variation in the first iteration, the project focused on the areas users consistently considered most important.

This led to prioritizing:

• Clearer publishing communication
• Reducing overwrite uncertainty
• Stronger historical visibility
• Simplified mental models
• Preserving trust through transparency

Meanwhile, lower-priority interaction ideas that generated limited user interest during conversations were intentionally postponed to avoid increasing workflow complexity too early.

In enterprise environments, clarity often creates more value than feature density.

• Clearer state labeling
• Stronger publishing confirmations
• Simplified publishing flow
• Improved visibility of official states
• More understandable historical behavior

The solution had to work within existing platform logic and could not rebuild the entire publishing model in the first iteration.

The main constraint was balancing safety and flexibility. Governance-heavy users wanted stronger control, while advanced users did not want the workflow to become slower or heavier.

To solve this, I focused on improving visibility, confirmation, and contextual communication instead of adding too many new steps.

This allowed the workflow to feel safer without turning publishing into a complex approval process.

The final direction focused on making publishing workflows feel safer, more understandable, and more predictable across different user types.

Rather than designing only for technical users, the workflow aimed to support multiple levels of experience and organizational contexts.

This helped keep the first iteration more focused while still addressing the most important enterprise workflow risks.

The final direction emphasized:

• Trust
• Transparency
• Governance clarity
• Lifecycle understanding
• Collaborative confidence

The project helped establish a more structured approach for handling published and official architecture views inside the platform.

The work contributed to:

• Clearer publishing behavior
• Reduced ambiguity
• Improved trust around historical states
• Stronger alignment between system logic and user expectations
• More understandable lifecycle management

The project also helped create a clearer V1 scope by prioritizing the most critical workflow risks instead of overexpanding the solution too early.

During later strategic client meetings and stakeholder discussions, the direction received positive feedback, particularly around lifecycle visibility, publishing clarity, and governance understanding. These yearly sessions brought together enterprise clients to review product direction, discuss challenges, and evaluate proposed improvements.

While exact client-specific metrics cannot be shared due to confidentiality, the discussions suggested that the proposed direction was addressing several of the concerns identified during discovery, especially around official state visibility, historical understanding, and publishing transparency.

The project helped establish a stronger foundation for future iterations while keeping the first version focused, practical, and aligned with user needs.

One important realization from this project was that lifecycle workflows are not purely technical systems.

They also operate as systems of organizational trust, where visibility, ownership, historical understanding, and publishing confidence directly influence how teams collaborate and make decisions across shared architectural environments.

This project further strengthened my approach toward enterprise UX challenges by reinforcing the importance of clarity, predictability, and transparent system behavior within complex organizational workflows.

It also reinforced the idea that improving enterprise systems is not always about expanding functionality. In many situations, reducing ambiguity and creating a more focused, understandable workflow can generate significantly greater long term value than introducing additional complexity.