Our team’s transition to design-driven development
The struggle is real.
When I started working at Nexu there were only 3 other programmers in the team: a Full-Stack, a Front-End, and a Back-End developer. Pretty much all you could need for launching and maintaining Web Apps and Backend services. But as the company grew, that became insufficient. At that time at #NexuDev, everybody worked on everything just like every startup. Nowadays we’re 3 developers and 2 designers. In this post I’ll talk about how important were the designers we added to our team and the obstacles we faced and continue facing.
In the beginning…
As I mentioned before, we were 4 developers in total. Everyone with its own strengths and weaknesses. But none of us were designers and only knew basic UX/UI concepts.
We work in 2-week sprints. The Scrum Master prepared the planning for the developers and we started programming new features ASAP. However, there was always a requirement called “Details from last Sprint”. At first it didn’t bother me. All the team’s unfinished details went to this requirement. I mean, it’s not that bad, these were just details that arrived during the sprint review. As weeks passed, a clear pattern appeared: all these details were tasks involving Front-End changes. Things like: change the button color, change phrasing, changes in the sidebar, design not suitable for mobiles, move textbox to the left, and so on. I’m pretty sure most development teams can relate to this.
The reason of all was that at the moment of reviewing our work, the product owner always had comments about design, I mean always. To be honest, it was mostly because the product owner didn’t give any feedback during the two weeks and, at the Review meeting, it was the first time he saw the product. So we decided to implement something we called “continuous feedback”. It basically meant to go and ask the product owner his thoughts in every change and decision we made. Can you spot the problem? We were not only throwing away the benefits of SCRUM at having zero independence, we were wasting time daily in 5 to 30 minutes meetings about design decisions, only if the product owner was available, otherwise we’d had to delay our work and do something else until the product owner was available.
Spoiler alert: we still had our “Details from las Sprint” story.
A new hope…
Even after all our work and effort in “continuous feedback” during the sprint, we knew that we needed someone to guide and be responsible for UX/UI. Our Web Apps worked and it was fine, but we are not our users and we didn’t know what their needs were. After our first UX tests unveiled some new insights about the website, we gave ourselves the task to find someone that could fulfill our needs and solve some of our problems. So we added a new member to the team: a UI designer.
I’ll be lying if I’d say that everything went smoothly. First of all, how do you integrate the design process to SCRUM?
Scrum and design. As sprints passed by (sprints, because they are time-measure units) the designer moved his tasks only through the “Doing” and “Reviewing” board. Obviously, she didn’t have anything in the “Deploy” part of our board. And what does “Done” mean? Does it meant that his design was finally going to be implemented? Or that it was going to be seen finally by our clients? To be honest, the organization hasn’t change a lot. But now the only ones who finish their sprint requirements are the designers.
Design first. As we started working the first problem showed up: we needed the design before starting programming. Otherwise, we’d have to wait for the designer to have all the changes and feedback, and that was time consuming. Hence the first change was that the design had to be done a sprint before we started working on new features.
Listening and Communication. I’ll dare you to go and say to a programmer to his face that he’s wrong, I double dare you. Change is not easy, but communication is key. Each part had his own troubles adapting. For one side, when the designer came up with an idea he immediately got shot down because an aspect of the design wasn’t plausible given the current state of the App (you know, things regarding database, information given by the endpoints of our Back-End, and so). Hence, he’ll have to redesign continuously.
In the other hand, sticking to the exact design is not easy. The font, the font-size, the color, the size, the image looks good in mobile but does not in desktop, the transitions, the space between elements, etc. At first, the only thing we got to make a design change was an image, and you had to figure out everything by yourself from a static file, obviously the resulting product was different from the design. We decided to implement style guidelines available for everyone to see and consult if needed. Sticking to those guidelines is another story.
Improvise, Adapt, Overcome.
Things are now easier. But we still have a long way to have a truly design-driven development.
Because of the actions we took, we have eliminated the unspeakable “Details from last Sprint” requirement considerably. The design has to be approved before we start to work on it, and minimal changes appear at the Review meeting.
We brought UX designer to the team. Her addition involves new challenges for everyone. But, personally, I think our whole process has become more robust and has improved significantly. We’re a really close team and everyone gives feedback on everything. Some times we invest a lot of time in constructive feedback, but step-by-step it has become easier for all of us, resulting in an increased quality on everyone’s deliverables.
Designers and Developers are two sides of the same coin. We have a lot of differences but also a lot of similarities. Each one with their own strengths and weaknesses.
Working side by side is not easy but it’s for the best. Just the “creative process” for each part widely differs. For one side, us developers prefer silence, we get immerse in our own thinking and we only talk to each other when it’s utterly necessary. On the other hand, the design team is always louder, talking, sharing ideas, listening to distracting music, and so on. Implementing a design-driven development has been bumpy and enjoyable journey that is now producing great results and learnings for everyone.
I hope you enjoyed reading this post. If you’re interested in being a part of #NexuDev please visit our Careers site.
