Netwealth: A Case Study in Cross Disciplinary Collaboration
A couple of months ago we launched the new website for Netwealth. It was a particularly satisfying project for us given it was about 6 months in the making, with hundreds of Sketch artboards created, many lines of code written and plenty of assets exported. We also got to work with a newly created brand designed by our friends at PUSH. It was a real treat working with an identity that offered up plenty in the way of colour, typography and imagery — all the good stuff.
That said, one of the most successful parts of the project was that we didn’t do any development at all. That was the responsibility of Netwealth’s internal engineering team, who did a amazing job not only in the total restructure of their CMS, but followed through with some really tidy front-end work as well.
This project was our first real foray into working with an internal engineering team. Here are some of the things we learned.
Be transparent, not opaque
Prior to joining MASS, I spent many years sitting metres away from the front-end developer who would ultimately be building the thing I was designing. Fast forward to late 2016 and with the project starting to gather steam, we had to find a way to recreate the same environment that existed in my early years when designers sat shoulder to shoulder with developers.
Luckily for us, Slack existed. For all the marketing speak about reclaiming your work day and eliminating email, it really did allow for both those things. It allowed the developers and designers a direct line to each other, which helped foster healthy discussion on a regular basis. It encouraged the asking of questions, the sharing of inspiration and kept conversations relatively casual. For two teams in different offices, Slack removed any feeling of that designer versus developer / client versus studio mentality that can often arise.
But before this gets into a shameless plug, it’s important to note that Slack was merely a tool that we adopted from the outset. It was only going to collect dust had the team not committed to making it work. By that I mean the commitment to being transparent — in what we were working on, in what questions we had and in what problems we were facing. That beautiful aubergine interface we all know and love just provided the means to make that commitment a reality.
Eliminate interpretation
My philosophy when working is that you may as well get it right the first time to avoid heartache later on down the track, whether that’s in the design work you hand over or the feedback you provide. This was only heightened as we transitioned from design into build.
We acknowledged early on that we had to have seamless workflow in place to make that treacherous period between design and development as pain free as possible. Sketch and Zeplin were two tools we had used previously so they were locked in from the beginning.
Zeplin’s ability to translate designs from Sketch into easily inspectable elements meant that the guess work (at least for the front-end build) was taken out. This was advantageous for us because it allowed the feedback to be focused on ways to improve the interface beyond just what it looked like, rather than getting bogged down in fixing alignment, spacing and scale. As long as I kept things thorough on the Sketch side of things, I had confidence the development team could implement to the pixel.
As much as we love the pairing of Sketch and Zeplin, it only solves about 50–60% of the problem when designing interfaces. Things on the web (or screens for that matter) are not static; they move, flex, change size, animate and can look terrible if you don’t pay close enough attention. Historically, it has always been tricky for me to describe interactions beyond the ones we see all the time — luckily there’s been a flurry of programs pop up in the last few years that are going a long way in solving this hurdle.
For this project I settled on using After Effects (as I had quite a bit of experience in it already) to mock up a number of bespoke interactions that we had proposed in our static designs. These helped for the most part, but only to a point. There were some significant drawbacks; namely the fact that they weren’t interactive, couldn’t export usable code and didn’t accurately represent how things would animate in the browser. As a result, these interactions were still open to interpretation even after the mock ups were complete — not ideal.
Thankfully the developers at Netwealth were able to make sense of the Quicktime files and recreate the interactions without much fuss. And just like I mentioned above re: Sketch and Zeplin, what we were then able to do was push the result much further than what I had initially come up with in After Effects.
Design systems, not pages
There has been a lot written recently (and not so recently) about design systems from people who are much more qualified than I am. If you think about your favourite apps/products for a moment; AirBnB, Uber, Spotify, Slack, anything from Google (these are just a few of mine) — all of them are likely to have been built on top of a robust system to ensure consistency and quality across the business. What was interesting with this project was the way in which we approached the design and subsequent rebuild of the CMS to ensure a similar level of consistency and quality.
Creating content managed websites is nothing new. Previously, that’s meant, for me at least, looking at projects from a template (or page) level. What we wanted to do with netwealth.com.au was get a little more granular than that and give content authors access to a suite of components to effectively be able to build their own pages. We needed to think beyond what the public would see when they typed in the URL—we had to consider these authors just like any other user and work to give them the best experience possible.
The strategy of designing and building components meant that we treated this website much like a digital product. Part of our vision for this project was to future-proof the work to a degree, to allow for scale and a long shelf life. That said, the mindset of creating a system over pages was something I, in particular, hadn’t fully grasped in the early stages. As a design team, we defaulted to page design straight away, which in hindsight probably clouded our judgement to a degree when it came to identifying components that were ready for build. The fallout from this was that there were a handful of components developed that probably shouldn’t have been — we missed the boat on setting aside time to really stress test and consolidate our initial list.
Speaking openly, while this did have a flow-on affect of sorts, it has ultimately meant that the content authors now have a pretty luxurious suite of things to pick from. Although the pages will be built from a common library, there is enough flexibility in the way components can be ordered, turned on and off, customised with different colours, type and images etc. to ensure the site maintains a unique look one, two or even five years into the future.
Should I send through .zip files?
If I could have my time again, the way in which we presented and stored our work digitally is something I’d definitely want to change. It all sounded easy enough from the get go— we had the team all signed up to Slack, there were a multitude of cloud based tools out there to chose from and we always had email (and .zip files) to fall back on. Fast forward a few months into the project and it was becoming apparent that I had underestimated a few key things:
- The sheer volume of screens that were beginning to compile
- The inherent lack of context around displaying static screens that were a part of specific user flows
- The rigour required around having a solid feedback loop
This posed a few problems around some of the choices we had made up until that point. Slack was fine for day to day communication, but quickly became unmanageable for sending through work. Posts ended up getting buried if you were out of the loop for more than a day. Even with the best of intentions, it was unreasonable to expect anyone to be on top of it all, particularly given Slack was a new addition into a lot of people’s workflow.
To combat the issue of buried posts, we moved to Invision — somewhere to catalogue all our work and have it sit permanently ready for the client to check in when necessary. Although this went some way to solving the Slack issue noted above, it also presented a few new ones:
- It was difficult to get a good view on a set of screens (i.e. user flow)
- We didn’t have the luxury of stitching up every user flow into a clickable prototype due to time constraints
- We still had too many screens
- It was tricky to stay on top of versioning to ensure the client was looking at the most up to date work
In the end we didn’t really get to a point where we had a streamlined feedback process. What we deduced was that it wasn’t the fault of any one piece of software, rather that we just didn’t find a combination that suited our team. We tried a few things, sampled some bits of software but ultimately fell a little short — and that’s okay! It’s important to acknowledge the shortcomings of a project even when a lot of other things seem to be going right.
On reflection, the method that ended up being the most successful (which I’ll explore in more detail below) was just catching up in person and running through work on the big screen. It gave everyone the chance to have some input, regardless of whether or not they were involved in the project directly.
Show your face
One of the things I was more than happy to leave behind after starting at MASS was the dreaded client presentation—the presentation where you’re madly scrambling a few days prior to get stuff for the ready for the keynote; the presentation that’s meant to distill weeks and weeks of work into a tidy 20 page document; the presentation that will be your only face-to-face with the client in over a month. That all seems a bit old school for us and at odds with how we work generally, so we were pleased not to have to work like this with Netwealth.
That’s not to say we stopped doing presentations—we actually did quite a few, just more often. The nature of working Agile was that we always had something in the diary every fortnight, with ad-hoc check-ins happening as required. That said, the vibe when we did meet face-to-face was far more casual and more closely resembled a chat between colleagues rather than the big board room scene I had always envisioned.
What started to become apparent after we’d done a few of these fortnightly catchups was that the element of surprise was gone. The client always had visibility on what our goal was for the sprint so could anticipate things to a degree. Sure, there was the odd curve ball, but I can’t think of a time where we’d totally missed the mark. The combination of offline discussion (Slack) and our time face-to-face allowed everyone’s expectations to be realigned. The process of doing the design work, taking the client through it in person (as often as possible) and then refining as required proved to be one of the great successes of the project.
I think Work & Co. say it best
We ask our clients to participate directly with us in an intensely collaborative process based on specific measures of success, rapid prototyping, and continuous testing and improvement. The result is one combined team, making things the right way, with less time invested in presentations and arbitrary deliverables.
Even though we used the term presentations above, we’d like to think that they were a lot more than that. We’d like to think that they were a lot closer to what the Work and Co. guys describe. This idea of continuous testing and improvement, combined teams and making things the right way is what we strived for with Netwealth and what we’ll continually strive for in future projects.
Prepare for that storm
This one is more of a note to self if anything, but the final push to get all the assets created, sorted and catalogued proved a much bigger task than what I think anyone had anticipated.
What ended up being the biggest thorn in the side was less the actual creation of everything and more the associated admin that came with it all. You’ve gotta be able to keep track of your assets in the short and long term and unfortunately for us, the storm came quite late in the piece and we weren’t able to get a proper repository in place in time. That’s not to say that the assets didn’t get delivered, just that they were drip fed over the course of a few weeks; updated, changed and refined as we went along, which wasn’t ideal for anyone when it came to figuring out what the latest versions of anything were.
Some advice I can give is that it’s never too early in a project to start building your asset library. If you can remove all the admin bs and instead concentrate on creation, I can guarantee a smoother run to the finish line.
In conclusion
If you don’t have time to read all the detail, here’s the TL;DR
Context
We (MASS) were tasked with designing the new Netwealth website, with their internal engineers responsible for the front-end and back-end build. The nature of the engagement meant we’d be in separate offices, with working methods required to ensure that this wouldn’t become an issue down the track.
Identifying the highs
- Slack provided the means for the design and development teams to operate as if they were in the same office
- It encouraged regular discussion from both sides. Any problems or questions that were raised were solved quickly
- Combining Sketch and Zeplin worked well to eliminate interpretation when it came to transitioning from design to development
- Our feedback was focused on pushing on the design work further rather than bringing it up to scratch
- The strategy of creating reusable components allowed content authors to build out pages that weren’t necessarily designed
- Fortnightly catchups with ad-hoc check-ins (both face-to-face) worked a treat and gave everyone the opportunity to have a good chat about where the project was at
- The frequency of these catchups resulted in a much more informal vibe, which helped build the relationship with the client
Recognising the lows
- We weren’t able to provide the same level of detail with our interaction prototypes as we were with our static designs
- This was due to the decision to run with After Effects, but also that the right tool (for us) isn’t necessarily out there just yet
- There wasn’t enough rigour when stress testing components to ensure we weren’t building ones that didn’t need to get made
- We didn’t end up having a good solution for housing design work that could be accessed at any time
- It was difficult to stay on top of versioning with the amount of screens we had catalogued
- As a result, the feedback loop wasn’t really defined
- We underestimated the effort required to create, sort and deliver all the required assets
- The final handover was rushed with different versions being drip fed right up until go-live
Final words
There was a lot that went right with the Netwealth project; in part due to the efforts of the development team who were able to totally re-build it from the ground up. There was also a lot that went right from a team dynamic point of view. Putting aside some of the workflow hiccups I identified, there was really little to no friction from either side throughout the whole process.
This project proved, in many ways, that being a design only digital studio works; that inter-office collaboration can definitely be achieved with the right tools and attitude; that there’s no reason why you can’t just focus on what you’re really good at rather than trying to spread yourself thin.
Personally, it’s made me a better designer and communicator and it’s given me greater empathy for developers working client-side. I can’t really see a better way of working from now on.
