Inside the redesigned Shisho Cloud Onboarding flow, where Engineers develop secure applications faster

Hello, I'm Hal. I joined GMO Flatt Security in October 2024 as the first product designer and am currently working on the design of “Shisho Cloud,” a vulnerability assessment tool for developers.

In this article, I’d like to share the complete renewal of Shisho Cloud’s initial setup screen, a project I took on during my first three months at the company. I will show how, as a designer new to the specialized field of security, I contributed to this business challenge.

Project Background

Vulnerability assessment tools, including Shisho Cloud (which we develop), only start to provide real value once the developer’s application can actually be scanned for vulnerabilities.

In order to perform assessments, you need to configure your application's authentification flow under development with Shisho Cloud. However, as of October (when I joined), there were issues with the initial setup screen required to connect user applications to Shisho Cloud.

Initial Setup Screen Before the Renewal

• Users could not complete the setup on their own, making it hard for our engineers to focus on development because they had to support user setup.
• It took too long to experience the value of the product after starting a trial.
• A poor first setup experience negatively impacted the user’s impression during the trial and increased the likelihood of losing prospects.

From the perspective of both cost and revenue, it was clear that the initial setup process posed a significant challenge. To solve these issues, starting two weeks after I joined and over the course of three months, I led a full renewal of Shisho Cloud’s initial setup screen.

In the sections below, I’ll introduce the specific processes we used.

1. Understanding the Domain

When I joined the team, the development members frequently used specialized terms related to security and the authentication mechanisms needed for the setup flow.

When I first heard about the project and saw the relevant product features, I honestly had no idea what the screens were for and was not at all confident I could manage.

So, the first thing I did was immerse myself in domain understanding. I actively used ChatGPT to get a grasp on authentication mechanisms for applications and to understand Shisho Cloud’s functionalities. For example, I asked questions like “Explain ◯◯ in a way that even an elementary school student could understand” or “What data is needed in this authentication flow?” to get a broad overview of the terms and processes I was unfamiliar with.

Of course, I didn’t just take ChatGPT’s answers at face value. I would do a rough read, then confirm the content with our in-house engineers to deepen my understanding step by step.

If you’re interested in how I approach learning a new domain, please check out my other blog post:

How to learn about a new domain for complex B2B product design

Visualizing the Workflow in FigJam to Establish a Shared Understanding

Next, I mapped out, in FigJam, the workflow involved in initial setup of a target application with Shisho Cloud—how users enter authentication information and how data moves between the product and the application.

I showed these diagrams to our engineer who is also a domain expert. By checking the details carefully with them, I gradually refined my understanding.

Sometimes, I even asked the engineer to draw their ideal flow or the current flow in FigJam. As I asked clarifying questions, we aligned our shared understanding and refined the process together.

2. Usability Testing with In-House Developers

While deepening my domain understanding, I also investigated why the existing onboarding flow was difficult to understand.

I conducted a usability test of the pre-renewal features with three in-house developers whose attributes closely matched our target users, and identified where they got stuck.

We did detailed interviews on the specific points of confusion and dug deeper into why they took certain actions. Unfortunately, even our in-house developers could not configure everything without error.

Redefining the As-Is and To-Be Flows

As-Is and To-Be Flows on FigJam

We added the confusing points uncovered in our in-house usability test to the FigJam workflow, making the As-Is and To-Be flows visible.

While looking at these flows, the engineers provided insights on what was technically feasible and gave their opinions from an engineer-user perspective. As the designer, I visualized the ideas, and we prioritized them based on factors like implementation cost and the impact on the user.

3. Creating an Initial Prototype

Understanding the Data Model

By this point, I had a decent grasp on the domain, so the engineers shared a YAML-based specification for the relevant feature with me.

I focused on understanding “what information is required to complete the authentication setup and how those pieces of information are related to each other.”

# (Sample) Coffee Recipe Registration Spec / Generated by ChatGPT

recipes:
   - id: An integer that uniquely identifies the recipe
     name: Name of the coffee (string)
     ingredients: A list of ingredients
       - name: Ingredient name (string)
         quantity: Amount of ingredient (string, e.g. "20g", "30ml")
     instructions: Steps for preparation (list of strings)
     impressions: Notes or reviews (string)
     store: Name of the store where you purchased ingredients (string)
     date_registered: Date the recipe was registered (string, format: YYYY-MM-DD)

Honestly, when I first received the YAML specs, I thought, “I have no idea what’s going on here.” But now, I actually find it more concise and easier to ensure consistent understanding than if the specs had been shared in natural language.

Prototypes Built Together with Engineers

After getting a decent understanding of the data model, I created a low-fidelity (Lo-Fi) prototype in FigJam. When I prepared an initial concept, it became easier for the engineers to tweak it or build upon it, allowing for a fast feedback loop between designer and engineers.

