Building strong relationships
Since our team works 100% remotely, putting time into building personal relationships with our clients and making sure we really understand each other is particularly important. And that works both ways — while we wanted to learn as much as we could about the project in the early stages, the Mirror team also needed to make sure we were a team who they could trust with such a major project.
Rather conveniently in this case, a couple of weeks after our initial phone call to discuss the project, Mirror's CEO, Avish, and their head of strategy, Peter, happened to be visiting London to attend a conference. We managed to sit down and have a great conversation about their concerns and goals for the project. Then, a couple of weeks later, Jon was in San Francisco and we were able to have a second in‑depth conversation about what they had in mind.
Those sessions were helpful. Even in the space of a few weeks between the two, the project goals had actually changed quite significantly. But by the time we kicked things off we were able to match up the right members of our team to the project. That's easier said than done, especially when you're talking about working with a startup going through a very intense early‑stage product build, with rapidly changing needs.
It was also a great reminder for the team on the value of these in‑person meetings. Just because we're likely to be working remotely during the project, it doesn't mean we'll never meet up. And that's particularly so if the project is going to run for a few months, as this one did.
Figuring out our hit‑list
Before the project was due to kick off, we'd sent over a worksheet to the Mirror team to follow up on our discussions and to try and get hold of as much information as we could about their existing learnings. We wanted to hear more about the product needs, and the problems they were looking to solve.
The idea behind sending this worksheet was to try to reduce the risk of us ‘re‑solving' problems which their team had already worked hard to address already. While there's a big benefit to bringing in an external team who can give an outsider's perspective on your work, the last thing you want to do is have them work inefficiently.
We had a few more discussions via email ahead of scheduled project start date, and then kicked off. Day 1 of the project started with a planning and review session at our end, working our way through all the content that the Mirror team had sent over to us, and also digging into a little research of our own.
By the afternoon of their first day on the project, Zsolt and Marcel, who were in Asia and Europe respectively, had a good feel for what work would be needed. As the Mirror team in San Francisco came online towards the end of our day, timing was perfect to have our first kickoff call and talk through our findings and plans together.
When Hanno joined the project, Mirror already had a working marketing website and bitcoin trading application that they'd been working on for a few months. The problem was that we had just a few weeks until the launch date, and while there were infinite opportunities to improve the design of the platform, we had to pin down those areas where we could make the biggest impact, and focus on those most heavily.
We quickly worked with the team to reveal some of the major headaches they were facing, and where we could help their team the most. There were 2 big ones:
- The application was based on a broadly functional, but rather unstructured and undocumented codebase. There was a lot of room for improvement.
- The user experience left a lot to be desired.
Our job was to analyse the user interface, put together a decent action plan and start making progress.
Digging into the codebase
Mirror's CEO, Avish, had a strong eye for design and recognised why great design would be needed in order to differentiate the product. The product UX would be a critical part of their company's competitive advantage — as important to their success as their Bitcoin buy/sell rate and the accessibility of the platform in different markets. As things stood, the design was a long way from achieving that.
Since Mirror had such a strong engineering team, they were comfortable taking care of the backend logic and functionality, which would function as an API. They'd also scaffolded out a rough, but functional, front end which was successfully communicating with their backend API using the AngularJS framework.
We sat down and began looking into the technology behind the product, and the way the codebase was structured. While a little rough in areas, it was well‑organised and was certainly a strong starting point to allow us to explore the application, test plenty of user scenarios, and get a good feel for the tasks which needed to be tackled.
Coming into the project at this point meant that, while we'd certainly be working with functionality on the front end as part of our role, we could focus mostly on the visual and UI of the application, rather than having to build the dashboard from scratch. The Mirror team had already validated a lot of initial assumptions and had many of the conversations about how elements of the dashboard needed to be structured, which was a big help.
From our perspective, this was the perfect match‑up‑while we have good engineering capability on our team, our focus when we work with clients should always be on design, rather than engineering. That's where we can really help our clients out and move them forward, fast!
We split up our list of priorities by dividing the existing product into two parts. These were:
- The internal pages: the web application and trading dashboard
- The external pages: the marketing website and brand messaging
So we started stripping things back. While we were careful not to discard valuable work that their team had built so far, we also needed to make sure that we were building the front end of the product in a way which could be easily maintained by their team after our sprints ended.
It's always a big priority for our team — when you're designing for the web, the technical side of that work is as important as the visuals.
Nobody likes inheriting poor quality code, and for any engineering team, it would be a major disincentive to working with us if we were to deliver that. So we made sure that all of our front-end code followed our code standards and conventions, and was properly set up.
We managed to boil down the whole interface to its bare bones quickly, which allowed us to focus on functionality and ‘big changes' first, and then fine‑tune the aesthetics later on.
This project was an ideal candidate for designing in the browser because of the Angular application that had already been set up. Trying to move as fast as we did here, while putting together mockups in Sketch and trying to subsequently implement them in code, would have been a painful experience. Not only did Mirror's team not have the spare capacity to implement the work we would have been doing, but it would have been far slower, and less effective. By designing in the browser throughout the sprints, we were able to try out new ideas, deliver results almost instantly and discuss our latest changes with the team on a daily basis.
The best laid schemes of mice and men…
One of our biggest learnings in the past year, and indeed, the key reason we moved further and further away from the fixed scope and hourly billing models we'd used in the past, was that projects with startups always change in scope. It's simply the nature of the beast.
Of course, you can always improve your planning skills, and the more experienced you get, the easier it is to prioritise well and anticipate where priorities may change. It's also possible to use our considerable experience of working with startups, to help guide them and set priorities better, themselves. We're certainly focusing on doing all of this, and constantly improving our ability to do it well.
But we've found that part of the solution is to embrace the changeable nature of projects. There's no way to plot a perfect course all the way to the ‘finish line', because that finish line is constantly changing. So we must set ourselves up to be as flexible as we possibly can. That's why we've made the shift to carrying out projects in a way which is relentlessly iterative. We plan, we build, then we assess and discuss progress and plans with clients.
Along with working iteratively like this, we also ensured that the Mirror team had total visibility of what we were doing. We even carryed out all of our work inside a forked copy of their own repository containing the application front end, on GitHub.
As a team, we had to stay flexible in order to bring them deep into the design process, evaluate potential changes quickly with them, help them figure out the best direction for the product, and adapt our process and plans accordingly.
Grappling with timezones
We've been working as a remote team ever since we started up, and we're no stranger to juggling the difficulties of working across timezones. But even so, having the team split across 3 continents during the project was an unusually extreme challenge.
To make sure that the project could run flawlessly, we had to find a way to link up:
- Hiong, Arnas and Zsolt, working in Kuala Lumpur and Bali on UTC+8
- Marcel, working from Spain on UTC+1
- The Mirror team in their San Francisco office, on UTC-8
The way we communicate on projects is something that we've continually refined and improved, to the point where (while still not quite at the point of perfection that we'll always be striving to meet) it gives a very reliable backbone to any project we take on, regardless of which shipmates are on the team, and where they're located.
Fortunately, we managed to make that happen here, too. Even if it did involve some adventurous late‑night travel by Zsolt, who often had to relocate to a co-working space in the evenings for a call at midnight in Bali. That daily standup call, which took place in the afternoons in Europe, and the morning in San Francisco, was an important and consistent point of every day on the project.
But the timezone difference also held many advantages. Since Marcel, working on the development tasks on the project, was working from Spain and was about 9 hours ahead of San Francisco, he was particularly well‑placed. In his morning, he was able to jump online and catch up with the rest of our team in Asia (late afternoon in Kuala Lumpur and Bali), catch up and collaborate, and spend the majority of the day making steady progress on the project. At the end of the day, the Mirror team appeared and could catch up with our progress, evaluate our results and define the objectives for the next day.
We used a bunch of tools for the purpose of staying in sync — each of them for a very specific purpose:
- Check‑in/Check‑out during the day
- A meeting room for all stakeholders and team members to have discussions
- Pinging people for small requests
- Daily standup meetings with the whole team
- Quick voice and video chats between team members
- Grabbing the Mirror team for urgent issues
- Basecamp: An email replacement. Used for documenting organizational and scheduling conversations
- Exchanging documents and assets
- Assigning occasional to‑dos to the Mirror team to complete
Pivotal Tracker: Mirror's chosen project management tool for their own team
- Bug reports and task assignment to Hanno
- Giving an overview of app functionality in development
Branding & positioning the product
But this project wasn't just about building a UI, refactoring the product's codebase, and creating a marketing site. When we kicked off the project, one of the big questions that their team were grappling with was what the new product should be named.
When we first started work, the product was actually known as Bitme and their team, Vaurum. It wasn't until we began to move through the project that the Vaurum team began to settle on a name they were happy with. Mirror turned out to be the name which they felt gave the right balance of consumer friendliness, as well as being ‘serious' enough to work as an enterprise, business‑focused product.
With this uncertainty to work around, we had to stay pretty flexible in how we were going to work with the team on the new brand. Fortunately, as well as having a very versatile UX and development team to call upon, we also had two members with very specific skills in brand analysis and identity design.
Hiong, who had been part of the team for the first two weeks, initially focused on doing a deep analysis of different Bitcoin trading platforms, comparing each of their strengths and weaknesses. This helped us figure out how the Mirror brand should be positioned relative to the existing players.
He put together a set of strategic guidelines that would allow Arnas (working on identity design) to get started with developing ideas and concepts for the new brand, and we were soon up and running.
There are currently two competing approaches in the financial world. The first approach is the traditional banking system. The second is a move towards digital currencies such as bitcoin.
Both approaches have their merits. Both have their imperfections. Mirror was created to reflect the best of both worlds.
It mirrors the fluidity and transparency of digital currencies; while simultaneously reflecting the best practices of security procedures from the traditional banking system.
Arnas began by creating sketches with pen and paper and exploring a few different approaches to the problem. This even extended as far as getting creative with mirrors and exploring how the logo could work as a physical representation.
He shared these with the whole team via Invision. This allowed him to gather feedback from the rest of our team, and also the Mirror team, so we could discuss potential directions and make sure we were on track.
The process of coming up with the brand went surprisingly smoothly. Although initially, the Mirror team had been concerned that trying to tackle a brand identity would be an overly ambitious step and cause us to risk missing the launch deadline, we were able to make sure that wasn't the case. In a similar way to rapidly iterating on a website design in CSS, doing the same with pen and paper, before digitising and refining our concepts and taking them through to a final version, worked very well.
Digging deeper with our cross‑functional team
As we dug deeper and deeper into the project, we began to spend a lot of time refactoring the existing codebase, looking more into the functionality of the application and looking to optimise the structure and maintainability of the product wherever possible.
“Being cross‑functional allowed us to dedicate our resources to whatever was the most pressing concern, whether it was a design or a development‑related issue.”
That's why, instead of locking down a promise to supply specific deliverables when we kick off a project, and refusing to change this scope, we work in sprints, billed at a flat weekly rate for the number of people involved in the project. This allows us to constantly adapt to our client's process and handle priorities more efficiently. In the end, rolling out certain features and urgent fixes is more important than rigidly sticking to a predefined plan.
While the project was initially a UX and front end one, having the skills on the team to be able to go beyond front end and UX design helped us to come up with far better UX solutions. A confusing user path through an application due to technical limitations is as much a UX issue as poor contrast on text and buttons. And fortunately, we were able to help solve those sort of problems, and help implement a couple of critical new features in the product, too.
We've been making a big deal of remote pairing within the team over the last year, and it worked particularly well here. Regular pairing sessions between Zsolt (who was focusing on UX design) and Marcel (on front‑end development) were a big part of this project. The big goal for us is to constantly have team members exchanging ideas, insights and frustrations — something that we've found from experience results in much higher code quality and faster progress.
To give an example, we usually start pairing and ask each other "how might we solve this specific problem…?". Simply asking and discussing the problem at hand, no matter how overwhelming it might seem, enables us to tackle apparently complicated UX issues in a more systematic and collaborative way. Each little improvement felt like we were making progress and getting closer to our goal.
Where is Mirror today?
Understanding the team's ambitious mission and helping them to find a way to meet this, was a really big deal on this set of sprints.
Fortunately, after six weeks of working together, we'd succeeded in delivering a solid brand, a fully developed UI, and a robust codebase, into which the Mirror team were smoothly integrating some of their newer features.
The handover was a seamless one: since we'd been working with their engineering team throughout the project, they were able to fully own the codebase as we departed. That tight integration and shared understanding was exactly what we had set out to deliver, and we were very happy with the results and how smoothly the whole process had gone.
Mirror now has far more confidence and clarity about their brand messaging and identity, and can share this with the world.
And both their product and company are now far stronger. The application is now a seamless implementation of that brand vision: what you see in the browser and on your mobile phone is now a logical extension of the Mirror brand — a modern trading platform for the sophisticated Bitcoin professional.
3 weeks later, we even returned for a second sprint to build out a new set of features and improvements to the trading dashboard based on the feedback and learning that the Mirror team had gathered in the weeks we'd spent apart.
We're very proud of the work we've done here, and to have been able to help such a talented team to create a far stronger UX and UI into their product. Here's hoping they can succeed in changing the future of finance.
What did the team think?
This was one of the most exciting projects I’ve ever worked on. At first, the prospect of collaborating with such an experienced team at a Bay Area startup was a little intimidating for me. Our project goals were very big, and we had a lot to achieve in a short space of time. Fortunately, the Mirror team turned out to be hugely friendly and welcoming and were a pleasure to work with.
I think the Mirror team has created a great product and us working for a couple of weeks alongside their team has really taken their overall user experience and product quality to a next level.
As a long‑time cryptocurrency admirer (I even built a mining rig with a friend ;-)) my heart started beating a little faster when we received Vaurum’s introductory e‑mail. A bitcoin startup? This could be a hot one!
The 'getting‑to‑know‑each‑other' process was not a rapid one — a couple of months separated our first call together, and day 1 of the project. But this was necessary, and during those few months we managed to get to know each other well and see that yes, there is clearly a fit for us and we can work together.
The biggest personal challenge for me was the timezone difference. Working with teams in 3 continents is only possible if someone bends their hours. In this case, it was Hiong and I who volunteered for the late‑night calls. This worked well for the purposes of this project, but it’s definitely something which could be maintained for months on end. We’ll definitely continue to find ways to improve things, here.
Working with an existing codebase is always challenging, but our workflow was the perfect fit here. I’m a huge fan of designing in the browser and it made perfect sense to work that way, here.
This was a great project, and I’m really glad that we’re still able to help out the team with more project sprints going forwards. It has been great to play a part in their story!
First of all, I think I finally managed to find a solution of working with clients who are on UTC -7 while I’m on UTC +8. The solution was to start early in the morning and get the overlap with the client while it’s their afternoon. In this way I managed to collect the feedback and set myself for the day.
I also enjoyed the project, because it was very different from other projects and all about technology, future and disruption in the finance industry. The idea that Mirror can become one of the big life changers in the next few years pushed me to come up with a strong design.
One of the biggest realisations for me was that the identity I design doesn’t have to be always clever visually. Sometimes an extremely simple and iconic style can have a big meaning and story behind it.
One of the things I liked about the client was the “getting things done” approach. This helped both sides to move fast and smooth by reaching a shippable level and moving onto other tasks.