large_Crossover Series NFTs.png

medium_Crossover Series NFTs.png

small_Crossover Series NFTs.png

thumbnail_Crossover Series NFTs.png

From Photography to NFT Art: Twisted Digital Landscapes with Nate Hill

From Design System to ‘NFT Design System’: Creating TinyFaces

Neurodiversity and Inclusion: Choosing Kinder Design

medium_652ccf22c8853584bde5553986a4eed0.png

small_652ccf22c8853584bde5553986a4eed0.png

thumbnail_652ccf22c8853584bde5553986a4eed0.png

Web5 is here. Goodbye Web3? TBD.

<a href="https://uxdesign.cc/addressing-the-handover-3f874e1e96d4?source=rss----138adf9c44c---4">uxdesign.cc &ndash; User Experience Design &mdash; Medium</a> | Jonny Gibson <img alt="" src="https://cdn-images-1.medium.com/max/1024/1*ALjCCtBzkfO5LmEucRFDng.jpeg">
<h4>Shaping a better environment of collaboration and success within digital projects and teams.</h4>
I don’t like the word handover.
In design circles it implies the end of involvement for one group and the start for another. Designers will create a suite of assets, whether it’s a style guide or page designs, and then hand those over to a developer to be coded.
The designer dusts his hands and moves onto the next task, while the developer gets the design equivalent of a bucket of cold water to the face and is told to get cracking. For some reason, we expect developers to see all the countless micro-decisions the designer has made, understand the designer’s intent, and execute in accordance with it — even when the delivered files have unintentional discrepancies… (sorry designers, but you know it’s true).
This traditional waterfall process is still ever present, and common amongst a lot of digital agencies. It’s another hangover from the old creative agency model. But even the often lauded agile method has limitations, and doesn’t solve the issue of asset handover and collaboration. Not fully.
The main problem is that there is a gap between those who do the thinking and those who are responsible for the doing. We’re not really working as a team.
Typically, there might be a group of strategists, responsible for setting up the vision or proposition for a project or product. Then there are designers who ideate concepts for an interface or design aesthetic. Then we have the developers who are responsible for bringing all of the above to fruition. Projects will often work their way through teams in this manner and in this order. It’s rare that you find a developer involved in the ideation process, rarer still to find them included in the strategic thinking.
This is not how good teams work.
The most effective teams have a shared understanding, language and goal. Sports teams are a great example of this. They can only be successful when they work together.
They communicate often and openly, spending time getting to know how the other thinks and plays so that they can facilitate better for one another. They have a single purpose, and work together using each other’s individual skills to achieve a common goal — without a big handover. They are in-sync.
Project teams are no different. We all have a common goal of creating a successful, useable and beautiful product for our client and the real people that use it, in the least stressful way possible. To do this we need to be inclusive, contributing to the entire project cycle through the lens of our individual disciplines. Only when we collaborate in this way will we be truly efficient and successful. This collaborative culture spells the beginning of the end for the unhelpful handover.
The first step to greater collaboration across disciplines is understanding. It’s no longer viable for disciplines to be specialised in execution at the expense of understanding each other’s craft.
I’m not saying that teams should be multi-disciplined in execution, in fact people who heavily differentiate their skills usually end up with one of them suffering as a result (jack of all trades, master of none). But like any great sports team, we need to have a clear understanding of how each other works and what we need from one another in order to do the best work we can.
Fortunately, there are some simple steps that can help steer your project team in the right direction.
<h3>Encourage consultation early and often</h3>
It’s not possible to know all the details of all the disciplines within an agency, there are nuances and subtleties, rules and learnings that those practitioners have spent their careers mastering. Trying to master them all is foolish, as is failing to acknowledge this fact. Attempting to focus purely on your own craft is inefficient and selfish.
Your work alone won’t make a product great. Learning how to collaborate and leverage each other’s knowledge is the path to real success.
In reality, this means outlining plans or ideas with the wider execution team, at the time. This helps to validate or discredit things early and avoids wasted effort later, when it’s too late. It also gets the ball rolling in the minds of those who will execute later on. Ideas may start to surface, thoughts or concerns may come to mind over time, rather than at a point down the line where there is no time for that kind of input.
Input from the doers can also help to build objectives, timelines, and backlog items that work for everybody, rather than assuming a set of objectives or a specific way of working that causes extra work for certain disciplines later on.
<h3>Communicating the intent — Principles are better than processes</h3>
Involving all the doers in the thinking work, or at least explaining the theory and strategy (in an accessible way) will give your team a massive advantage. In the traditional handover method, a developer may have 6–8 weeks worth of thinking, subject matter and work to onboard themselves with and understand. That’s untenable. The result is usually that this stuff is ignored in favour of executing to their best understanding.
We can alleviate some of this by sharing the thinking, the intent, or the knowledge of the subject as you go through it. It doesn’t have to be laboured. It doesn’t have to go into the same level of detail, but it does allow the developer to have a much more holistic understanding when the actionable tasks land in their inbox. It allows them to make better decisions, because they have a better understanding of the desired goal, or knowledge of some of the client’s central desires or interests.
When was the last time you saw a developer invited to sit in and observe a session of user testing? Hearing the user feedback, and being part of the solution discussions? This insight and information is invaluable to a designer as it helps them make decisions. The same is true for developers. Having exposure to the issues, and being part of crafting a solution, may be invaluable later as it helps them to prioritise and understand “what’s important about this, and what part of it do I need to focus my attention on”.
Creating a set of overarching principles as you strategise and design can help to establish themes and guidelines that steer decision making, where there may be a lack of clarity. This is beneficial to both designers and developers. Make sure these are communicated, and more importantly, understood by all disciplines involved.
<h3>Get to know each other</h3>
Having an understanding of how each member of each discipline works and thinks, helps you to plan your deliverables, catch ups, process and communication channels better. All of which lead to a more efficient project, with more satisfied and fulfilled team members.
Avoid generalisations about what each other does, or what each other wants. Communicate openly and often, ask each other for advice! It’s not a sign of weakness or a lack of superiority if you don’t know the finer details of things, even within your own craft. Assuming you do is what stops you from learning and improving. Even when not resourced, you’d be amazed how many designers and developers would gladly find time to answer a question, or sense check an idea, if it means their life will be less stressful later on.
Work, skills and disciplines aside it also helps to actually get to know each other, on a personal level. You may be surprised by the backstory, passions and skill sets of the individual — which often go far beyond the specific role they’re hired to do.
Really listen to each other. Being clear and open about your agenda and motivations as well as listening to and understanding the motivations of your teammates will help you communicate more effectively, and helps to avoid pain points, misunderstanding and frustration at one another.
In practice, it’s impossible to completely remove handovers. Individuals and disciplines will always have an element of isolation and remote work. What’s important is to try and remove the cultural idea of the handover. The concept that one person’s job is done and another is just beginning.
This is not how teams work, we are all a part of the success and all a part of the failures. If one person is struggling, it’s our responsibility to help — perhaps we should have considered what resources we supplied? Did we take the time to explain our ideas and goals in a way that they can understand?
Building project teams who consider one another, work together and leverage each other’s strengths will not only make you more efficient and profitable, it will create a culture of support, togetherness and unity.
Wouldn’t we all like to be a part of that.
<iframe src="https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fupscri.be%2F50d69a%3Fas_embed%3Dtrue&amp;url=https%3A%2F%2Fupscri.be%2F50d69a%2F&#038;image=https%3A%2F%2Fe.enpose.co%2F%3Fkey%3DdRXnS9Gplk%26w%3D700%26h%3D425%26url%3Dhttps%253A%252F%252Fupscri.be%252F50d69a%252F%253Fenpose&amp;key=d04bfffea46d4aeda930ec88cc64b87c&amp;type=text%2Fhtml&amp;schema=upscri" width="800" height="400" frameborder="0"><a href="https://medium.com/media/05d5fd32eda31cbd1b83287606744532/href">https://medium.com/media/05d5fd32eda31cbd1b83287606744532/href</a></iframe><img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=3f874e1e96d4" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou">
<hr>
<a href="https://uxdesign.cc/addressing-the-handover-3f874e1e96d4">Addressing the Handover</a> was originally published in <a href="https://uxdesign.cc">uxdesign.cc</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Addressing the Handover

Addressing the Handover

Shaping a better environment of collaboration and success within digital projects and teams.

Top Stories