What good are our user personas, scenarios, and cute wireframes if they fail to look half as nice in production?
Where UX work is done in isolation and passed on to a development team to implement, it most likely will end up in a drain for both parties. Many developers would frown at the introduction of a design process into their workflow, as they see such as a drag that would make them do extra work or even multiple re-works. This doesn’t always have to be so.
User experience designers own product definitions, and they help teams define and refine roadmaps for products based on user needs. To actualize the goal of bringing to fruition, products that users really want, designers and developers need to collaborate seamlessly.
Empathize or Systemize?
Developers tend to systemize rather than empathize. They are logical, left-brainers who find it hard to see the emotional/demonstrative side of things whilst designers are creative, flexible, right-brainers who show a greater concern about end users reception to design decisions.
These days, the web design process isn’t as linear as it used to be. Roles overlap and an openness to iterate frequently means that deliverables move forwards, backwards, diagonally and sideways during the life cycle of a project. In order to keep up with this, a team must communicate early and continue to communicate often. Essentially, the people in a team need to work cohesively throughout the duration of the project instead of siloing themselves in their assigned roles. — Kylie Timpani
Have key discussions
It would do no good if a UX Designer takes up the brief, disappears and then comes back with a polished UI after 2 weeks.
As a designer, before creating a new artboard in Sketch, ask your developer or development team these questions, they will help you create a base on which we you can make UX happen as a team:
- What hand-off tools are we using? From Avocode, to Supernova, to HTML/CSS, there exists tens of hand-off tools and techniques out there. Ensure you are on the same page with the developer on the most preferred tool to use, based on project needs and teams strengths. This will create a lot of ease during production.
- What asset management strategy are we using? Tools like Zeplin, Marvel e.t.c have hand-off features that support asset management, however they present developers with different file formats (PNG, SVG, JPG e.t.c) and file dimensions (1x, 4x e.t.c). Having the clarity on which way to go from the onset will save a lot of frustration.
- Is there a particular file-naming convention? Many hand off tools out there do not do a good job of auto-generating class names from design layers. Relying on them to cater for naming protocols will end in frustration, especially on the part of the developers. Having this discussion early will guide both parties during implementation.
- Are there design/technology constraints based on the frameworks/libraries we are using? If we have ever had to work with a developer in building a pixel-perfect Android app, we will understand that having an in-depth comprehension of Android components and/or Material Design will reduce a lot of rework. For instance, the Material design guideline has a pre-defined responsive grid layout, same goes for the Bootstrap 4. Creating our Sketch artboards based on these grids will save a lot of headache for the developer during implementation. Also, we might need to check what font icons come prebuilt with each framework, what default components e.t.c
- How do we show states, micro-interactions or animations? Interaction design and states are highly inseparable. How do we then show these to the developer without having to explain verbally all the time? This discussion is best had with the developer in the early stages of production, as each developer has his/her own unique approach. Some work with static UI’s with brief explanations of when and what happens. In the past I have used Lottie to create micro-interactions and animations for developers, and it was such a breeze. I highly recommend it.
While collaborating with Iyk Azorji on a music composer app, these 5 tips proved effective as we reduced production time by half while creating a product that was very close to the UI in terms of look and feel.
Designers and developers have struggled to co-exist, creating a pain point for the product team, stakeholders and clients. However we would be surprised at how having these key conversations early on can positively impact not just on their co-existence and productivity, but also on the product outcomes.