First attempt to update everyone about Branch 2 initiatives. Original GDocs here.

If you dislike reading long form text, here are some pointers about the updates:

We are focusing on audience building in research system initiative
We are looking into alternative pool of audience for user research in addition to customer’s email list
Designers been granted access to auth0 and MCP so they don’t have to request on their own. We think this should be part of onboarding checklist
We build relationship with data team and marketing tech team to enhance cross collaboration
We are discussing about responsibilities of Research Ops team
Interface component single source of truth will be available for everyone here (password: newton)
Momentum UI will be explored by product team (flight) in Q4 and Q1 in collaboration with Branch 2.

Research System

After months of understanding the existing system to execute design research and bring that to everyone’s understanding, we decided to focus on tackling the problem in chunk. Generally there are 6 areas of problem:

Strategy: We decided to focus on Audience Building problem with the goal to optimize the way we generate lists of research participants candidate. Here lies the most complicated process from end-to-end design research experience. Also it’s the most urgent relative to the other problem area.

To tackle this area we split into two sub-focus: innovate the way we tap the audiences and supporting current system with clearer process and PIC.

Tapping alternative pool of audience

To be really honest, current complicated process just to get the list of customer’s email is far from ideal. Added with the fact that customer’s contacted via email only resulting in ~10% response rate. Very small number compared to the 5+ working day spent on collecting the customer’s contact.

Thus, on innovation sub-focus we will try to open up opportunity. To have access to wider research participants pool, organically groomed in a community-like group, ready to be tapped whenever we need it. We discussed with Traveloka Travel and Lifestyle Fair team and try to bootstrap the community by riding this moment. Thanks to @dirk-harunsjah for stepping up and bridging the discussion with TTLF team!

Talking about tapping alternative pool of audiences, we noticed that snowballing (contacting friends of friends) is a common practice among researchers in design team. We seek out to understand the motivation, limitation, and other context around this practice with the hope we can scale this effort as an alternative approach. @farah and the other research system team is on it

On supporting current process sub-focus, we already registered all designers in this list to get auth0 and MCP access to be able to create assets for building audiences and send invites, so you don’t have to! Thanks to @ernestine for the thorough follow up

:clap: We think this request somehow need to be included in the on-boarding checklist (at least for UIDev, DR, and IxD). Please join #dsgn-research-support in slack if you need help around design research process.

Parallel to efforts above, we also build relationship with data team and marketing tech team to discuss these things:

Streamlined request flow from design to data analytics team
PIC from research team (research ops on design team) as a single gateway to data analytics team and marketing team.

Emphasize on building relationship, not imposing our needs without trying to understand the needs of other.

Research Operation

Above we mentioned a little about possibilities to have a Research Ops team. Understanding the needs of having such team is becoming more and more important, we brainstorm and compile the possible responsibilities in this document. Currently we’re gathering feedbacks from people about this. Feel free to give your feedback as well!

Design System

Unclear process, unclear PIC, and unclear quality expectations seem to be the common case from designers in product team about what kind of solutions that they can explore? Is this still inline with whatever guideline we have? (spoiler alert, we don’t have yet).

We surveyed designers and developers alike to really understand their needs and concerns. Afterall how can we offer better process if we don’t understand that? We recapped all of those in this document.

We shared with the team on how a design feedback session might be conducted as simple and as clear as possible. It can be run in 45 minutes only!

Alliance with developers

During this past months we’ve strengthen our collaboration with development team. Before, the development process feel waterfall-ish. Designers finish the design, spend some time to perfecting the image and representation of final product, then deliver it to developers. We wish to change that and having close-knit collaboration instead. They learn our language of design and we learn their language of code.

To achieve shared understanding through shared language, we build single source of truth that will be available for everyone here (password: newton). Content is being planned strategically along with implementation plan.

Momentum Design System

We dub this design system “Momentum”. A new way of working and collaborate. All available building blocks for product interface will be made visible to everyone. See example of library here (password: Momentum2018).

All the components are reviewed from design and engineering side for quality, accessibility, composability, etc. So product team can easily use that without much to worry. We tackle the easy mundane essentials problem, so product team can focus on harder, complicated, critical problems. From design team this part of initiatives are represented by @jeje

This new alliance open up to new possibilities. We build tools that can help both designers and developers work more efficiently and more in-sync, like icon kit (lead by @bakti p.s. Join #dstool-iconkit to ask questions about this tool), sketch plugins, and more to come.

Other than fixing and improving how we work, we also share this with product team. Momentum UI will be explored by product team (flight) in Q4 and Q1 in collaboration with Branch 2. We see the value on this as means to increase trust among product team.

What we learned

Politics is important in navigating organization. Who make the call and whose opinion has “weights” is the useful information even though often times it’s implicit. To collaborate well involves strategy and negotiation.
Contribution is not only executional level. When you share the goal and vision openly, people will contribute ideas, game plan, even tactics. This can come from unexpected parties as long as facilitated fairly. The executional part doesn’t have to be “your way” because it may not be the best way.
The process might not be formally there. But there is underlying “norm” where we operate daily. Recognizing this is the key to offer a more established and proper one. Disruption to the workflow will results on resistance to integrate process.

What’s on our mind this week

How to budget Design Research activities
Adding more people to help thinking about Branch 2 opportunities and initiatives
How to communicate and distribute guidelines. Not only that but also ensure everybody equipped with same knowledge and tools to be able to implement it.
How to craft career path for totally new roles which is more operational and execution. How to build the team for this.
How to scale brand system to align user experience end-to-end

Great! You read till the end, we really appreciate it! If you find this useful and relevant to you, please react with the emoji

:heart: (also give feedback in the original gdocs, what are we missing that you’d like to know?) so that we can communicate things better.

CDC Branch 2 Update | 26 Oct 2018 (Fri)