Pull requests for the designer: How to improve the development process
At Luminis we see user experience and usability as crucial factors in developing successful mobile and web apps. We are always looking for ways to improve the way we as a team collaborate and work towards delivering those great applications. One of those improvements is putting the designer into the technical workflow of the developers.
Our approach
In short, our approach goes something like this. After the product definition phase, the designer starts creating the various screens and interactions to accommodate the use cases as described on the backlog. This is done in collaboration with the Product Owner (PO) and the development team. In doing so, we design the right solution (checked by PO) and the design is implementable (checked by the developers).
When the designs are done, the development team can still involve the designer for assistance during implementation, sometimes resulting in updated designs. This flexibility and close contact helps us as a team to implement the best possible solution within 1 sprint.
The problem
This close contact between the PO, the designer and the developers makes us agile and helps us to quickly catch possible issues and lose little time by preventing rework. But what did not work well enough for us, is the moment after the developers are done with implementing those designs. The developer finishes the functionality, sets the backlog item to done (after being reviewed by a colleague developer of course), and that functionality is then presented in the demo at the end of sprint. In our experience, this process was lacking for two reasons. One, during this demo the designer sometimes would notice a detail or interaction that would not work well or as intended. This can be the result of a mistaken implementation of the design or an unexpected issue caused by something else. As a consequence, this issue would be put in the next sprint to fix. The second reason is that the demo shows the functionality in a limited way, often as one specific use case as described in the original user story. That is quite different from experiencing the app on your own device, going through several use cases. You’ll experience stuff like loading times, and how an interaction feels in the bigger picture of the whole application.
The fix
So there was a weak link between finishing the code by the developers, and demoing this work at the end of the sprint. How did we fix this? We involve the designer as soon as possible, when the functionality has been built but before this is shown at a demo. Using the existing development process with its tools, it is quite easy for the designer to test the new functionality. And that is done by involving the designer in approving pull requests as well. (What is a pull request, you ask? It is basically a developer asking the team to review his or her code, before it become part of the main code.) The developer is then not only sending a pull request to the developers but also the designer. The designer can download the right build of the app to experience and review this new functionality.
This was the fix we needed in our process. As a designer I get notified when a PR is available, I download the build and test the functionality. I am able to verify if the design and the PO’s wishes have been implemented well, and I could act quickly (with suggestions or updated designs) if something was off. For our development process, this gives us multiple advantages:
- A designer can check the functionality and help to improve it before the end of the sprint, so the functionality is definitely finished at that point. And that results in a satisfied PO at the demo;
- With a review of the PR when it becomes available, the developer has the code and solution still fresh in his or her memory. So discussing or changing the solution, takes less time and effort for the developer, in comparison to fixing an issue in the next sprint. This will more then compensate the extra time the designer puts in to do the PR work;
- A designer becomes a semi-tester, by putting the new functionality to the test and trying various inputs and interactions.
In a recent project, we applied this process when developing a mobile app. My colleague Frank explains in this post how you could set this is up for your own projects.
Conclusion
If user experience and usability of an application are important, it makes sense to involve the designer sooner and more often during the development process to review newly built functionalities. The best way to do this is to use the already existing process of pull requests, and sending the designer a PRs as well. Then not only the code will be reviewed, but the user-facing solution will be tested as well, resulting in better and more user-friendly applications.
