BRYTER Services

A big evolution of the BRYTER platform that enables customers to automate complex workflows and create truly self-service solutions.
A visually refreshed

Overview

The introduction of Services created entirely new opportunities for BRYTER customers and added a new level to the BRYTER platform. Before the Services release, BRYTER was a great application for creating tools to automate processes and get knowledge from experts into a reusable and approachable format that could be easily used by non-experts.

The addition of Services not only added a simpler grouping mechanism for related BRYTER modules (the name of software tools created with BRYTER). It also provided additional functionality (e.g. Case Databases) that enable customers to do wholly new and powerful things.

I was part of the initial process of understanding and creating the first version of what Services are today. Nowadays, Services are further developed and even more powerful. In this case study, I will only focus on the time I lead the design during the initial concept phase of a little over six months.

Challenge

At the beginning of the journey, nobody had a concrete idea what this project is all about. We had different kinds of feelings and perspectives, but nothing concrete — everything felt foggy.

While things were quite unsure in the beginning, we knew we needed to preserve the easy way to get started with BRYTER, while also extending the capabilities and setting the platform up for rapid extensibility and more complexity. Balancing these two factors was one of the most challenging parts in understanding and uncovering what we needed to build to enable our customers to do even more powerful things.

Approach

Together with the leading product manager for this project, Yang Meyer Reifenrath, we went ahead outlining and prototyping different potential focus areas of the foggy ideas different stakeholders and leadership had in mind.

We deliberately went straight into this mode to spark discussion and conversation we could leverage later on and validate with time and care. Our approach focused on many conversations with key stakeholders and quick visual prototypes to illustrate different opportunities and options we could take.

We hoped to slowly but steadily get closer to the gist of what these different stakeholder feelings and perspectives were pointing to, without a clear mental model or idea.

Implementation

In the first weeks, we went ahead, outlining and prototyping different potential focus areas. Starting like this really helped bring more and more stakeholders together in seeing common patterns and aligning on a still abstract idea.

We had numerous conversation with key stakeholders across BRYTER. It wasn't uncommon at these early stages to change some key element of the current direction on a weekly basis. It felt like a rollercoaster ride, but one that seemed to make actual progress.

Numerous prototypes, whiteboarding sessions, interviews, and stakeholder discussions later we had a more clear idea on how something might come together at the end.

We quickly noticed that the path towards Services would also include a rethinking of our navigation and first page customers would see after logging into BRYTER.

Foundations

Before Services, most of the interaction and surface area towards customers was based 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 needed. With the introduction of new functionality outside of the editing experience, we had some time to rethink some earlier decisions.

A screenshot from the original module overview page inside BRYTER. A black header with navigation and a list of vertically stacked card-like modules, customers can click to enter.
The module overview page was the first page after login. It set the foundational structure before the “Services” project.
A visually refreshed
Now, the “Services” overview page is the first page after login and the replacement for the modules overview (see example above).

The restructuring of the initial page and navigation of BRYTER gave us an opportunity to also think about topics that were on our design backlog for a long time, but never were important enough to tackle — Empty States.

With a shift in visual appearance, a deeper focus on card-based design and generally more instances where empty content might be the first state a customer sees, we wanted to improve this experience.

Together with Nina König, the same illustrator who supported us during the Bliss Icons project, we started to think about a visual approach that could combine the Bliss Icon work with this new need.

The
Empty state for the overview page of all “Services”.
Screenshot from a empty state example for the module overview inside a “Service”.
Empty state example for the module overview inside a “Service”.

With the new illustration style, a simple and centered layout of the empty state content, we had a foundational blueprint we could reuse across all empty state instances. One adjustment we added to our empty state was the very center-focused call-to-action button. We always wanted to have the call-to-action button paired with the empty state to shift the focus there — no additional call-to-action buttons on the page, only one to focus all attention.

Onboarding

One tiny side project that was coupled with the empty states project was onboarding. We wanted to make the big shift towards Services easier to grasp for existing customers. With this in mind, we played with the idea to create a fast and straightforward onboarding flow, explaining the key changes.

We killed the onboarding flow later in the project due to time constraints and prioritization. While it never saw the light in the end, it was a small part of the project I really enjoyed thinking about.

Every so often, you need to kill your darlings.

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 therefore listed on the first page after opening a Service.

The skeleton of a Service is similar across all the 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).

Screenshot from a module overview page inside a “Service”.
Module overview inside a “Service”.

Case Databases

Case Database are a key addition to the initial Service feature set that also immensely extended the capabilities of what customers can accomplish. A Case Database gives customers a built-in way to make data persistent and also access it in a straightforward way across different BRYTER modules.

Before the introduction of Services and Case Databases, this kind of functionality only was possible with additional integration and maintenance work, which made use cases far more difficult and costly.

We saw in user testing sessions that adding a persistent layer that is very close to standard databases (some shortcomings like no migration support were part of the first version) made the adoption and understanding for customers easier. The known shortcomings sometimes led to confusion, but this was what we expected, and we were okay with this being the case of the first release.

Screenshot from a case database configuration page, where customers can add new fields to a database.
Customers can configure and add database fields to initially configure their database.
Screenshot from a list of database fields, showing the schema of a case database.
List of database fields after the initial database configuration.
Screenshot from a data viewer of a database, showing rows of data customer entered via a BRYTER module with case database access.
The data viewer of a database where customers can see the saved data entries.

Collaborators and settings

Besides the two key focus points, Modules and Case Databases, Services also needed some generic control and settings area to enable easy collaboration and management. We wanted to build a solid foundation that could be easily extended later.

One key new functionality we added to Services was the deletion flow, which we called Danger Zone. Danger Zone became a pattern for very critical and destructive deletion flows, which needed some sort of verification, on the BRYTER platform.

We based the verification flow on a modal, which prompts customers with the potential consequences of the deletion and asks them to type in the name of the instance they'd like to delete. This not only gives customers more context of the severity of their deletion, but also covers “Modal fatigue” where customers quickly click on the confirmation action without reading or understanding the description of the deletion modal.

Screenshot from the settings area inside a
Foundation of the settings area that needs to be extended in the future.
Screenshot from the “Service” deletion modal.
Open “Service” deletion modal that was triggered inside the “Danger Zone”.

Outcome

After leading the design of this project from the beginning and doing a lot of early exploration and design, I handed the project over to my amazing colleague Jen Goertzen at the ~ 80% mark to focus again on our Design System. From this point, Jen led this project until the initial release and continued working on additional new features.

With both of our contributions to the initial release of Services, we saw a great and fast adoption to a whole new area of BRYTER. Services not only improved the way of organizing the modules our customers build with BRYTER, they also opened entirely new areas to explore and use — like Case Databases.

What I’ve learned

In hindsight, it's probably fair to say that in the beginning this was one of the most unclear and open projects I've worked on so far. There was a rough idea about something and with countless questions asked, creating early prototypes and ideas we were able to communicate and align more and more with our founders, stakeholders, and customers.

At some point during the process, I decided to create a whole HTML-based prototype which was ~ 90% based on our Design Systems foundations to make feedback and testing sessions even more straightforward and also reuse some created bits during development later one.

While I was not sure in the beginning if this time invest would be worth it, it played out very nicely. Testing sessions were even more detailed and fun. Furthermore, developers were able to leverage some of the prototype parts which speeded up their work immensely.

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

Position Lead Product Designer
Company BRYTER
Year 2020
Responsibilities
  • UX & UI
  • Concept
  • User Testing
  • Product Design
  • Front-end Engineering