Our multi-client-model

I am currently designing the new dashboard for our startup fortrabbit. And as “design is how it works” we are rethinking all workflows. In our current version we already have useful collaboration features in place. But we felt that there was room for improvement.

This is our journey.


Definitions

I started researching for UX patterns for (software) systems or user interfaces where users can manage and share multiple objects in a team. Maybe I was looking for the wrong keywords? Multi-tenancy is marketing buzz word for cloud computing nowadays, ok. Multi-client-capability maybe? I started mostly from scratch.

Briefing

fortrabbit is a Platform as a Service. That’s just a fancy way to say that we do web hosting. Our users are (PHP-)developers. They create Apps. In the curent version they can invite others to collaborate on these Apps with different permissions. That’s sounds maybe a bit special, but I guess this can be mapped to other Software as a Service models as well.

Reality check

We sat down and thought about use cases. It turned out that our users like to organize themselves in groups in the real world. Yeah, let’s map this! The first thing was to define a naming for our implementation: team, crew, organisation, party, pool, group or company? We settled with the last one.

Our goals were: Within a Company all Apps are shared automatically. Users can create new Apps on behalf of a Company.

What’s a Company?

Our first approach was to create a new kind of “Company User”. But somehow this felt wrong. I disliked that you have to log out and log in for certain actions to perform. Also: we write retention mails, ask to complete tutorials, to enter SSH keys and such things.

A User is a human being.
A Company is something else.

So we rethought the minimum requirements for our new Company object: Billing details, Apps, Users with different access roles. Each App must be assigned to a Company. Companies can be “owned” by multiple Users. Each User can be part of multiple Companies. There are different Access Rules for Users within Companies: Owners, Admins & Developers.

Again we discussed all different kind of scenarios for our target group: freelancers, startups, digital agencies. And this time it felt really good.

At this point we also checked out how others solved this. As a proof of concept it turned out that GitHub and Heroku have similar models. However needs and target audiences differ — so we better carefully rip. mix. burn.

We implemented two additional features: A way to share only certain Apps of a Company; and the possibility to have multiple Billing Contacts per Company.

Caution, complexity ahead!

It was not an easy decision, we discussed it a lot. Our service is a business solution, we want to map workflows from the real working world. That’s why we need a powerful model that indeed comes with some complexity.

Developers are smart, they will get it!
Developers are lazy, they will neglect it?

We even compared our model with Twitter and Facebook. In Twitter everything is an account. Your personal Twitter account, your company account, your APIs account, your cats account. In Facebook everything is an object of it’s own, a person is a person, a local restaurant is a local restaurant managed by a person. Which one is better?

It depends on the needs. Twitter is a world of it’s own where everything is about 140 characters — and it doesn’t really matter if those are written by a dog. Facebook aims to map the real world.

Hide complexity until needed

The just in time theory of user behavior and his older brother progressive disclosure helped me to cover up most of the complex stuff until the user requests it. A plain vanilla new user can focus on the core features and then later discover how nicely our system integrates with hir needs.

There is no test like production

So far everything is theory. It’s a bet. No client every requested something like this. Our developer crowd is cheering for the latest development technologies — we are implementing these “meta business features” instead. It’s not sexy. It will likely not help us in a sales pitch.

But we have studied our users behavior and support requests regarding accounting and billing. We think that it will be good. Our platforms is getting more mature. This is a real world production feature.

It will take some more months until we can see it in action. The new collaboration features will land with our new dashboard.

I am curious about any feedback.