Not Involving Developers in Design

via GIPHY

This seems to happen at every company to some degree or another. The company I remember the most for it was a company in the personal credit score space. There, I worked with two other developers on the company’s universal application. It was very much a “watergile” company. By that I mean that they acted like they were agile by having daily stand-ups, but everything else was a waterfall process. We would just have designs show up in our inbox one day, and that was the way we had to make the application. Even when we went through them and offered suggestions that would improve usability, they were ignored because changes to the designs just took too long to make happen.

One specific example I remember was a simple selection screen. As we were building the application, we agreed as a development team that we would not custom-implement anything that could be done with a standard component to basically complete features in a more minimally viable product (MVP) type way. Designs for this selection screen asked for a radio button that were filled in to denote which option was selected. A native implementation would utilize the checkmark functionality of table views to display this information. It took me about an hour to code, and I moved on to another task.

About a week later, we received a defect report saying the selection screen wasn’t as designed. I took the idea to our UX designer, and she agreed that checkmarks were the way to go. She also said she would deal with it, and said not to worry about it for now. Another week went by, and the defect was back. I was forced to create completely non-standard radio selection buttons. The new implementation took about a week to solidify because of the nuances of managing the selections and updating the images when arriving at the screen from different flows.

Oh man, I don’t know how many times have I come to a user story and just said in my head “this isn’t standard at all and would take a month to create”. First and foremost, there should always be designs created by the time a developer is ready to start coding. However, they should be very loose and expected that they will change over time. This is one of the twelve principles of the agile methodology:

“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

Creating a design with a sticker that says “this is how it has to be” is the perfect way to increase development time and guarantee the project doesn’t deliver.

Designers do not know all the nuances of development, and developers do not know all the nuances of design. But together they make a very formidable team. Developers bring very valuable insight to the design process that can drastically improve timelines and ease design headaches. Imagine the cost of the scenario above. With all the people involved, and the timeline it took, it was a $15,000 change that turned out to be a poor user experience. It could have all been avoided if a developer was involved in the process of the design.