If you've been working in product development, web development, web design or most other areas where designers and developer work together, you've probably seen or heard at least one of the following (or something similar to it):
From the designers:
“We came up with a really beautiful design, but the developers really mucked things up. It's nowhere near what we designed.”
“How can we create a beautiful design if the developers will just screw it up?”
And from the developers:
“This design is impossible to replicate in HTML/CSS, this is as close as we can get.”
“Designing in Photoshop is easy, you don't have any limitations imposed by code. We can't fit this design into the development framework we are using”
Although you'll frequently hear comments such as the above, in my eyes, they're stemming from two main problems
- A lack of good tools / communication frameworks in place leading to …
- …a serious breakdown of communication between the designers and developers
In reality, designers and developers are very different from each other. Designers are right-brained, developers are left-brained. Those who think creatively need to establish a way to communicate correctly with those who think rationally / logically.
A way which works well for both.
The communication problem is made that much harder in today's environments, where remote working, different geographies, cultures, and languages, different timezones are all business-as-usual.
Having designers in one country and developers in another is the order of the day.
But designers and developers need each other. They need to communicate well if you want to create a good end product.
Start dating before living together
So, let's think of the developer-designer as a relationship.
Partners in a relationship need to understand what works (and what doesn't) for both of them before they can make more serious commitments.
The key to a good end-result: developers and designers need to start working together from the get-go.
Simply put, if a designer creates a design without the involvement of a developer, they're bound to have to go back to the drawing board often and get frustrated that their work as been ‘destroyed by the developer”.
If a developer is given a design which they had no involvement in, they're going to say that this design is impossible to implement and will have a hard time achieving the required end-result.
To create a design that works the developer should be present during the design brief to make sure that things are designed to an appropriate developer specification.
The following questions (and no doubt others) need to be figured out during the design brief and require input from both the developer and the designer.
- What responsive framework (grid) system will be used to implement the design?
- Are there any design elements which cannot be implemented using the selected framework?
- Which elements can afford to be hidden at smaller screen sizes and what will that look like?
- What text styles and fonts sizings are to be used?
- Create actual videos or specifications of micro-animations to be used.
- What imagery will be used and what kind of cropping will happen on smaller screens?
This is an exercise which needs to be done internally by your team. Figure out where you communication breakdowns are happening and then develop a set of questions which need to be fully specced (from the designer to the developer).
In essence, your designers and developer need to ‘date” such that they both understand each other, before actually committing to a design which needs to be developed.
As the design is being created, the developers should get involved frequently, such that potential development problems are identified early and resolved during the actual design.
Now that we've defined the theory, let's actually show you the tools we actually use to improve our communications between designers and developers.
How to get designers and developers to start working together
1. Use a constant communication process
Continuing with the need to have constant communication, you should implement SCRUM or another agile methodology.
Agile methodologies like Scrum emphasise the need for constant communication. All stakeholders agree on what is going to be built and they meet regularly to ensure everything is being developed to specifications.
We're not going to recommend or go deeply into the methodology to use, but, one thing is surely necessary.
Develop a process of constant communication.
For example, in Scrum, you have Daily Scrum 10 minute meetings which are meant to show the progress of the previous day and set a path for the current day. Any issues will be identified immediately and resolved separately from the daily meeting.
The Sprint Review – usually when a sprint is complete is a milestone – where both the developer and designer can actually see that progress on the design/development is according to the original vision.
By having both the designers and developers in constant communication, problems are identified and resolved quickly, before they get out of hand.
2. Use a good mockup tool
While PSDs are going to be necessary for the development, you won't be needing pixel-perfect designs for each and every screen in your project.
When the basic designs have been developed in Photoshop, you can then hurry things along with a good mockup tool.
Now, let's make one thing clear, mockup tools may be used by designers, but they're more likely to be used by your UX guys and developers. The favorite tool of choice for designers is an actual design tool, not a mockup tool.
Your mockup tool should be used as a bridge, between the people designing the requirements, the developers and the designers.
One thing to keep in mind - let everybody use their own favorite tool, don't force anything down anybody's throat.
Let the designers use their favorite design tool, Photoshop or whatever they prefer. Let the UX designers, the product managers, the business analysts use their favorite tool (typically a mockup tool). And then let the developers do their thing with whatever they want.
As long as there is a good line of communication, the tool they use is not very important.
Balsamiq
[caption id="attachment_153147" align="aligncenter" width="947"]
There are plenty of good tools out there, but the one we absolutely favor by far is Balsamiq.
Balsamiq has a full library of components and design elements which can be used to quickly create screens which need to be sent to the developers for implementation.
Balsamiq is available both as a desktop application for Mac or Windows and a cloud-based service.
UXPin
[caption id="attachment_153148" align="aligncenter" width="1200"]
If you're looking for a cloud-based service which is pretty much good for mocking up any design, UXPin has all of your bases covered.
Again, based on a comprehensive library of elements, you can web designs, Android or iOS apps, Bootstrap based screens, Material Designs, interactive UIs or micro-animations. It's as comprehensive a tool as it can get.
Moqups
[caption id="attachment_153145" align="aligncenter" width="1200"]
Whilst my preference is still with Balsamiq because, honestly, I like my mockups be just that - mockups, rather than near pixel-perfect designs, Moqups is another great wireframe tool.
With Moqups, you can create very high-fidelity mockups. Using the extensive libraries available within the tool, just like UXPin, you can go into quite a lot of detail into the design of your actual mockups.
3. Manage your project + tasks
Once your designers, developers and all the stakeholders have agreed on a way forward, it's time to actually start doing the work. When your start the actual job, job management software is great for quoting, time-tracking, billing and all the essentials of tracking your job.
Besides the actual job management (the easy part), you need to manage your project and the work which needs to be done.
It's during the actual project work where the problems often start to crop up, so there another few things which are critical to the success of a project.
First of all, each project must be broken into its parts and each step must be monitored for completion.
Secondly, your management tool of choice must be a single point of contact.
The biggest headache you can get is having ‘decisions” spread over multiple means of communication, email, Slack, your project management tool, face-to-face communication, phone calls. Always make sure that decisions taken anywhere all eventually end up in noted ‘in writing” on your project management tool.
Project Management Tools: Asana, Basecamp, and Trello
Ok, so rather than waste your time going through all of the most popular project management tools out there, I've bundled them all up into a single paragraph. Diving deeply into any of these specific tools has been done to death, so we'll leave this up to you to decide which tool is best for you.
All of the above tools have their strengths and drawbacks – it's a question of choice.
I've used all of them to varying degrees and all of them work well as long as you apply them well to the problem at hand.
Continue reading %6 Tools to Stop Your Devs and Designers Strangling Each Other%
by David Attard via SitePoint
No comments:
Post a Comment