Working as a Remote Product Designer from far far away
As far as I remember, I always wanted to fulfill my life with adventures and purposes. The latest company I worked with, Heetch, gave me the opportunity to combine two of my greatest wishes: bloom as a Product Designer, and doing it while discovering the World.
As a remote first company, all the Engineers were already working fully remotely. But for Product Designer? That wasn’t spread yet, as we expect our Product Team to be close to our users to combine both a user centric and business needs approach. This translated as working from places we were operating.
But the more the company was growing (from 40 to 300 souls when writing these lines), the more we were having product processes we were lacking at first, the easier it was to challenge the status-quo, try and found solutions for the Product Designers to work far from our user base, but doing it in a way it wouldn’t hurt the product, and even enhance it.
The idea wasn’t sold at first, but Heetch gave me a chance to prove them it was worth trying it. It asked for a big jump of faith, a challenging, and sometime scary, one.
This article is the result of several years of experimentations, and something I would have loved to read when I started this journey as a Remote Product Designer far from home, when I had so many questions in mind about how I should do it.
But first, Local or Nomad Remote Worker?
I usually like to draw a line between two kind of remote worker:
The Local Remote Worker
This might be the most well known, as companies are leaning more and more toward remote working. I define them as people who are working from a given and fixed place, which might not be the city, or the country, the company is located, a place they’re staying most of the time.
The Nomad Remote Worker
On the other hand, this second one might be kind of a new specie for companies and Startups sharing a remote first culture. More bind to Freelancer and known as the Digital Nomad, they are the ones always on the move, staying a few weeks in a place before flying away for the next one.
This article is dedicated to this second kind.
When to work from far away
This is the question I struggled the most with, and the one I should have answered first.
It is commonly said a Designer only needs a computer and a good internet connection to work. This is actually both true and false, especially for Product Designers tasked with covering the whole product spectrum, from research to problem definition, ideation, user test and design delivery.
The path to answer this question begins with identifying which goal you’re aiming for.
Identify your roadmap
We divide a year into 4 Quarters. For every Quarter, we have company wide objectives, coming from the global vision and overall strategy set by The Founders. Those are then cascading into goals to reach, defined for each team (Product scope oriented teams, Data, Brand, Global Operations, etc…) with related key results.
Thanks to this, we’re able to create our Roadmap and define which projects are going to answer those goals. This is something we’re trying to do ahead of the following Quarter, so we can begin the new one with a clear plan.
It’s a first step to clear out the cloud regarding remote working, especially if you know how you’re going to move forward on a given project.
A glimpse into our Product Framework
At Heetch, we use what we call a Product Framework.
Long story short, it’s a playbook we’re following for every project we’re working on to make sure we ask ourselves the right questions to solve a problem and keep a consistant, agnostic, shared and known process among teams to make it easier to communicate with anyone in the company.
At some point, we shall probably dedicate an article about this, but so far, all you need to know is that it is composed of 4 major steps:
- Opportunity Assessment: Define the problem to be solved
- Discovery: Come up with the smallest solution that is usable, valuable, feasible and business viable
- Delivery: Implement the solution
- Monitoring: Launch the feature, monitor performance & results to deliver tweaks if needed
Each one of those step can be described as a shared set of activities, giving a pace to the project. Thanks to that, it was easier to define which ones would work best done remotely or not.
🤔 Opportunity Assessment
You might have an intuition about something not working or performing enough in your product. If you have the chance to work with a Customer Care Team, you might even get feedback from the inside.
At this time, we’re digging into data, we’re sending surveys and calling our users to do interviews and get the information we’re looking for to make sure we’re working on a real problem.
Remote shouldn’t be an issue for now. Even from far away, you should be able to segment the users you’re looking for, call them and get useful feedback depending on the kind of research you’re doing.
🔍 Discovery
At Heetch, we’re trying to have a fast iterative approach for ideation. Our philosophy is that if you have an idea in the morning, you should prototype it and be able test it during the afternoon.
This is why we rely a lot on Guerilla testing.
Do it for a week or two and try to get as much learning as you can to assess your hypothesis and define the most valuable solution.
With this mindset, it is expected to have access at any given time to a pool of users familiar with your product, most preferably in a country and place where you’re hoping to have an impact on.
Remote didn’t work so well for this step. Therefore, we would try as much as possible to be all together, Designers, Engineers, Product Managers, Data Analysts, etc… in our office to generate ideas and challenge each other.
But, we found there’re actually two exceptions to this rule:
- if the project you’re working on is aiming to an internal use (such as tools for your teammates) so you can make your colleagues try your ideas whenever it’s needed
- if your product is known enough in your current location to be used by casual people
🚧 Delivery
Guess this one is the most straight forward. We’re producing mockups, specs and high fidelity prototypes for our Engineers so they can work with all the elements they would need.
Remote made the more sense regarding Delivery. Do you need to be in your office to do all of that? Chances are, probably not, especially with a good communication framework (more about this below).
🚀 Monitoring
Your feature is implemented and now live, congratulations! But the work isn’t done yet.
You will probably have to keep track of your KPIs, tweak some elements following user feedback, so on and so on.
Again, Remote proven to be working quite well here, as long as you’re having the good process to monitor and get live feedback from your users, even from the opposite side of the World.
As a Remote Product Designer, you might be getting started to have all the elements in your hands to take a thoughtful decision.
You guessed, that wasn’t exactly “When”, during the year, but “When”, at which stage of your project can you allow yourself the freedom to travel and the luxury to do it far from your user.
How to work from far away
To be very honest with you, I didn’t ask myself this question the first time I flew 10 000km away from Paris for the months to come.
I should have, as the way of working I had in my office needed to be adapted to those new conditions, and it took me quite some try to find the accurate workflow.
Find your routine
I used to be afraid of the word “routine”. It sounded like a repetitive and depressive thing, something I felt I would never experience as a Nomad Remote Product Designer. I thought I would work during the day, backpack at night, move from cities to new places every given day.
Oh dear, how badly opinionated was my definition of a routine.
Routine is a gift, especially in those conditions.
Remote working, even from far away, isn’t vacationing. It’s doing your work, but remotely. Simple. Would you everyday change the place you’re working from? Chances are, probably not.
Before understanding this, I was working almost immediately once I would land to a place, and it was a lot of struggle. I didn’t know where to work from 9am to 5pm, in which place I would make my calls with my team, etc…
It was clear I wouldn’t be able to continue like this. I was losing quite some time and stressing myself for nothing.
After a few tries, I developed some rules to make things easier:
- Duration: Stay from 2 weeks to 1 month or 2 in a given place
- Exploration: Take 1 or 2 days OFF if needed on arrival to explore and find places I could work from (usually, Hotel Lobbies, Coffee places, National Library, Parks and very few often, co-working places)
- Network: Give a shot at FAST (Netflix’s network speed measuring tool) to rank the internet quality of those places
- Breakfast: Check where I could take my breakfast from (if not cooking it myself)
- Sync: Mix everything to have an applicable routine
Manage your time
Depending on where you’re working from, you might have a luxury very few Designers can brag about: focus time.
Time and Attention are our most precious ressources, and with the time zone difference, you might have several hours without being interrupted by a Slack notification (well, if Slack is your biggest issue, there’s probably easier ways than leaving to the opposite side of the world you would say…).
This is kind of the Holy Grail.
In this context, it is important to set time for you to focus, and time to sync and share the work done with your team.
To make the best of this focus period, I used to dedicate some time to plan the following day and prepare the tasks I would spend my time on. Trick is that, as a Remote Worker, you’re fully in charge of your time, and it can be tempting to be distracted by something else.
Planning and prioritizing helped me manage this precious ressource.
When I was working from Singapore or New Zealand, I knew I would have 4 to 6 hours alone to focus before syncing with my team in Europe. Finding the good balance for focus and sharing has been a key element to stay productive when working remotely.
Ideate remotely
Usually, Ideation is done during the Discovery phase of our Product Framework, and remember, this is the step we try to be together as much as possible. But no matter if it’s because you’re the one far away or the people you’re working with, ideate remotely can happen way more often than you would think when you’re part of a remote first company.
Knowing how to hold ideation meeting and workshop can be a tricky situation. Internet is full of ressources to articulate Remote Workshop, but here’re the few keys we’ve been using so far to make it work:
Remote Workshop means it’s parity time!
If member of the Workshop is remote, then everyone should be in a remote condition. This means that if one of us happens to use Zoom to talk with us, we all jump on Zoom as well and dispatch from each others.
It can be very easy for someone being remote to feel excluded when everyone is talking in the same room. Noise, bad network can make it a nightmare call for the remote person. By enforcing everyone to be on Zoom, we make sure we’re all on the same table and create a safe environment for sharing ideas.
Reproducing a white boarding environment
During those remote workshops, Product Designers are often designated to animate them. Overtime, Designer role evolved. From being Creators and Thinkers, they are now being expected to be Facilitators as well.
Some of our Product Designers, Product Managers and Engineering Managers are equipped with iPad and Pencil. Alongside a collaborative white boarding software such as Miro, we try to reproduce the dynamic which happens in those face to face workshop.
Define a clear agenda & goal
When doing a remote activity, a person’s attention span time is often way shorter than when doing the same activity with real person next to each other. It can be very easy to be distracted by minor things and quickly lost interest for what’s happening.
Defining shorter sessions with an agenda and clear expectations helps fight this habit, and this is where the facilitator role take central stage: it’s not always easy to play the Cerber and make sure we’re not deviating off road, but this is the most important responsability to make sure the workshop is doing well and no one is feeling like they are wasting their time.
Test from far away
With defining the correct problem to solve, testing your solution is probably the most important step on our Product Framework. And again, there’re plenty of ressources online to learn more about remote testing, more than I could ever share in this article.
Still, there’re a few keys to share to help you decide if doing remote testing is the best option for you, and if you should be here to do the testing yourself or not. Those are the questions I asked myself each time to take the decision:
- Which kind of feedback am I looking for?
- Which test or protocol can help to get those feedback?
- Do I need to create a specific testing environment to get the feedback I’m looking for?
- With very few bits of context, does the people or users around me can help me get those feedback?
As a Ride-Sharing Company, it was quite easy to find in the street of some popular cities users who have already encountered a product like ours. I think that any user can give you valuable feedback, it’s just a matter of what feedback you’re looking for.
Trust your Product Manager
I have the belief there is a big overlap between Product Managers & Product Designers’s role and what they’re able to do. Both should be able to take part into each other processes and participate to it without any frustration or exclusion.
Together, they form the Problem Framer & Problem Solver duo, and sharing your toys is the best way to work together in the most efficient environment.
As part of this duo, both should join when testing the solution, and if one happens to be remote, in our case the Product Designer, then Product Manager should be able to take the mantle of responsabilities, with some few guidelines:
Create & share the testing protocol
If you can’t make it to the test, prepare in advance the testing protocol to ensure the test will be efficient and won’t be biased. When done, and if not built with the Product Manager already, share it and organize together a few fakes sessions to try it.
Assist to the test no matter what
If the test isn’t a guerilla one, you should be able to assist to the test no matter what. Set up a video call, don’t show your face to not intimidate the tester and let the Product Manager do the dance. Take note and discretely tell your partner if any questions pop in your mind.
No bias when it’s not done by yourself
Once curious discovery we made in our Start Up environment is that when you, Product Designer, aren’t the one doing the test, there’s way less chance to bias it. It’s easy, even unconsciously, to orient the test when you’re the one asking the questions and sharing the protocol about something you designed. Letting someone else, sometimes even someone who isn’t part of the project itself, run the test for you helps getting straight forward feedback and erase those biases.
Communicate from far away
Modern days made communication easier, and remote possible, but when you don’t have the ability to discuss face to face with your colleague while drinking some tea or coffee, communicate effectively becomes a new challenge as it’s a whole new beast to master, especially at long distance.
Dealing with Time Zone
Working from another place in the world might mean having time difference, and for this to work, it can be very useful for your team to know when you will actually have shared time.
Something very simple I did is updating my own space on Notion to share the most important information about my remote sessions:
- Location: Where will I be
- Time Zone: Share the time difference
- Remote Period: From when to when
- Availability: The period I would be available to sync with my team
Pretty basic, but it did the job quite well!
Thing is, you’re the one moving away, so you should make it the easiest possible for your team. There’s no perfect and universal balance to share here unfortunately, it’s up to you to find your own, but one thing to keep in mind is that you should be the one adapting your schedule to your team, and not make it the opposite.
Unless it’s really difficult on your side, don’t make the team change the actual ritual slots in their calendar to fit yours.
Prepare your meeting
Remote or not, this should be the basic to anyone, but it’s even more important when your time is limited.
You probably don’t need to spend hours preparing a meeting, but a quick checklist with the following items will help quite a lot to optimize your time:
- Topic(s) to discuss
- Expected outcome(s) of the meeting
- Asset(s) to share
Share those points at the beginning (or even before if you get the ability to) so everyone is on the same page and know what the focus is.
Also, if you feel like the discussion if going off-road, do not hesitate to tell it kindly and clearly so you can center the debate around what matters at the moment. Take notes of the feedback, and once your topics are done, and if you have time, spent the rest of the meeting talking about them.
Never skip Rituals
Rituals are regular meetings defined as “a ceremony consisting of a series of actions performed according to a prescribed order .” As Remote Workers, we’re not physically next to our colleagues, and those opportunities are here to create links, even if that might sound tempting to skip some of them.
Feeling isolated is something which can happen fairly quickly and without notice, so once advice: never skip Rituals.
Good Rituals can make or break a Team. As a Remote Product Design Team, we try to get a good mix between casual calls and Product Design oriented ones:
- Monday Chill Call: We gather all together, and we talk about our week-end, team-related topic and plan for the Weekly Design Critique(s)
- Design Critique: On Wednesday and Thursday, we’re holding two 30 to 45 minutes sessions to talk about our projects and share feedback about it
- Product Design Workshop: Every month, we hold a Product Design Workshop where we take one topic and try to tackle it all together. It can be anything, from training to new tools, pair designing or even actually discussing Rituals and organization.
On top of the Product Design Rituals, we also have Product dedicated ones, such as:
- Product Critique: A time for Product Design and Product Management teams to gather all together and talk about the problems we’re trying to solve, the keys criterias we’re looking for to define if we solved an issue and get feedback on solutions we’re aiming for.
- Product Demo: Every two weeks, we’re having a Demo where we show what we’ve been working on and the state of our projects to the whole Product-Scoped Team we’re in, so anyone can be aware of what’s happening
- Sprint Retro: This is a Bi-Weekly retro to share was worked and what didn’t during the last 2 weeks, but also your own positive (or negative & goofy) adventures!
Those are all synchronous rituals, but working remotely from far away, you might not be able to always be available in the same time (it can happen unfortunately). The tools you’re using and how you’re documenting your work can be a great counter to this bad effect.
Document your work for asynchronous communication
Always remember this: Design is not your mockup. Design is the decisions you’re taking, and your job is to make sure to communicate them as clearly as possible.
Remote means people are free to make the work fit their personal life and schedule, and not the opposite. You might be moving around the World, you might not be available due to time zone difference as explained before. Whatever the reason, thing is, you probably won’t always be around to answer all the questions your colleagues might have, and same thing the other way around. Documentation is a way to make knowledge available to everyone at any given time and not be a blocker in the Product lifecycle.
Working remotely means embracing asynchronous communication.
Design is not your mockup. Design is the decisions you’re taking, and your job is to make sure to communicate them as clearly as possible.
The Remote Product Designer Holy Trinity
With great powers come great responsabilities. This is how I (and probably Uncle Ben too) would define your duty as a Remote Worker.
While synchronous meeting is a must-have, you can’t always share everything, being because you’re limited in term of time or other topics are more important to be covered during those common times.
Embrace this constrain and find your workaround and the appropriate tools.
As for myself, this resulted in using 3 primary tools I now rely a lot on:
- Figma: My primary design tool. With its real-time design approach, we were able to do interactive Design Critique, Remote Workshop and Pair Designing like we were next to each other, and even better, I didn’t have to share my screen for my team to see what I was showing, as they could use the real-time tracking feature to follow my cursor
- Notion: Our one source of truth. All our project and overall documentations are available to everyone in the company there. With its notification system, it’s great to share your papers with the outcomes of your last design approach, your research protocol or your recommendation matrix following tests
- Zoom: Once the team is onboard, nothing better than having a face to face communication. With Notion as the note paper and the ability to work in-real-time together on Figma, this made for the perfect collaboration combo
I didn’t mention Slack or similar softwares, as it’s probably expected from any companies nowadays, Remote first or not.
Challenges & Tips from a Remote Product Designer
Working Remote from far far away in a fully distributed team comes with great opportunities, but also many challenges you wouldn’t expect to face at first. Those are probably the ones which stuck the most in my mind:
The feel of loneliness
This is not something Remote Workers talk a lot about, but the feeling definitely exist.
You’re traveling and working from new places, great, people might even say you’re living the life! But moving from places to places, without really belonging to any of them, maybe not having somewhere you can call “Home” or not creating long-life relationship with the people you meet can bring a sense of isolation and loneliness.
You might see great pictures on Digital Nomads’s social network, making it like the perfect way of living, but losing your social cycle, having to re-create one each time you’re moving somewhere new, this ask for a lot of physical and mental energy. Keep that in mind, Remote working is not for everyone.
Meeting new people
Traveling as a Product Designer is such a great excuse to meet new professionals from the industry from any place you’re going, more especially if you’re going to big cities where Product Design is a thing.
But not everyone can be extravert, and meeting new people, from or outside the industry, can be a singular challenge on its own, and so far, I didn’t find a miracle formula, only some nice tips to get opportunities to make things happen:
- Guest House: you would surprised how many professionals you could found there! Alongside other Digital Nomads or people traveling for the pleasure of it, this is one of the best opportunity to meet people which are in a similar mood as you are, and there’s nothing better to make a great first contact!
- Designer Meet Up: No matter in which big city you’re going, Product & Design Meet Ups are probably a thing. Being in Japan, Taiwan, Singapore, US or Europe, there’s not a place I’ve been I wasn’t able to meet Designers, with some of them becoming friends along the way, and learn from their way of working on their Product.
- Language Exchange: All around the World, people are willing to share with you their culture and get to know where you come from. I’m not saying you will learn Chinese in a few weeks, but this is a wonderful opportunity to meet local people and learn from them and feeling part of the community.
- Facebook Community: This is sometimes disregarded along my friends, but Facebook Groups are full of people seeking for advices or to help other people.
Never hesitate to talk about your frustrations
When you’re working next to someone, you can usually feel when something isn’t right, and you can quickly take a break to talk about it. This is more difficult remotely.
It’s easy to keep your frustration for yourself and not telling your colleagues when something they did hurt you, or misunderstood something one of them said, and it’s even easier to keep it inside yourself until you’re about to explode as you couldn’t take it anymore.
Never hesitate to talk about your frustration, and do it in a constructive way. Tell the people how you feel, ask them what was their intention if they said something which hurt you, assume for the best, but express yourselves at any given time to diffuse a possibly anxious and stressful situation.
So, does it work for Product people?
At first, Product Designers were only allowed to work remotely from a place Heetch was already implemented. Not for performance tracking purpose, but because we believe in quickly testing our ideas and therefore, we should always have access to a pool of users ready to help us and answer our questions at any given time.
I believe you perform best in your work when you’re happy, and companies should aim for employees to have both a meaningful job and give them opportunities to get a satisfying life. What made me happy was to both work as an efficient Product Designer & discover new places at the same time.
I wanted to challenge the status-quo to prove remote could still work in this context, traveling around the world but still enjoy my Product Designer work and doing it best. If done well, this could be a competitive advantages to onboard new talented Product Designers.
Heetch was open to give me a try at this to prove them it was possible. It started by being remote for a few weeks, seeing what worked and what didn’t, then a month before doing it for 2 months straight away every Quarters and more.
Right now, my experiment showed that leaving for 2 months per Quarter was a good balance. If you can have a Roadmap validated with identified projects before the Quarter, it even easier for you to organize yourself with your team.
So, yes, I would say it works for Product people! To be honest, I’ve never been as happy and productive as I was when working remotely from the other side of the World compared to doing it from Paris.
Reach out
I truly believe allowing collaborators working from anywhere they wish and how they want to will change people’s relationship with work, both for companies and individuals, to the point that I believe it will change the World for the best.
Remote working is still something new, we’re testing the limitations, seeing the benefits, and there’s still a lot to discover about it and build to make it even better for every collaborators.
This article was mainly focused on Nomad Product Designers working from a company and something I wish I would have read when I started my journey, but most of the learning can be applied to any Remote Workers.
Congratulation if you made it to the end, it was quite a long read! If there’re questions you had in mind, I’ll be more than happy to answer them if I have the ability to.
Feel free to reach me on Twitter at Twitter.com/@JuanGGZ.
