There was a recent conversation in the UX Community on Slack Designer Hangout about getting developers to follow wireframes from a UX team. I've seen this question, and struggles come up hundreds of times in the last couple years.
{img}
My ux team recently has been dealing with front-end developers deciding that they are designers & that ux wireframes are just a loose guideline. It’s been frustrating, because the development ends up having a lot of ux & usability issues. Our front-end devs are not focused on the user but instead what they prefer. I’m wondering if anyone has had experience integrating developers into the design process. Has it helped prevent issues like these?
Thankfully we've got lots of active and helpful users. Overwhelmingly the answer given was some form of "Involve the devs in the process sooner rather than later."
{img - @briancrumley}
... gives more of a sense of ownership over the project as a whole instead of feeling like the last phase of a long established process
{img - @birdsong}
... I try to include the development team in all design reviews, so their concerns can be heard, their input accepted, and their buy-in to design decisions pre-determined.
{img - @gene}
Definitely talk to them to find out the reason why they didn’t follow the wires, sometimes there are good reasons ...
The basic principle that everyone is trying to get across here is that a silo'd work environment tends to create more problems than benefits. In an ideal world your teams will work closely together and all of the stakeholders (anyone responsible for the end product) are involved in the entire process from start to finish.
When working in a silo'd environment it's all to common and easy to fall into the "not my problem" mentality. A strategist comes up with the ideas, a designer creates wireframes or mockups, and a developer is responsible for executing the design in a way that fulfills the users and business' needs. The problem with this team dynamic is that it's very linear in practice and doesn't allow for quick pivoting or taking contraints into consideration early on in the process.
A strategist or designer is not expected to fully comprehend the constraints of a codebase or specific framework. Because of this their ideas and designs may be beyond the scope of capability. With the traditional silo'd waterfall approach these issues don't come to light until the "final" designs reach a developer; typically after they've already gotten client sign-off, when it's too late to make any large changes. This often results in a lot of internal turmoil, and ultimately a lesser product; for both the end-user and the business.
There is also the issue of silo'd teams with seperate leaderships and goals. A UX team may be focused on creating the best experience for the user. A Design team may be focused on creating beautiful and "innovative" designs. A Development team may be focused on code quality, accessibility, and performance. If these goals do not align you end up with frustration on all sides and no one taking blame because the "other" team(s) weren't moving towards the same goals.
Unfortunately there is to one-size-fits-all solution to the problem. The truth is that solving the problem is hard work. The only way to solve these problems is communication. Communicating about potential issues with the design. Communicating about each teams seperate goals and how to align them. Communicating about pain-points each team has and how to resolve them.
The best way to solve existing issues is to sit down and have a conversation, it's not pretty, it's not an app, it's people. People are messy, people have different opinions, people are responsible for the work you're company puts out. It has to be the people who want to make things better. A client isn't going to pay you to figure out your process; you can't put a conversation in a portfolio, but these things are going to make your team more productive. A happy team is a productive team. If your teams work together, if there's a real bond between employees there is a noticable boost in moral and a noticable boon in the quality of work being put out.
People don't put in long hours for a salaried paycheck. People put in long hours to help and support the people around them. The put in the hard work and the long hours because they believe in the work they're doing.
Special thanks to Designer Hangout users @gene, @birdsong, @briancrumley, and @bridgetecohen