Because Shisho Cloud is a developer-focused product, having the developers themselves contribute to the prototype design was important for improving the feel and usability of the product.

In this phase, my role was to provide a starting framework so that the engineers could more easily engage with the design. This approach proved to be very effective.

After several iterations, we had a clear direction for improvement, so I created a high-fidelity (Hi-Fi) prototype in Figma.

Since I was the first designer, there were no existing design files. I decided to split the design work into a library file and a project file.

I created commonly-used components in the library file, then referenced and used those components in the project file to build the Hi-Fi prototype.

Later, we needed a large-scale layout and screen flow update to the project. However, because we had built the UI components as a library, we could manage updates centrally, drastically reducing rework.

4. Usability Testing with External Users

This renewal project involved a major change in the user flow and was also strategically important for our business. Instead of releasing it all at once, we decided to conduct usability testing with external users first.

Because the team had never done usability testing before I joined, I first explained to the team why we needed to do it.

The attached image shows the actual proposal document I created: it summarized when, why, and how user testing is effective. I shared this with our CTO, developers, and the sales team.

After that, the company was more eager to run a usability test, and our sales team introduced us to three external users.

We conducted usability testing using the Figma prototype. (A big thank you to all the participants and our sales members who set it up!)

Feedback on the Figma prototype was generally positive, but we discovered smaller issues such as insufficient explanation of certain concepts or unclear wording on the screen. We immediately fixed what could be addressed quickly before the initial release.

That said, because our target applications used multiple authentication methods, I anticipated that we wouldn’t be able to fully capture all real-world issues just from the Figma mockups. I felt we needed to test in a real environment after release.

5. Usability Testing on the Released Product

Knowing we needed to test as soon as possible in the live environment, we split the new features into the smallest releasable units and launched them incrementally.

During this process, we aggressively removed any functionality that wasn’t strictly necessary for the first version.

We then proceeded to release the minimal features and ran usability tests using the new product in the actual environment.

Whenever possible, I had the engineers join these testing sessions to experience first-hand where users struggled during the onboarding process.

As expected, we discovered new issues that we could not fully anticipate with just a Figma-based test.

During the testing period, we would do daily reviews with the engineers to identify issues, come up with improvements, and then release revised features again.

6. Holding Support Sessions and Implementing Improvements the Same Day

Even after releasing the renewed version, only a few users could complete the setup entirely on their own. To address this, we proactively hosted online support sessions.

I, as a designer, also joined these sessions to observe in real time where users were getting stuck.

Whenever a question or stumbling block came up during a support session, I spent the remainder of the day reviewing improvements. If a quick fix on the frontend was enough, I coded and deployed it myself.

We kept a tight cycle of:

1. Support session
2. Same-day review of improvement points
3. Design in Figma
4. Implement the front-end fix ourselves.

By doing so, we quickly incorporated what we learned from the support sessions.

After about three weeks of running these support sessions, the volume of questions dropped, and the percentage of users who could complete the setup on their own began to rise.

7. Creating and Publishing the Help Page

Once our UI improvements had settled, we created a help page explaining the new initial setup flow in detail. As mentioned earlier, when we kicked off the project I didn’t even understand the basics of authentication. But after going through this project, my domain knowledge improved enough that I could write the entire flow on my own (of course, with a final review from the engineers).

We included in the help page any detailed explanations that we couldn’t fit into the product itself, and then added multiple links from the product UI to the help page. I also implemented these minor UI updates myself.

Between the iterative support sessions and the new help page, more users can now complete the initial setup on their own.

We certainly still have many improvements to make, but we have significantly reduced the engineering support load. Additionally, we’ve been hearing more positive feedback about how much clearer the new onboarding is.

I’m happy to say this was a project where I, as a designer, was able to make a meaningful contribution.

What I Want to Achieve at Flatt

Beyond the feature we improved this time, working in the domain of cybersecurity means dealing with complex, specialized information and making it more accessible. I believe it’s both challenging and exciting as a designer to contribute to creating more secure products.

Before joining GMO Flatt Security, I saw security as complicated and difficult, something I tended to avoid. To be honest, I used to see security incidents in the news as “someone else’s problem,” but now I realize how even a tiny mistake can lead to a critical breach.

That’s precisely why I believe we need the power of design to help developers—who are moving at high speed to make the world better—focus on delivering true value.

My Design Mission

Dramatically reduce both the financial and time costs required for detecting vulnerabilities, enabling developers to address truly critical issues hidden among countless alerts, and thereby allowing developers to focus on delivering value to society.

This is what I want to achieve through Shisho Cloud! Thank you for reading!