Get better technical maintenance quality and productivity by introducing UI/UX profiles onto dev teams: a lean/ growth-hacking approach.
This is an idea we’ve been working on for a while. Our clients find it interesting, but it’s still rarely applied. As such, we haven’t pushed it much in the last few years, as we are first and foremost focused on technical production.
Fighting against obsolescence of solutions with technical maintenance could be made much more effective by adding digital design professionals, oriented more towards software or Web platforms, into the dev teams that we offer our clients.
Many positive effects
1. Better functional integration of new tech developments
Adding UI/UX profiles to your team will help you better take advantage of new functions and technologies introduced into the product life cycle, whether working with software or a Web platform, with a view to extending the lifespan and more fully aligning the product with user expectations throughout its life.
2. Decrease backups in your work pipeline
How many times have your tech and design work flows been unsynchronized in recent years, with tech waiting on UI or vice versa? How many times has that desynchronization resulted in re-working and delays? Incorporating UI/UX into maintenance puts all of the work together into the same agile development cycles, leading to a lean/ growth-hacking process. UI work can be added at the start of your next sprint, or even into your current sprint.
3. Much better understanding and collaboration, thus much better quality and productivity
Pentalog has long included QA and PO experts in its agile teams. By adding design, all participants in the sprint benefit from better functional understanding, decreasing the risk of re-working and functional problems.
That’s not to mention the time saved on communication and quality assurance.
The amount of work for designers in each sprint should be no less than two days to provide a minimum amount of focus time. Or maybe a week every two or three sprints. Maybe even more! It all depends on the tool and the context. The designer will use that time to examine usage, competition, and the meta-environment then introduce tiny changes, sprint after sprint, to avoid having to make abrupt, massive changes that users hate.
This work, although included in the dev sprint, will only be released after internal validation testing done by our client or a group of users. That testing will include KPIs generated with live usage wherever possible.
In practical terms, we will start with a discovery and understanding period, which will take place at the client’s offices. Then, the work can mostly continue remotely, but with many meetings with the client planned online and offline.
Maintenance saved by lean development and growth hacking!
Maintenance is a great opportunity to improve the way you work and Kanban is perfect to help you with that. It provides highly qualitative support, which is important because that is how customers build opinions about brands. Much more than with creating a new product, where data is, by nature, much less abundant, more theoretical, further from reality, and thus more open to interpretation.
If we want to really help our clients grow by matching their products to their markets, we have some serious work ahead of us. These concepts are already in play for Web platform processes, but they are less commonly seen in software development.
The entire innovation cycle could benefit from deep reforms.
Maintenance could be saved by lean development and growth hacking! Who’d have thought it?