remote-friendly, remote-first, remotes.in

From the beginning, remote work has been a part of Whitesmith’s core culture and we try to ingrain this “remote spirit” not only to the newcomers but also to the current team. We actually encourage our “local” workers to be remote as well so they can feel a little more empathy for their fellow remote coworkers and also enjoy the quirks and perks of remote working. As we grow, more in-office workers started to work partly remote due to our increasingly crowded office. Personally, I find a crowded office inspiring, but not all people are the same.

However, different workers have different needs and being comfortable and happy while doing our job is a “commandment” in Whitesmith’s culture, no matter where you are. Just like design evolved from a fixed-boxed-one-size-fits-all to a fluid approach in order to adapt to never-ending panoply of screen sizes, work needs to be flexible as well.

Remotes as first class citizens

Being remote-first involves a lot of things. One of the first steps that we’ve taken was to centralize team’s communication and collaboration into one async place since 9-5 workday is not really our thing. Working async means: to not “pull you from doing actual work in order to talk about doing work”^[1]; no interruptions when you’re focused on something else; independence of time and location. Let’s face it, most of the times, work can wait and life or death work questions scarcely happen when you have a clear workflow. When Whitesmith started (I wasn’t here yet), Hipchat was where the magic happened, but when I entered, the Slack train™ was already passing by, we gave it a ride and never looked back! Slack is awesome, but “if you want to build a great remote environment, you need to front the dough to have some in-person face time from time to time”^[2]. Looking at a static one-time-for-life-uploaded avatar or gravatar doesn’t build or reinforce a relationship between team members. Of course, we talk on Skype, Hangouts, or even Screenhero, but we use these tools for sporadic 5 minutes talks or remote debugging/pair programming.

We wanted something else.

We wanted something that gave all of our workers a presence in the office, even if they are 3000km away. Since teleportation isn’t here yet, and holograms are f*cking expensive, we’ve chosen the usual suspect: the internet.

The Crusade for the right tool

We’re not fans of reinventing the wheel, so we looked for a tool that could allow us to achieve it. We found Sqwiggle in the interwebs and gave it a try. Swiggle is an always-on online workplace for your remote team to work together throughout the day and feel more connected. Ok, but we use Slack for that. What really captured our attention was this particular feature: the auto snapshot. This forced a real face to appear in short time frequency. No more shiny photoshopped avatars, just messy haired faces, sleepy faces, bored faces, excited faces, funny faces, real faces. Our team reacted really well and even some snap competition started among us.

But (and you know there’s always a but), after two weeks of use, people started abandoning Sqwiggle. We tried to understand why, so we asked our coworkers and some of the motifs were:

• “Some conversations are happening now both on Sqwiggle and Slack and it gets messy”
• “In Sqwiggle, the snap is where all the fun is, and conversation it’s secondary”
• “The ui is more focused on chats, and talking, less on the presence”
• “It’s like the second version of slack, and we prefer slack #slackforlife”
• “Another app to start and sign in”
• “I’ve got bored”

So yeah, it was clear for us that Sqwiggle didn’t fit our needs. After a while, we were talking about this with each other and our fella Whitesmith José says something like, “hmm I can make a super basic, snap only, version of this in a day”. At first, we thought he said it just to say it. But (yes there’s always a but), the next day he shows up in HQ saying: “hey take a look at this:”

Done is always better than perfect.

That rough implementation allowed our team to do what they love most about Sqwiggle: take funny snaps or just be present!

REMOTE WORKERS FROM THE WORLD: UNITE!

Time flies, and a lot of stupid snaps after, a wild CEO appeared with this idea of opening the doors of our newborn Faces to a world level remote audience. It was definitely not ready for prime time but… Challenge accepted

Design

First we’ve built a simple minimal layout to refresh the face of Faces (I couldn’t resist). The focus was on the snaps and the snapping action itself, so it was a simple grid with the snaps, name and location to identify each user and an actions bar. Just keeping it simple.

Then the name

There are only two hard things in Computer Science: cache invalidation and naming things

Faces never gathered full team approval. To keep recent company’s internal product naming policy (cofs), it should have a “q” somewhere, so we tried “Qaras”, a twig on the Portuguese word for faces, “Caras”… Meh 😑. It’s for remotes, it had to have something related to remotes…

Quick domain search on remotes, remotes.in available, Remotes wins 🎉.

UX flow

At this point, we really wanted to take the barrier of account creation out the process, so we went no-database on this, no saves, no info retained: just type your name, location, you’re in; close your browser tab and you’re out^[3]. In order to avoid people’s one-time-sexy-profile-pic upload and no more fun, we’ve setup a timer that takes a snap every 60 seconds. You can also go the manual way and take a snap yourself, but hey that shiny moment will only last 60 seconds. Carpe Diem Baby.

Social Spice

Taking snaps and being online made sense when this was just an internal product, as we can talk to each other through Slack. But now that this was public we needed to add something to connect those remotes to each other. We had learnt from our Sqwiggle experience so while building this feature, we always had these three things in our minds:

• the fun is in the snaps, make the connect feature available but not an intrusive experience;
• keep the no-account-no-sensitive-data approach for the conversations.
• Do not make the UI look like a chat app to avoid “oh no, not another Slack” thoughts;

Note: These points are a priori inferences of our own internal experience. The power of metrics and public feedback could prove that we are wrong.

Now the challenge was how to build the no-account-no-sensitive-data conversations. I won’t go too technical here, after all I’m a designer whose coding skills are limited to the client side of the force. But hey… I have my jokers… and had the perfect one to solve this problem, sliding off my sleeve.

Appear.in is an app that allows chat and video chat conversations up to 8 people at the share of link, “No login required — no installs”, for free.

It’s built on a new web standard called WebRTC. For you, this means no plugins or installation.

Sweet.

The only downside is browser support, but we’re building this for a techsavy modern workforce so a modern browser is not asking for much right?

Did I mention it’s free?

I told José about it and the conversation was more or less like this: Renato — “We could use appear.in for the talks…”
José — “Yeah that’s cool but how the hell are we…”
Renato — “It has an API”.
José — “Let’s do it.”

So I’ve setup a basic dropup for invite notifications, José did his thing on the invite system and appear.in connected the dots.

Ahhh… love the smell of connected remotes in the morning! 🚀

Fun & Details

Finally, we added some little UX enhancements, namely sounds and web notifications on invites, as well as some just for fun features like dark/light versions and pan view mode.

And that’s it for the MVP, live and running!

BUT WAIT THERE’S MORE… ON THE ROADMAP

Now we have the first version up and running, there’s a lot to be improved, as always, and we have some ideas in our whiteboard that will mostly depend on user feedback:

• Branding and improve overall UI/UX accordingly [WIP];
• Move conversations inside the app to some kind of sidebar or facebook style dropup,(appear.in actually allows that);
• user customizable auto-snap time frequency;
• Desktop app (probably a wrapper using electron or similar);
• Open source;
• Filtering: remotes grouped by work area, interests, location;
• Data-viz: mapping remote work globally;
• Penis detection (I know that this one has crossed your internet distorted mind);

SHARING IS CARING

You’ve come this far, why not join the biggest remote HQ in the world? Checkout remotes.in and share it with your remote friends! Suggestions and feedback are always welcomed!

Keep shipping™, wherever you are!

[1] Zack Holman, How github works asynchronous
[2] Zack Holman, Remote First
[3] We use cookies so you don’t have to “login” again, when “accidentally” close the tab.