Unifying disjointed workflows and design

The problem

GGSA was a number of custom built toolings and a platform to provide schools with software to monitor student performance, access curriculum material and aid in their day to day teaching roles. The platform had rapidly grown into four unofficial separate teams with nobody owning the whole. As the core feature set grew, each team took on its own responsibilities and communication was pushed back to focus on short developer sprints.

Unfortunately, not all pieces of work can be shared, but a notable example of the disjointed work was in the primary navbar across parts of the platform. The same platform had different sidebars depending on which team built the page, and the teams worked on different tech stacks. Most of the platform ran on LearnDash in WordPress, while other parts were being rebuilt in Next.js, but a single stack was never landed on.

Some staff around it were split too. Each team had its own developers, some with a manager, and two BAs were shared across all of them.

The different sidebars that existed across the platform against my single built sidebar. This was a collaborative effort with two BAs and the CEO to confirm a navigational structure and what features currently exist vs. in progress, omitting anything that isn't live

Discovery

During my first month at the company, I ran workshops in two forms. The first was individually with the BAs as they had the most context around the different teams and state of current work. The second was then with the developers and the lead software engineer understanding how they work and why they work as they do. The biggest finding wasn't that teams were disjointed because they we're cooperative - They were disjointed because the amount of work was bottlenecking collaboration, and there was no buffer to engage in conversation or alignment.

Hearing the same gaps from both sides, the business view and the engineering view, made the case for one system rather than four fixes. As a designer, introducing a design sprint before development introduced the needed buffer to work being done so that staff alignment could happen before anything would enter production.

How I helped

To me, the order mattered starting with the obvious, quicker wins followed by the more complex pieces. Guidelines first, then tokens, then components, then missing design pieces then process. Each step gave the next something to stand on.

1. Shared guidelines, then tokens. I wrote updated, shared design guidelines before touching components. I then built a token system from them.

2. Shared components, grown slowly. The component set was fleshed out over time as real pages needed it, rather than built all at once. Often, there were existing components from outdated that could be restyled and reused over creating them from scratch.

3. One library, many files. Every new Figma project pulled from a single shared library, the design system. Files were split by minor feature or by complete feature set, so each team could work on its own piece without drifting from the others.

4. An archive convention. Every file was named [date][name], where the date is the last major piece of work done in it. Each file had a page for current work and an archive page for designs decided to be outdated, so nobody built from old screens.

5. A clear handoff. Work moved through three states in Figma Dev Mode: In progress, Waiting review, Ready for dev.

6. One review path. Because I was the only designer, any new piece of work went through me and the CEO first, whether I designed it or the engineers built it and I reviewed it. I ran workshops with the BAs to walk the CEO through each piece. I also started joining developer standups to share what was being designed but not yet handed off, plus any technical decisions or considerations. [Image: workflow and process diagrams.]

Constraints

The platform couldn't switch stacks overnight. Most of it ran on LearnDash in WordPress, while parts were being rebuilt in Next.js. The teams' differing stacks were a part of the inconsistent navigation.

We proposed moving the platform to Next.js, so shared components could eventually be built once. Next.js was in progress during my time but never adopted across the whole platform.

Results

Starting from around 2 to 3 extra developer alignment calls a week, ranging from 30 to 60 minutes each, were replaced by daily 10 to 20 minute standups once the design system was in place. Any calls outside of that were for developer-only work to still run through me before being presented to the CEO to ensure alignment.

Other outcomes, from how the work ran rather than from measured figures:

• Every new piece of work, whether designed or engineer-built, passed through one review with me and the CEO.

• Developers heard about upcoming designs and technical considerations before handoff, through the standups.

• New Figma work followed one library, one naming convention and one handoff status flow.

  
  

I became able to be cross-functional across different teams or staff before anything got approved by the CEO. Most workshops were facilitated alongside a BA, or a BA and manager.

What I'd do differently

Staff turnover was high, and it slowed onboarding. New BAs and developers were only briefed on the current work, with no context on earlier or related pieces. That left me running onboarding workshops instead of focusing on doing design work. Next time, my focus would shift to writing personal reasoning and documentation down as I go including why the system is shaped the way it is, the decisions behind past work and a 'wiki' like view of everything I've worked on. A living onboarding guide would let new people catch up without needing me in the room.