Forest Service Business Operations (BusOps)

Before you read...

Due to multiple NDAs associated with this role, I am limited to sharing high level information only. Specific details and visual assets cannot be shown publicly.

Stepping Into a Larger Role

Following the successful launch of the Research and Development website, Dynamo asked me to step into the role of lead UX designer for the Business Operations contract. I felt confident in my design process and excited to take on a more complex challenge, especially one that built directly on the work I had already done within the Forest Service ecosystem. After meeting the new team, which included a Scrum Master, Business Analyst, three developers, and three primary stakeholders, it was clear this project would be larger in scope and influence.

Understanding the Problem Space

Business Operations already had an online presence, but it was fragmented and outdated. Some resources lived on a basic HTML site, while others were scattered across multiple Microsoft SharePoint pages. From the beginning, stakeholders were clear about their goal. They wanted to improve usability and modernize the interface, while consolidating content into a single, reliable hub for employees.

Initially, the site supported only a small set of features such as announcements, events, and basic informational pages. That scope changed quickly. We were soon tasked with bringing eleven separate offices under the Business Operations umbrella into a unified design framework. Each office had its own stakeholders, priorities, and opinions, which significantly increased the complexity of the project.

Leveraging Familiar Frameworks

One major advantage going into this project was my familiarity with the Forest Service design standards. Business Operations followed the same design system and accessibility requirements as Research and Development, including USWDS and Section 508. Because of this, I was able to move quickly into requirements gathering without needing to relearn foundational constraints. This allowed me to focus my energy on understanding user needs rather than reestablishing design rules.

Defining Users and Information Structure

Early stakeholder sessions helped clarify who this site was truly for. The goal was to make Business Operations the starting point for employees across all offices. Stakeholders wanted a site that could support daily tasks and empower even brand new employees to complete niche workflows without needing to ask for help.

With that goal in mind, I designed an information architecture that treated Business Operations as the main entry point, then guided users toward office specific content based on relevance. This required mapping every page across Business Operations and all sub offices, resulting in a very large and detailed structure. I organized this work in Adobe XD and presented it across three levels of stakeholders to ensure alignment before moving forward. Once approved, this structure became the backbone of the entire experience.

Establishing Consistent Visual Foundation

Branding decisions came together quickly since most of the visual identity already existed. I referenced the Research and Development site to demonstrate how color, typography, layout, iconography, and components could be reused and extended. This continuity helped stakeholders feel confident and dramatically reduced decision making time. With branding aligned, I was able to move into exploratory design very quickly.

Exploring Layouts and Patterns

Using Adobe XD, I created several early layout concepts for the landing experience and presented them to stakeholders in a guided design review. Rather than focusing on aesthetics alone, I explained how each layout supported discoverability and task completion. We landed on a flexible approach that could scale to support the individual offices as they were brought into the system. With stakeholder alignment in place, I moved forward with building a complete, interactive prototype.

Designing for Real Use Cases

The high fidelity designs were built around realistic scenarios, such as employees searching for office specific events or filtering content by department. This required designing complex interactions like multi facet filtering and dynamic navigation paths. I used real content wherever possible and supplemented with placeholder text only when necessary.

Once the prototype was in a solid state, I reviewed it internally with developers, the Business Analyst, and the Scrum Master. This step helped identify potential development risks early, especially cases where a design might create unnecessary complexity given timeline constraints. After refining the work internally, I presented the prototype to stakeholders.

Securing Executive Buy In

Unlike the previous project, this phase required approval beyond the immediate stakeholders. The design needed buy in from the Forest Service Chief as well as leadership from every office under Business Operations. This meant presenting to a group of more than ninety participants.

To make this effective, I intentionally narrowed the scope of the presentation. Instead of walking through detailed workflows, I focused on the most impactful changes such as navigation structure and overall look and feel. I supported design decisions with references to USWDS and lessons learned from the Research and Development project. This strategy kept the conversation focused and avoided unproductive debate. By the end of the session, the prototype was approved, which was a major milestone for the project.

From Design to Launch and Beyond

Developers used Adobe XD dev mode to build each page, sending completed work back to me for review and approval. In January 2023, we launched the Business Operations website with one office included. Over the next two years, we continued onboarding additional offices, each with unique requirements. Some needed simple landing pages, while others required integrating multiple third party tools into a single cohesive experience. These challenges pushed both design and development boundaries while still adhering to accessibility standards.

Tooling Evolution and Project Close

In mid 2024, I transitioned all design work from Adobe XD to Figma. This change was driven by stakeholder ownership and tooling preferences. While the migration required additional effort and learning, it ultimately improved collaboration and became my preferred design tool moving forward.

The project concluded in April 2025 due to federal budget realignments and shifting priorities. While it was difficult to see years of work paused, the experience reinforced the realities of long term contracting in the federal space.

Key Learnings

Designing for scale requires thinking beyond the initial launch and anticipating how systems will adapt as new teams and requirements are introduced.
A strong information architecture is critical when a product serves multiple departments with overlapping but distinct needs.
Executive level buy in requires a different communication strategy than stakeholder reviews, with a focus on clarity and impact rather than detail.
Early collaboration with developers helps balance design ambition with technical feasibility and delivery timelines.
Reusing established design systems accelerates progress and builds trust when decisions are grounded in recognized standards.
Adapting to new tools and ownership models is essential in long running projects, especially within large organizations.