BRYTER - Services

BRYTER’s Services feature has transformed the platform, creating new opportunities for customers to automate processes and make expert knowledge more accessible. Previously, BRYTER was primarily used to create software tools for non-experts.

Services now provide a simple grouping mechanism for related BRYTER modules, while also offering powerful new functionality such as Case Databases. As the leading designer involved in the initial concept phase, I saw firsthand how this feature evolved into what it is today.

Challenge

At the beginning of the journey, nobody had a concrete idea of what this project was all about. We had a variety of feelings and perspectives, but nothing definite - everything felt hazy.

Nevertheless, we knew we had to maintain the straightforward way to get started with BRYTER, while also increasing the capabilities and setting up the platform for rapid extensibility and more complexity.

Finding a balance between these two factors was one of the most difficult aspects in understanding and discovering what we needed to build to enable our customers to do even more powerful things.

Approach

With the leading Product Manager, Yang Meyer Reifenrath, we quickly began prototyping different potential focus areas to spark discussion and leverage later validation. We had many conversations with key stakeholders, as well as the founders, and created quick visual prototypes to illustrate opportunities and options. Our goal was to gradually understand the essence of the stakeholders’ feelings and perspectives.

Implementation

We outlined and prototyped different potential focus areas, bringing stakeholders together and aligning on a still abstract idea. The early stages involved numerous conversations with key stakeholders, resulting in weekly changes to the current direction.

After numerous prototypes, whiteboarding sessions, interviews, and discussions, we had a clearer idea of how the project would come together. We also realized that the path towards services required a rethinking of our navigation and first page for customers logging into BRYTER.

Before services, most of the customer interaction happened inside the module editor. As the BRYTER product was so laser-focused on the editing experience, not a lot of additional functionality or settings were required. However, the introduction of new functionality outside of the editor led to a rethinking of earlier decisions.

Onboarding

We created a small side project to help existing customers understand the big shift towards Services through an onboarding flow. We explored the possibility of creating a fast and straightforward onboarding flow that would explain the key changes.

However, due to time constraints and prioritization, we had to kill the project. Every so often, you need to let go of your beloved projects.

Modules

As mentioned earlier, the introduction of Services also led to a reorganization of where modules can be found and managed. Modules were now always part of a Service, and were therefore listed on the first page after opening a Service.

The structure of a Service is similar across all its individual parts. The sidebar gives an overview of the parts a customer can access inside a Service, and the content area always presents either an empty state (if no data is present) or a list of items (e.g. modules).

Case Databases

Case Databases are a key addition to the initial Service feature set, extending customer capabilities. They provide a built-in way to make data persistent and easily accessible across different BRYTER modules. Previously, this functionality required additional integration and maintenance work, making use cases more difficult and costly.

User testing showed that adding a persistent layer similar to standard databases made adoption and understanding easier and more approachable.

Collaborators and settings

Services needed a generic control and settings area for easy collaboration and management. A key addition to Services was the Danger Zone, a deletion flow used for critical and destructive actions. This pattern is based on a modal that prompts customers with the potential consequences of the deletion, and asks them to type in the instance name for verification. This provides more context and reduces “modal fatigue,” where customers quickly confirm without reading or understanding the description.

Outcome

After leading the initial exploration and design of the Services project, I handed it over to my colleague Jen Goertzen at around 80% completion so that I could focus on our Design System. Jen led the project until its initial release and continued working on new features.

Thanks to both of our contributions, Services were quickly and widely adopted, improving the way our customers organize their BRYTER modules and opening up entirely new possibilities, such as Case Databases.

What I’ve learned

In the beginning, this project was unclear and open-ended. We communicated and aligned with our founders, stakeholders, and customers through countless questions, prototypes, and ideas.

I created an HTML-based prototype based on our Design System, which proved to be a worthwhile investment of time. Testing sessions were more detailed and enjoyable, and developers were able to use parts of the prototype to speed up their work.

I also learned many ways to improve the overall handoff process and how to illustrate some common stress cases of designing for the web directly in these handoff documents. In the end, this handoff flow resulted in a Design Review checklist that designers now use during their work.