[#]: subject: "5 open ways to help UX designers and developers collaborate better" [#]: via: "https://opensource.com/article/23/4/designers-developers-collaborate" [#]: author: "Katie Riker https://opensource.com/users/kriker" [#]: collector: "lkxed" [#]: translator: " " [#]: reviewer: " " [#]: publisher: " " [#]: url: " " 5 open ways to help UX designers and developers collaborate better ====== Ideally, designers have a good relationship with their product team and users. However, the relationship between designers and developers is more difficult to build and maintain. The lack of a close relationship makes it difficult to solve problems or improve. In my experience, the open source [Open Decision Framework][1] can overcome many of these obstacles. The Open Decision Framework asserts that [open decision-making][2] is transparent, inclusive, and customer-centric. It involves clearly sharing problems, requirements, and constraints with affected parties. It enables collaboration with multiple stakeholders to secure diverse opinions and comprehensive feedback. Most importantly, it manages relationships and expectations across competing needs and priorities. These principles probably resonate with anyone involved in the many decisions around designing a product, feature, or service. For a designer, developers are key stakeholders in making the best design decisions. If you're a designer, it's time to embrace the opportunity to get diverse opinions. ### The backend and the user experience Developers are key stakeholders because a user's product or service experience is more than just the pixels on the screen or the workflow designs. It encompasses the service's performance, the speediness of [API][3] calls, the way user data is treated, and even the design of the data for scalability. When they're considered full stakeholders in the design, developers can contribute their expertise on the backend and architecture of services to assist the overall design of the experience. A user experience (UX) designer is a stakeholder for the items the dev team is responsible for. A performance deficit, or the effects of an architecture on what data is available, can hinder the user experience. An open, [collaborative relationship between dev and design][4] allows for trust and transparency in all areas. ### Make space for collaboration An open and transparent relationship between developers and design is not as common as it should be. This way of working may be new to both sides. Here are my top five tips for making collaboration a success: - **Designers**: A coding foundations course, such as the open source [Odin Project][5], can be helpful for learning the fundamentals of how a service is constructed and built. - **Developers**: An understanding of UX principles can help guide questions and feedback. You can find a good overview at UX design principles or in various books and articles. - **Set up a recurring time to collaborate**: Establish a recurring time for design and development to meet between once a week and once a month. The invitation should at least include UX, lead engineering, and quality engineering. Ideally, all developers on the team should be invited to attend as schedules permit. - **Make sharing the main agenda:** UX should share the current use cases and features they are working on, along with any relevant user research data. UX designers should demonstrate workflow designs, wireframes, and high-fidelity mockups to the development team. Development should share any design decisions made on their side that may affect how the user experience works. - **Encourage questions:** Collaboration is the ideal scenario. Encourage all attendees to ask questions and give feedback. Answers to questions and responses to feedback are opportunities to discuss design and direction, as well as a chance to learn from one another. - **Embrace a learning mindset**: Avoid lecturing or "telling." Instead, aim to learn from each other. Use mutual expertise to design and build a great experience for users and customers. Ask for explanations of unfamiliar technology or concepts. - **Consider formal learning**: A collaborative relationship can be easier when groups speak the same language. Consider formal learning paths, such as: ### An example of open collaboration In an early design review with a developer on my team, I showed a specific interaction for displaying more data about an object. I communicated the user's need and demonstrated the interaction when the developer asked, "Does it need to be done in exactly this way?" He mentioned that with a few minor design changes, the effort to develop it would be significantly lower. We agreed that the changes would not negatively affect the user experience, and the user would still be able to achieve their goals. This feedback saved the development team time, leaving more opportunity to address bugs, build additional features, and preserve a healthy work-life balance. The user experience remained strong, and the team was even stronger. This result would not have been possible without the early feedback from a developer with whom I had a strong working relationship. ### Your next steps Creating an experience is a series of decisions made by a collaborative team. Product, design, and development need to work together as experts in their respective fields and stakeholders in the others. I encourage you to engage development and design for more collaborative feedback and work together to create the best product with the best user experience. -------------------------------------------------------------------------------- via: https://opensource.com/article/23/4/designers-developers-collaborate 作者：[Katie Riker][a] 选题：[lkxed][b] 译者：[译者ID](https://github.com/译者ID) 校对：[校对者ID](https://github.com/校对者ID) 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 [a]: https://opensource.com/users/kriker [b]: https://github.com/lkxed/ [1]: https://opensource.com/open-organization/resources/open-decision-framework [2]: https://opensource.com/open-organization/20/6/open-management-practices [3]: https://www.redhat.com/en/topics/api/what-are-application-programming-interfaces?intcmp=7013a000002qLH8AAM [4]: https://www.redhat.com/architect/keycloak-ui-architecture?intcmp=7013a000002qLH8AAM [5]: https://www.theodinproject.com/