How Mobile App Designers and Developers Can Work Better Together Remotely
The best products and services usually result from successful collaborations. On the surface, the end-user rarely gets to see all of the moving parts that go into creating their favorite apps and programs (at least that’s the goal). Depending on the organization and the project, getting disparate teams of designers and developers to work synergistically can feel like herding cats.
Collaboration becomes even more difficult when you can’t be in the same office with your coworkers or partners. Conversations suddenly take a lot of extra effort. All of a sudden, you can’t just get a question answered by walking over to someone’s desk. Additionally, while working in an office can feel collaborative, working remotely can make it feel like you’re working on a project by yourself.
Here are some tips to get your team working better together — remotely, and in person.
The Communication Wall Between Devs and Designers
Developers and designers generally speak different languages — literally and figuratively. From dealing with geographical and cultural differences on remote teams working across the world to technical and creative differences, designers and developers often tend to work in silos, even when working on the same project.
According to the typical project trajectory, the design team creates the blueprint and vision of the app or program according to factors like user research, usability, and design aesthetics. Once that’s done, the project usually changes hands and goes to the developers, who then have to deal with the practical aspects of actually getting the thing to work.
The problems that many teams face usually pop up somewhere in the middle: the designers and developers didn’t talk to each other early enough or frequently enough to establish whether what is desired can actually be done.
A designer may not necessarily grasp the challenges involved in programming even “simple” design elements. Developers may not have the insight into the user requirements and behavior that justify a design choice that doesn’t necessarily “make sense” from a programming perspective.
Designers and developers may be different breeds, but they need to be communicating clearly for your app to succeed — or, at the very least, to not become a frustrating mess for those that work on it.
All of these issues are present in the best of times when everyone can hash out their differences around a conference table. But when you’re working remotely, every minor communication issue quickly becomes something much more frustrating. To prevent that from happening, managers (and the developers and designers themselves) have to create strategies to encourage communication.
How to Make Communication Easier — and More Frequent
The first step is simple: you need to really make your team like a team. Introduce everyone at the beginning of the project, even if it’s just to “put a name to a face” in the beginning. As we’ve established, developers and design teams tend to work in silos in many organizations, and may never even meet or have direct communication with each other throughout the life of the project.
This is especially true in a remote environment. When developers and designers are working by themselves, it can really reinforce the feeling that everyone is working in a silo.
And to be clear, we don’t even mean designer and developer silos — we mean everyone feeling isolated for(.
This really reinforces how important it is for you to introduce everyone on your team to one another. Yes, we know it can be awkward, and we know it can seem sort of silly — but creating actual bonds between people on your team is crucial.
It’s much easier to have empathy — and ask for help — from a specific person than an anonymous member of an impersonal organization. This is especially true for scattered teams working remotely, but it also applies to designers and developers working on different floors or opposite ends of the same building.
Find the Right Tools for Your Situation
Everyone has a personal preference when it comes to productivity and communication tools. With so many choices, it’s impossible to get a consensus and keep everyone happy when dealing with a team of people with entrenched work habits and practices. Build a consensus by taking an early survey of the members of the design and development teams to see how they manage their time and the tools they use to communicate and stay organized.
Here are some common collaborative tools that we’ve had experience with:
Direct Communication Tools for Remote Offices
If you’re working remotely, you need to stay in touch with everyone else on your team. We’ve written about some of these tools before, but here are our favorite picks for communication and conferencing apps.
There’s almost no way you haven’t heard of Slack if you’re either a developer or a designer. If you haven’t, it’s a simple chat program that’s extremely customizable for various environments. However, to really turn Slack into a powerful tool, you need to pick up some of the many integrations that it offers. For example, you can link up your calendar, your DropBox account, and more.
For traditional environments that rely mostly on text-based communication and only rarely require voice conferencing or screen sharing, we think Slack is the ideal pick.
While we’re big fans of Slack, we think there’s an argument to be made that Discord is just as good — if not better for certain tasks. While Discord looks (and behaves) a lot like Slack, it offers up more customization for channels and organizational roles. As it was originally developed for gamers, it also allows people to hop into voice channels without starting a call — something that Slack can’t do. For large collaborative projects, that can be a huge boon.
For offices that require more flexibility and would prefer a solution that allows easier voice conferencing without sacrificing text channels, we think Discord is the ideal pick.
In just a short period of time, Zoom has become the de facto remote work conferencing app. There’s a good reason for that, too: Zoom is easy to use, it makes collaboration easy, and it works across many platforms.
Yet, it isn’t without faults. While we think it’s still worth a look, the massive amount of attention the app has received has exposed some security vulnerabilities that should give any user pause.
For offices that don’t mind combining a video/audio conferencing platform with a text-based platform like Slack, we think Zoom is the ideal pick.
Webex is another conferencing platform similar to Zoom. There’s a lot of features that overlap here — although it isn’t as user-friendly. We’d suggest using Webex over Zoom if you’re in an environment where security is a major concern.
For offices that want a video/audio-based solution and value security, we think Webex is the ideal pick.
Ultimately, deciding which conferencing and communication app works best for your organization is a decision your team will have to make for themselves. There’s no clear winner here — it’ll come down to which features you value most.
Set Up Communication Channels for the Life of the Dev Cycle
Working remotely isn’t just about having the right tools — it’s also about having the right processes in place.
Ideas — and the products they give life to — live and die according to their ability to flow freely and often. Questions and problems will come up at every stage of development, and many of them will be unforeseen and impossible to plan for ahead of time. As the scope of the project inevitably grows and evolves, team members should have a sounding board when they hit a snag or need to course correct.
Encourage and make it as easy as possible for designers and developers to talk to each other throughout the duration of the project so that they’re collaborating rather than piggybacking off of each other.
Designate Designer/Developer Pairs
Designers and developers obviously have different skillsets and even agendas when it comes to building an app or product, but nothing will derail a project faster than a “stay in your lane” mentality.
Pairing designers and developers when appropriate can solve a number of technical and practical problems. Designers can’t be expected to have a working knowledge of back-end programming languages, but it can be beneficial for developers and designers to have a better understanding of the other’s perspectives and challenges.
A great place to start is by asking questions.
Questions Every Designer Should Consider Asking Their Developers
- How long will this take to build?
- How will a particular design element or layout affect the site’s responsiveness and mobile compatibility?
- What are the security requirements and concerns?
- Is this possible and/or practical to build?
- Can we make edits/changes as needed once the prototype is built?
This is where empathy, one of the most important (but underrated) factors of successful communication and collaboration, comes in. Something that may seem simple and completely obvious from a design perspective can seem nonsensical from the developer’s perspective.
Connecting the dots between the two camps requires insight into how the other thinks and the actual work involved in bringing an idea to fruition in a way that actually works for the end user.
Truthfully, remote work isn’t really about what apps you use, or how organized you are. While those things certainly help, the real secret sauce is encouraging empathy and teamwork and removing as much tension from the process as possible.
That begins with getting your developers (and designers) to step into each other’s shoes.
How Developers Can Think Like Designers
Without insight into how or why designers make specific choices, developers can feel disconnected from the design process. While understanding the intricacies of user behavior and motivation may not necessarily be a developer’s problem or area of expertise, a general understanding of what goes into the design process can help developers and designers talk to each other more efficiently.
Some of the most common pain points between developers and designers include:
Taking the design team’s technical grounding and expertise for granted. This goes both ways (and can backfire); assuming the design team knows much more or much less than they actually do about the technical scope of the project.
Shutting down discussion on technical grounds. Developers may know when something can’t be done, but they still have to explain why. Taking a collaborative approach over an adversarial one (“I know more about this than you do,” for example) is always advisable when working on a team with people from different disciplines.
Sometimes a design request is counterproductive to the project. Explaining why in practical terms, rather than just shutting something down without discussion, will keep everyone motivated and on the same side.
Some examples of productive and actionable talking points include:
- It would be too expensive or time-consuming to build
- It would slow down the app or site and hinder productivity
- It’s bad for product visibility
- It’s a security issue
- It’s technically impossible
Designers often think abstractly and work with ideas; developers have to deal with the nuts and bolts. Helping to manage each other’s expectations along the way makes it easier for people to work together and stay productive.
Develop a Clear and Transparent Workflow
Even modest projects tend to take on a life of their own once they get off the ground, often in ways that can be impossible for anyone on the team to predict ahead of time. Clients change their minds, key people leave midway through a build, budgets shrink, and things take longer and are more expensive to complete than anyone involved in the project could have anticipated.
Designers and developers often have to make do and adjust to factors and circumstances beyond their control, sometimes at critical points in the life of a project. Teams become (and stay) more productive when roles and expectations are well defined, people know what is and isn’t expected of them, and everyone feels they have the support and resources they need to be successful.
Roles and deliverables may change and evolve depending on the scope of the project, but some of the factors that can help keep the workflow moving and the various teams engaged include:
- Accountability (on a team and individual level)
- Clear and well-defined team structures
- Clear priorities
Not only do uncertainty and poorly defined roles and workflows affect productivity, they can create resentment between teams and individuals, especially for the teams “working in the trenches” who are usually far removed or even cut off from the decision making process when it comes to the overall direction of a project.
Establish a pipeline early that keeps everyone working on the project connected. It’ll make it easier to pivot and manage crises as they develop.
Once again, the right tools help here: we’ve written about our favorite project management tools in the past, and in a remote environment, you’re going to be leaning on them even more.
“Plan” for Chaos
Remember that when folks are working remote, things can go off the rails fast. If you can’t maintain solid channels of communication, tiny mistakes can quickly add up and derail a project. Things like weekly check-ins can help prevent this — but ultimately, the best solution is a team that’s constantly checking in with each other throughout the process.
Practical Tips to Help Designers and Developers Stay Connected
Even with an endless supply of productivity and communication tools at their disposal, even small teams can fall victim to information overload, competing agendas and priorities, and practical considerations, like time zone differences.
We’ve harped on the importance of communication throughout this guide, but “communication is important” shouldn’t translate into “let’s have constant meetings about everything.” Meeting fatigue is real, and if you aren’t giving your teams actionable items during a meeting, then there’s a good chance you shouldn’t have had the meeting in the first place.
Here’s how to prevent “communication” from devolving into an annoyance for your team.
Tools for Cross Channel Communication
Daily/weekly/quarterly roundups: the frequency may vary depending on project needs, but keeping developers and designers in the loop about the overall scope of the project can minimize a lot of confusion and “turf” disputes.
Some information will inevitably be “need to know” and no one wants to be bombarded with superfluous information, but a “highlights reel” whether it’s a quick email, an internal blog post, or a full blown newsletter can get everyone on the same page.
Videos: designers and developers may not have the time or opportunity to “sit together” and collaborate on every aspect of a project, but anyone can watch a video.
Whether it’s a quick explainer discussing workflow issues, user research, or simplifying a complicated technical concept, videos offer easy and low impact ways to exchange information quickly and efficiently.
Set up “office hours” or an AMA: Setting aside a dedicated window of time for developers and designers to talk to each other in a low-pressure setting can take a lot of the mystery out of the process, and prevent silos from forming or becoming too entrenched.
Every team and project is different, so a little creativity and resourcefulness will go a long way. The main goal is to create an environment where people feel comfortable and supported enough to speak up and communicate with each other, especially when things don’t go as expected.
Create a Mobile App Prototype
Of course, we’d be remiss if we left ourselves out. Our prototyping software takes a lot of the pain and guesswork out of creating your own app. A fully functional prototype can help you seamlessly transition from the design phase to the development phase. It’s perfect for helping developers and designers work better together remotely. To help get you started, we offer a 15-day full-featured free trial. Sign up and get your next project moving in a snap!
How do you encourage your mobile app designers and developers to work better together? Let us know by tweeting us @Protoio!