Where do you work?
I’m working as a part of DeviantArt. After Wix acquired it back in 2017, we started working on a huge redesign. When I saw this position, I didn’t even know DeviantArt still existed. I was a user of the website back in mid 2000s and this was the website I found my first Photoshop lessons on.
I have a small Design System team which is working on building a ton of infrastructure along with our redesign process. I think it’s the right time to do so since we had a lot of performance, consistency, infrastructure and team communication issues...
I think this is a perfect job for me and my team since all of us are a very organized people who are very detail-oriented, great at communicating and spotting issues in the processes. Our team is the best!
What's your role on the team?
I joined the team for a role of a Product Designer, but now I mix this role with managing Design System and a Design System team. The opportunity for this transition came from me suggesting some improvements to the way we design, doing some small internal workshops and handle our communications. Basically, It all came from my natural frustrations about issues we had and working my way to improve it for myself and everyone around.
For example, here’s a list of things I’m handling at this very moment:
1) Design of our first Mobile Web version and after I finish this simple build, we will pass this to our smaller teams handling different parts of DeviantArt
2) We prepare for our biannual Design System off-site where we discuss all the big issues we noticed in the past half of a year and we plan action points on solving them in the next period. It usually takes 3-5 days of meetings, white-boarding and planning. We try to gather feedback from Product Managers, Devs, QA etc all the time and put it into a spreadsheet, then we investigate those issues, prioritize them and go to an off-site to discuss.
How big is the product team?
Everyone in DeviantArt is in a product team. We have small teams(we call them Bands) dedicated to some specific parts of the Product tackling their issues, planning their workflow and working in their own sprints. Each team has a Product Manager, some Designers, some Front-End Devs and QA. Everyone in the team has a right to affect the product.
As for our design group, each month we have something called “Creative day” where all of us gather in small groups of 2-3 people and build some concept which can improve DeviantArt in a certain way: whether it’s an infrastructure project, some community improvement or just a feature they wanted to build a while ago. Then those projects are evaluated by the Bands and those Bands consider building them and release to our users.
What’s your process like for going from the idea for a small improvement (not a large task) to it going live in production?
Our usual triggers for improvements are either data or user feedback which was reinforced by further research into the issue. We have a ton of data in Tableau and everyone in the team (from devs to support) can access it and raise the flag if they see something unusual. After the issue is raised, it’s been evaluated by the Product Managers and one of the bands take it into their roadmap.
After the time has come, Band’s Product Manager and Designer(s) start doing their research. They investigate the issue, figure out why it’s the issue and what it affects and they start from creating some of the idea concepts on how to solve this issue.
When concepts are done, if the Band has time, they test those concepts on our users. If there’s no time and it’s something very urgent, we release some of them and do split-testing (A/B or other variations of those tests) and continuously watch the data to see how it performs.
The key point here is that we try to spend time understanding the problem rather than just blindly assuming or fixing what user say that need and not really need. Focus is very important for us even in a smaller tasks.
How much (if any) paperwork/bureaucracy is there involved with releasing a new feature/bug? Tell me about your process for planning work in, do you use sprints? Does it work well for your team?
There's not really much bureaucracy. We work in a single workflow in our small Bands. Product Managers, Designers, Devs and QA all user the same board for tickets.
Design documentation is more complex though since we require to cover a ton of system states described for each of the Design System’s components. But at the end of the day, it saves a lot of time when you don’t have to design a ton of screens with a different states of the components inside. Also good for re-usability.
Do you plan testing upfront or chat to testers about it once the dev work is done? And do you take the testing work into consideration when planning what to bring in?
The thing is the majority of the testing is done by either Designers or Product Managers. We usually test our features starting from components used in the feature and all of the states of the component, then the screens. Our QA team usually helps with testing of the back-end and regression since sometimes the release of the new feature breaks current ones.
The testing plan is easy since the list of system states you covered in your component(s) is the list of the states you want to test. Sometimes QA help us find an uncovered things, but this is more of an edge case.
Also, to make it a bit easier for everyone to remember, I created a list of the most common system states we need to cover. Some designers have it printed on their table to make sure they didn’t forget anything.
What’s the biggest annoyances you’ve had around getting stuff done, planning, working together as a team, or that kind of thing?
To be honest, I couldn't even dream of such a great and professional team and a very supportive management. The biggest problem we have now is lack of time, but it’s ok.
When we were starting with implementing the design system, it was hard to align everyone’s knowledge of the tools and methodologies to make sure we keep everything somewhat consistent. There was some pushback when Designers understood that they need to deliver a much higher-quality designs and documentation which usually takes more time and resulted in Product Managers and Designers being unhappy about it. But in the end, with communicating all the benefits of the Design System to everyone and giving some time to practice and make it their daily routine, we noticed that the quality and the overall mood became way better.
Which (if any) tools do you help to keep track of work?
We use Sketch for Designing and documenting components by our templates.
We use Zeplin for delivering those docs to the dev team.
We use Google Drive + Google Docs and Slides as our storage.
We use Axure for an early-stage prototypes and InVision for testing some flows.
We use Slack as our communication tool and Phabricator as a ticket-management tool(although I and most of the team would rather use Atlassian’s Jira+Confluence but we cannot affect this decision now).
We use WhatsApp and Telegram for our out-of-office discussions, memes posting, business trip chats, etc.
You mentioned about preferring to use Jira+Confluence, could you tell me more about your reasons for that?
Most of us think that Jira is more advanced and goes well with Confluence infrastructure-wise. Also the depth of integration of documentation with tickets is what we need.
Another reason is that all Wix is using Jira as their main tool and we have plenty of people in the office who are truly a professionals and can help us with migration.
As a downsides for using Phrabricator I see:
1) Pain with an onboarding of new devs and designers since no-one uses Phabricator anymore.
2) The search tool in Phabricator is very complex and sorting your notifications out takes a lot of effort.
In the end of the day, it’s up to a small number of execs to make the decision to migrate and it can be hard to ensure the developers are always heard.
If it is “up to a small number of execs to make the decision” with Jira+Confluence, do you have similar issues when you want to spend money on other things? Is it easier to spend a small amount of money than big, or always hard?
Not really. Mostly depends on the areas. For example, we don’t have any problems with spending a big buck for quality when it’s coming to design. In my specific case, I’ve seen my management to be very helpful with organizing big changes and allocating resources for them. I would say it’s mostly related to being open to the change on a personal level. We don’t have any financial issues to think about cutting many corners.
Could you go into more detail about how it went implementing a design system in such a large long-standing project? Was there a lot of pushback? Were some parts of the site harder than others?
So from exec level there was no problem. Some of our design and product execs transitioned from Wix where they already worked with a design system. It saved me a lot of time and brain cells when I didn’t have to do any convincing there.
When I joined the team, we actually had a very primitive level of a design system and I we had a team of 10+ designers designing their parts of the product while still figuring out the visual language for a new version. That was a very messy but necessary part. When I joined the team, I started from bringing more clarity and alignment into the process: like implementing 8px grid, doing some workshops and pushing for design libraries.
With each new Design System iteration, we see some push-back, but it’s mostly based on the fear of the unknown. Sometimes, our incremental change require more of time investment from the team, so teamleads and designers are not always happy about stretching the timeline. Usually, in the end of the day, when you explain the value and give some time for the team to test it out and see the outcomes, there’s no issues left. My team still has to re-evaluate some processes we push, learn from a feedback but it’s a natural thing to do in a product so we’re fine with it. We’re not stubborn for the sake of it.
As for the hardest parts of the project, I see the alignment as our biggest challenge. We have a huge backlog of designs we were delivering for 1.5 years and now we try to bring more consistency in our patterns and overall look and feel. This usually takes multiple teams working on the same part and a decent dev investment into rebuilding an infrastructure. It’s sometimes a pain to negotiate putting this activities into a roadmap, but it’s something we’re successfully managing to do at this moment. This is also very related to my management being open-minded about allocating a resources for my team.
So from exec level there was no problem. Some of our design and product execs transitioned from Wix where they already worked with a design system. It saved me a lot of time and brain cells when I didn’t have to do any convincing there.
When I joined the team, we actually had a very primitive level of a design system and I we had a team of 10+ designers designing their parts of the product while still figuring out the visual language for a new version. That was a very messy but necessary part. When I joined the team, I started from bringing more clarity and alignment into the process: like implementing 8px grid, doing some workshops and pushing for design libraries.
With each new Design System iteration, we see some push-back, but it’s mostly based on the fear of the unknown. Sometimes, our incremental change require more of time investment from the team, so teamleads and designers are not always happy about stretching the timeline. Usually, in the end of the day, when you explain the value and give some time for the team to test it out and see the outcomes, there’s no issues left. My team still has to re-evaluate some processes we push, learn from a feedback but it’s a natural thing to do in a product so we’re fine with it. We’re not stubborn for the sake of it.
As for the hardest parts of the project, I see the alignment as our biggest challenge. We have a huge backlog of designs we were delivering for 1.5 years and now we try to bring more consistency in our patterns and overall look and feel. This usually takes multiple teams working on the same part and a decent dev investment into rebuilding an infrastructure. It’s sometimes a pain to negotiate putting this activities into a roadmap, but it’s something we’re successfully managing to do at this moment. This is also very related to my management being open-minded about allocating a resources for my team.
Could you go into more detail about the acquisition? It’s a process I’ve never been through myself, how did it go bringing the various people together? Do you still have any fallback from it or anything?
So I actually wasn’t a part of the team in the moment of acquisition, but from what I learned, there was a half of a year period before and after acquisition when new and old team just did a bunch of onsite meetings to learn the product.
The main goal of Wix was to keep as many people from the old team as possible and make the transition smooth and seamless. The pre-Wix guys know about DA and the community so much more than us and they bring a lot of value into our daily work. There definitely were some people not happy with the acquisition who had a completely different vision and left the company, but you cannot make everyone happy anyway. We kept most of the team and I’m happy about it.
For the design team, I’m completely happy that we kept 100% of the original staff and the insights they bring are great. We would never figure out the logic and thinking process behind some decisions if not them.
Transitioning is definitely hard, especially when you’re working on a big change to a product. You need to merge 2 teams who are used to different styles of management, workflows, culture, etc. 2 years later, we still have some differences, but we made a huuuuuge progress during this period.
You have three big offices and also have remote workers around the world. How does this work for you? Is your specific band across various places?
It’s kinda hard with devs since we hired a lot of remote devs recently and I’m not familiar with most of them except of discussions in the Phabricator tickets.
My team is mostly in Kyiv and I think this is the best way to work. It’s challenging when you need to discuss some major things with people with an 11h difference in timezones, but mostly we Slack pretty efficiently and have a regular meetings to update on our progress.
How does the design and development teams work together? Do you have developers assigned specifically to your team? Do you “pass over the fence” or work together? How does your “feedback loop” work in that sense?
We have devs assigned specifically. It’s not working perfectly right now since it’s a transition period, but it will soon, Each Band has their own weekly meetings and Devs and QA also take part in them. Usually product discussions, planning, etc is being addressed on those meetings and everyone has a right to say.
As for process, I think it’s depending more on a designer. For example, for me it’s easier to run a couple of small demo meetings with devs to make sure everything works rather than design something awesome and learn that it can be developed in like 6 month which we cannot afford and all of it will result in a chaotic cropping of my feature
That said, I would say about 2/3 of design team talk to devs regularly. Other 1/3 don't and only does kickoff meeting.