Process

I hold multiple listening sessions to understand all different styles of processes internally, from design/eng/product. I also studied what's out there externally(Lean UX, Design Thinking...). Then reviewed it across, up, and down.

Results

In the end, we decided to modify the "double diamond" design thinking model to our own needs.

Artifacts populated along the flow below:

• Hypothesize
• ~Business Goals
• ~Customer Goals
• ~Tech Constraints
• Research
• ~Survey Question List
• ~User Interview Kits
• ~Impact Mapping
• ~User Archetypes
• ~Competitors Analysis (SWOT)
• Define
• ~Problem Statement
• ~Journey Map
• Ideate
• ~IA template
• ~Flow template
• ~Wire template
• Validate
• ~Rapid User Testing Kits (UserZoom)

Learnings

Due to the time limit, I only involved Eng and Product. More partners like analytics, QA, content strategy, marketing should be invited into the next iterations.

Jira, as a more engineer and product friendly tool, how should a design team use it? There were 2 needs based on the hybrid team structure we had then:

• Design task management in Design Org: Honey Design needed one place to see what everyone is working and which stage they are at.
• Design task management in Feature Team: Designers needed their own places to communicate with their feature team partners.

At first, I set up the Jira board for our Design Org.

• Each kanban board on the sidebar stands for a specific design vertical within the org. For example, we had verticals from Design System to Product Copy (Content Strategy team)
• The vertical column is mapping each stage we set up in the Product Development Process, namely the Strategy > Skeleton > Detail.
• The horizontal swimlanes are defined based on each team's needs. Some teams are using Designers, while some are using Feature Teams.

Secondly, I wrote Jira Query Language to mirror the board in Design Org to the distribute Feature Team.

• The design board exits together with our partners, like the Eng board, QA board, Analytics board...
• Due to the JQL linkage, whatever our designers move in the Feature Team will be mirrored to the Design Org.

The rest of the Jira artifacts, such as 'Issue template', 'Different issue types based on our different verticals', and 'Jira workflow'.

I also realized how important sometimes the title can be, especially for managers & leaders. As long as I brought it up during my sync with the product & eng head with the proper rationales, they instantly agreed with my point and offered to help. We were on a promising start with the strong support from product & eng leadership.

But how should we participate in the quarterly planning? The articles out there were mainly for engineers and product managers. Only a few about 'UX road-mapping, but mostly on annually basis. I was left with only 2 choices: 1). Study how eng & pm plan. 2). Study our current and past pains.

Top findings and my thinkings below:

• Product managers used to kickoff planning 1 month ahead. With design joining, the timeline needs to be pushed more forward, so that we have enough time to fund the engineering work.
• Design initiatives varied with some needing research while others don't. For those needing research, we need to bake research time into planning, which will push the timeline even more forward.
• Some teams tended to plan design way much ahead, like half a year. As a hyper-growth startup, we were seeing changes every single day. What we planned so much ahead might be easily out-valued by new trends/tech. We really needed the balance between no planning and over-planning.

The proposed timeline with the Design joining:

A few things to call out:

• Design started to have 2 months ahead of eng works for each quarter.
• Design started non-stop researching.
• Design started to have 2 months to hire if product asks surge.
• ~Later I realized hiring should be planned on an annual basis.
• Eng started to have at least 1 month of funded work before each quarter.
• Product started to kickstart planning in sync with design.

Just like how the Product planned in one place and then demoed to the entire company. We started to use Miro as our single source of truth to plan and then to communicate to everyone within Honey Design.

After lots of listening sessions with my designers, design managers, and feature team peers, we came up with the weekly rituals plan as below:

Couple of things to call out:

• Each design vertical started to have its own ritual to maintain lean and fast. We had 5 major verticals at that time: Shopping Tools, Native Shopping, Product Growth, Checkout, and Merchant Exp. Each had at most 5 to 6 designers.
• We kept org-wide rituals, but fewer. So designers could still gain visibility from other verticals and design leadership, and of course, have fun together in a larger group.
• We made feature team rituals optional. Through chatting, I found the value of everyday standup and other feature team meetings like planning with points system and demo was really not adding too much value. After the change, they were still on the calendar, but designers had more priority on Design Org.
• I also moved all my 1:1 into the beginning of the week, where my energy was at peak level. It also cut down my context switching drastically.

Last but not least, everything was documented within Notion, from 1:1 to Monthly All Hands. Below is an example of how we run Weekly Warm-up in Notion.