Behind the scenes

Part of working on a large design team within an enormous organization is having a really good process.

The Transamerica Design team I was assigned to is made up of four sub-design teams and each are designated to a product. The design team is made up of User Interface Designers, User Experience Designers, and User Experience Researchers.

The team I was assigned to first was a new team slated for a new work.

This new team was additionally tasked with coming up with a work process that allowed Design to drive the direction of the product based on our research and data gathered directly from our users.

This process positively affects our interactions with Product, Engineering, and Business.

The Objective

Come up with a work process that allows Design to drive the direction of the product

Since we are the team building the user's experience, it only seems natural that we are helping drive the direction of the product. In addition to our main objective leadership felt our team needed better documentation so when we have pushback, or work transfers hands, or handed off to development, that someone else could jump right in and know where they are.

And since we are the team expert digital experience designers, it's important we communicate across the organization as clearly and delightfully as possible.

The Opportunities

The following opportunities were identified as places for improvement:

User journey agreements
Lo-Fi Wireframe agreements
Documenting all variations before reaching hi-fi mode
Component maintenance

Better handoff to engineering

User Journey Agreements

If user journeys are agreed upon before moving onto wireframes, there is less friction in the future, a lot less tech debt, better communication across teams, quicker development time with tighter QA around design and experiences.

This means that before the designer moves onto wireframes the following stakeholders agree on the user journeys for the piece of work:

Design leads/managers
Business analysts
Engineering
Development

By looking at the journey from all of these points of view, we can identify places where, for example: a needed data check might be, an edge case scenario, super complicated scenarios, our happy flow, where UI errors could occur, etc.

Lo-Fi Wireframe agreements

Like User Journeys, early agreements remove a lot of back forth between teams and they take the guessing out of where the project is going.

Documenting variations before reaching hi-fi mode

Along with visual work, journey flows and wireframes, documenting variations at this time has also proved to be valuable. This documentation should be a visual aide if it is complicated, but not all variations are, so at the very least have a master list of variations that is agreed upon by the project's stakeholders.

This is a living list since as you work things change.

Better handoff to engineering

This is usually some of my first questions - how do we communicate with engineering, how do we communicate our requirements? Immediately this was identified as an opportunity for improvement.

Once the lo-fi phase is completed, the hi-fi stage may or may not uncover more things. Either way, it is important to have annotation for the developers, especially if they are an external team who you don't actually meet with.

It's also important that engineering not waste time looking for answers. We know what they need and where it is located, so let's make it easy. One way is to create a directory of our files and pages. Figma allows linking to anything and anywhere, so you can have a really complicated file structure and have your users (engineering) sent exactly to the place and section on the page they need to be.

I came up with this idea after observing and hearing that our users from both engineering and business were "getting lost in our files".

The Outcome

A little protesting, but a favorable outcome!

No one loves change, especially when they are told the change will also transition decision making, but as the weeks went on everyone became more comfortable with what appears to slow things down, there was a more relaxed feeling. I think we alleviated the pressure put on business and the developers to do everything, including the design of the user's interactions.

Once business slowed down and saw the capabilities of a User Experience Designer, they were very please knowing they don't have to make all the decisions; they began asking us questions. They stopped bringing fires to the table and began trusting our approach and direction.

After performing retrospectives amongst the teams, here are some of the big takeaways:

Reduction in accumulation of technical debt for a new feature
Better knowledge transfer for the future
Less cross-team miscommunication
Breadcrumbs of reasons everywhere