How do you build your internal tools when you don't have a designer?
By
Cláudia Conceição
Engineer designing in her free time. Sustainability and sports passionate. Adidas fan. Learning saxophone.
View All Posts
One of the key objectives of our core Experimentation team at FARFETCH is to provide a single experimentation framework across the company. By building on a common and shared approach, every piece of our business can leverage our AB testing and analytics infrastructure and apply our best experimentation practices consistently.
We already provided a back-office tool where we could set the variants of their tests - aka the Dashboard. Yet, managing an experiment end-to-end, from its definition to its analysis, originally involved multiple internal and third-party tools.
That’s why my team, the Experimentation engineering team, decided we should move to the next step. The goal was to bring all our experimentation tools together into a single one for everyone: The Experimentation Hub.
A major challenge for us was that we didn’t have a designer on our team - and we would really need one! So, once we started to discuss this idea, my old-designer-self started immediately thinking about what the best tool would look like. It didn't take much longer to say it out loud. Boom! Besides being one of the frontend developers, I was also gonna be the team's designer. Challenge accepted!
Phase 1: Connecting the dots: system components and users
Right from the start, we were sure about one thing: this tool must empower Farfetchers to be better at their daily work and with less effort. So we kicked off the project by talking with some of our FARFETCH colleagues who were active experimenters. We wanted to understand their experience, pain points, suggestions, daily tasks, etc.
We concluded that the following was roughly our experimenting teams' general workflow:
- Product managers fill out our one-pager hypothesis definition document on Confluence. Product managers create a new experiment on our experimentation Dashboard, defining only the experiment variants.
- Product managers ask analysts to configure the experiment metrics, scope, etc. on our Declaration Form, which was originally an internal tool consisting of a manual Python script. We also learned this step could take place while the experiment was already running due to the potential unavailability of the analyst.
- The Declaration Form was very long, not user-friendly, and owned by our data science team.
- The experiment's results data analysis would be performed using a third-party tool Looker.
Thus the entire process of defining, running and analyzing an experiment required different stakeholders to perform different tasks in three different tools. This was overly complicated, error-prone and inconsistent.
Experimentation tools at Farfetch before this initiative
We had a big challenge ahead and the biggest hurdles to jump were:
- How could we structure all of our user requirements in one tool?
- How could we make it straightforward, self-explanatory and simple to use?
- How could we solve our users' main pain points?
- How could we educate our users throughout the interface?
Phase 2: Prototyping and testing it
We started by combining our Dashboard and the Declaration Form, enabling our users to set up an experiment from start to finish in one interface.
To achieve that, we talked with our data scientists to understand their tool better. We reviewed the form in detail and realized that before integrating it into the dashboard, we needed to reorganize it. We quickly learned that we had to work closely together and on a daily basis. To achieve this, we also integrated our data science and engineering teams! To make our tools work better together, we recognized that our teams also needed to work better together.
We started with paper prototypes and later evolved our designs on Figma. As someone responsible for our tool design who wasn't an "official" FARFETCH designer, we were challenged to know our FARFETCH back-office design guidelines and to identify the (real) back-office designers that could help us. We then continuously shared our work with them for feedback. Their input was really important to ensure we were on the right path - in true FARFETCH #TodosJuntos spirit.
As soon as we had something testable, we gathered with analysts and product managers to test our prototypes. Initially, I thought we could ignore that step because 1) my main role was to be a frontend developer, not a designer who is fully dedicated to the design process, and 2) we really wanted to deliver a final solution as soon as possible. Yet, to my delight, our team lead and product manager recognized the importance of testing our ideas. (I mean, we are the Experimentation team after all, right?) They gave me total freedom and support to go for it. How awesome is it to work surrounded by people who also strive for the best?
The tests really helped validate things we were not completely sure about. They gave us more confidence in what we were doing. Not only did we receive feedback on the UI, but we also collected more information about the different experiences of different users. After each test, I would compare my ideas with my product manager and we would update our Figma design right away.
During this phase, we also made sure our documentation for this initiative was up to date and with as much detail as possible. This allowed us to understand all the work we had ahead and enabled more precise estimates.
We tested, we learned, we redesigned, we tested it again and, finally, after several iterations, we reached a good solution we could start implementing.
This phase required me to balance my dual designer and front-end developer roles. My designer self first wanted to fix every pixel and make everything perfect. On the other side, as a front-end developer, I just wanted to start coding because I knew it would be better to test a coding prototype with the users before it was "design perfect".
The bottom line is: as soon as you are comfortable with your solution, code it and test it. Give it to your users so they can use it in their real-life situations and you will naturally understand what needs to be done. And let's be real: the world is not going to stop and wait for us to have the best and final solution!
Phase 3: Building it and shipping it
Although we were initially focused on the UI and UX, throughout I had always been thinking about the challenges we would have on the frontend implementation. This enabled us to have a clearer idea of what UI/UX we would need and the time that would require to support it in code, which worked a lot in our favour.
Often when you have a handoff between dedicated UI/UX designers and front-end developers, you don't want the UI/UX designers to self-limit their ideas based on mistaken assumptions of what is difficult to implement or not. But this increases the communication and feedback loop to reach the right tradeoff decisions. While I don't consider myself an expert designer, playing both roles simultaneously allowed me to navigate these tradeoff decisions quickly.
At FARFETCH, we work with a continuous delivery approach in mind. Thus we wanted to build a feature and deploy it as soon as it was finished. Therefore, before shipping the new Dashboard to all Farfetchers, we did soft rollouts. We selected a group of users and gave them access to the new version. This strategy enabled us to test it live, get feedback from our users, and fix some issues before exposing them to the entire company.
Experimentation tools at Farfetch after this initiative
Final Thoughts
As a team, we are proud of what we have accomplished. Our internal users love our new Experimentation Hub -- they shared many heart emojis on our Slack channel after we announced the release. But more than releasing a great product improvement, we evolved our team, improved our processes and communication - even after going 100% remote overnight - and we now know a lot more about experimentation than before. And still, there is a lot yet to come. New ideas are constantly coming up. New requests and new user challenges constantly arise.
As for my own experience, I’m really glad I could help the team and improve my design skills. The fun part is that I couldn’t be the designer at one time and then switch to a frontend developer later in the project. I found myself working on Figma and thinking already in CSS! I was both at the same time, and that is what enabled me to think of the best solution as a whole from the beginning.
What really makes me proud is the dedication everyone put into this project - expressing our FARFETCH #TodosJuntos value - and the feedback we received from our users. This tool is not just a bunch of code with a functional UI. It’s also a collection of our best ideas and intentions, built with our desire to improve our colleagues’ daily lives and impact our company. All of which made it so good to work on.
If you are facing the challenging task of rebuilding your internal tools without access to a UI/UX designer, here's what I suggest to help improve your outcomes:
- If you have a front-end developer on your team who might be something of a rookie designer, consider having them play a dual role like I did because they might effectively anticipate tradeoffs between design ideas and implementation feasibility.
- If your internal tools reflect a troublesome process that might be split among different teams, consider co-locating some members of the different teams -- if not at least temporarily combining them. This will improve your understanding of your respective systems and accelerate your mutual understanding and coordination.
- Focus on learning from your internal tools' "power users" and consider making them key stakeholders in your project for regular testing, feedback, and early rollouts as "beta users".
Our accomplishments wouldn't be possible without sharing knowledge between disciplines and embracing new roles and responsibilities. It has been quite a ride and we’re excited about the road ahead.
Just experiment, follow your curiosity, challenge yourself and it will pay off, both professionally and personally.
