Driving Fast Product Development Through Design

Hello, I am 623 (@623px), a Design Manager and Lead Designer at CAMPFIRE. Recently, I was invited by the Friends of Figma Tokyo community to speak at their event.

The response to the content was greater than I expected, so I decided to extract some of the points I discussed that day and turn them into an article. I hope this provides some helpful insights for those facing challenges with the development structures surrounding designers.

Over the past two to three years, our company's product development structure and approach have changed significantly. In this article, I will introduce a part of that.

▼ 14th year since CAMPFIRE began

Our company operates one of the largest crowdfunding and community platforms in Japan, with the mission of "creating a world where thoughts and money circulate, even for one person and even for one yen." It is used by a wide variety of people, including individuals, creators, companies, NPOs, schools, and local governments.

CAMPFIRE is now entering its 14th year since its founding. In the beginning, we grew the service primarily by focusing on increasing awareness and operations, but to further expand crowdfunding, we need to evolve through our product.

During the COVID-19 pandemic starting in 2020, the crowdfunding industry saw a significant increase in transaction volume. Through the high demand at that time and the subsequent difficulty in maintaining it, our business challenges and the direction for evolution became clear. To realize this business evolution, we are aiming to establish an appropriate development style.

▼ A development team with design at the forefront

Originally, our development team consisted of PdMs, engineers, and designers all in one team, focusing on improving and developing around business issues.

Around 2020, we changed this to an organization based on roles—PdMs, engineers, and designers—and now we are approaching a "matrix" organization where cross-functional organizations based on roles and teams based on domains exist simultaneously.

Support for each job category is handled by the cross-functional organization, while the achievement of OKRs and KPIs is aimed for by the domain-specific teams. In the domain-specific teams, we have introduced Scrum development in some areas, collaborating in a way that dissolves boundaries rather than staying within each role.

▼ Challenges and solutions in the development organization

One of the challenges in the CAMPFIRE development organization was that it had become inefficient with poor visibility. In our previous approach, we would start thinking about requirements, feasibility, specific UI, and specifications only after reaching the roadmap object.

This was sufficient for small initiatives, but given our business phase, there were many large-scale initiatives, and we frequently encountered unexpected blockers. Sometimes, specifications that no one was aware of would emerge later, suddenly increasing the difficulty of the initiative...

This is inefficient and does not increase productivity. If anything, it only increases team stress. Therefore, we decided to change how we set development milestones, moving away from the common [ Planning → Requirements → UI → Specifications → Implementation ] process to:

1. Drafting a concept

2. Verifying through prototyping

3. UI refinement and implementation

We decided to proceed with these three stages. Roughly speaking, the approach is: "Once ideas are gathered, draft them lightly in advance to check for critical issues before proceeding. Then, take time to discuss UX and implementation concerns through prototyping before creating the specific UI."

Design is always at the forefront of these processes, and we promote this daily under the banner of "Fast and Amazing Product Development through Design."

This allows us to gain foresight into the roadmap before proceeding, and even if it seems like a detour at first, it ultimately enables us to deliver high-quality services to users quickly.

The themes are: 1) Concept mocks to gain foresight into the roadmap, and 2) The introduction of "UX Spikes" that focus on realistic UX.

1. Concept mocks to gain foresight into the roadmap

First, before starting an initiative, we create a visual representation to align our perspectives. We call these concept mocks; they are slightly different from typical wireframes in that we draw the maximum ideal as a concept without worrying about product constraints or feasibility. By the way, this year, we created concept mocks for our entire one-year roadmap.

For initiatives that take two weeks to a month to release, we aim to complete them in about two hours, including research.

While this might seem like a high burden for designers, we visualize everything at once during the planning phase through pair design with the PdM and the person in charge. Since we work while discussing and confirming things, led by the designer, there is no need to sync later. It's fun because we make things while talking it all out.

When we imagine the feasible line based on the concepts drawn this way, we can identify issues in advance, such as legal perspectives or technical investigations.
By scheduling based on these issues and starting initiatives with fewer blockers, we can proceed while reducing stops caused by unexpected events.

2. Introduction of "UX Spikes" focusing on realistic UX

For fast development, there is another approach we call "UX Spikes."
Usually, requirements and specifications are finalized before implementation, but we conduct a Spike (investigation) in advance to avoid hitting walls after starting implementation and to finalize the UX. It is a concept close to what is known as prototyping.

When you hear the word prototyping, you might imagine using design tools, but here we perform prototyping that involves implementation.
The goal is not to build any backend functionality, but to confirm whether this idea is feasible and if there are any issues as a surface-level experience.

The reasons for not adopting prototypes using design tools here are:

• It takes a certain amount of time to reproduce the production environment down to the details.

• Since confirmation is based on the assumption that the user will move as designed, it becomes difficult to grasp unexpected user behavior (such as churn).

We thought that by actually implementing it, we could cover these points and verify a more realistic UX. (Of course, if we judge that design tools are more suitable, we will use them extensively. In fact, for quick checks, I prototype in Figma as naturally as breathing.)

Engineers, designers, and PdMs take the lead, and all stakeholders verify whether this UX is good. With this prototype, the rough requirement definition is completed. If technical investigation is necessary, we proceed in parallel, and then move on to UI refinement and specification formulation.

By preventing points to consider and technical issues from surfacing before entering full-scale implementation, we reduce the need to redo initiatives, enabling smooth progress with good foresight.

You might feel that implementing the front end once is a huge task, but it is overwhelmingly faster than before, when initiatives would go back to square one or specification oversights would emerge, and we are able to proceed with high team motivation.

However, rather than trying to apply this process to everything, the fact that everyone recognizes that 'we can also take this stance and use these methods' may be a necessary element for a strong product organization. It is important to always discuss the best form with team members as you proceed, depending on the situation.

▼ Trying Design-Led Development

Design is too important to be left to designers. This is a famous quote, but it does not mean that designers are not capable enough.
There must be 'design' in every role, and it is about recognizing the area of design you are involved in and moving forward. I interpret the meaning of this quote as not being confined to being a 'something-er,' but rather spilling over into adjacent roles to collaborate.

Development progress led by design is something we have only just begun to challenge. When we first created a year's worth of concepts in two weeks, I was honestly worried about whether it was possible while other tasks were running in parallel. Of course, a completed 'UI design' is difficult, but it was just the right constraint for summarizing the plan, and as a result, we were able to complete it.

We held a roadmap briefing for all CAMPFIRE employees with the plan visualized, and I feel that the outlook for not only development but the entire company has improved.

▼ Why not expand crowdfunding further at CAMPFIRE?

CAMPFIRE has been fully remote since 2020, but we are making various efforts to support a culture of co-creation.
For high-cost phases where we think about design and measures, such as PdM-designer collaboration, designer-to-designer pair design, and pair programming, we sometimes hold online camps for synchronous communication.

The establishment of such organizational design and style is something we continue to improve while everyone, including management, contributes their opinions. Being able to quickly tune according to the path we should take is not something that can be done easily even if you try, and I am proud of CAMPFIRE for facing it naturally.

I believe that crowdfunding does not yet have an established experience or UI, and it is an interesting area with still much room for expansion as a business.

Why not face the business with design at the forefront? I look forward to hearing from you via the link below or on X, etc.

🔻 Hiring PdMs, designers, and engineers

🔻 Recruitment page

🔻 Introduction to the Product Design Department

Thank you for reading this far!https://twitter.com/623px