Server-driven UI has been a relatively hot topic in mobile app development circles over the last few years. While its implementation requires a good deal of up front development work, large companies have proven it to be an effective method for publishing UI changes quickly by reducing demands on engineering and avoiding the app store submission process. We’ve written a good deal on Server-driven UI here, and indeed, for many product teams it can be highly impactful. However, there are alternatives to SDUI for product teams looking to ship and iterate on UI more effectively.
At the core of any impactful solution, is a defined problem. As such, it's important to get at the core of what problem or improvement a product team is looking to solve when they implement Server-driven UI. In our experience, product teams are led to SDUI, primarily as a means to ship and iterate faster in their mobile apps. We know shipping frequently and iterating quickly based on user feedback is a cornerstone of successful products, so approaches that can accelerate the product feedback loop are highly sought after.
In order to understand where there can be efficiency gains in the product development cycle, we need to look at the workflow of a product team working on native apps. In general, this process can be broken down into 6 steps:
- Strategy and Use Case Identification
- Mock Up and Prototype
- Design
- Build
- Test
- Publish
Of course, this process continues as product is refined based on user feedback and data. While Server-driven UI does accelerate the ability to make certain UI changes by reducing demands on engineering resources, it is known to be highly expensive to architect and requires a lot of organizational alignment and long-term foresight. Getting your SDUI implementation wrong can significantly reduce any efficiency gains and result in its implementation being more costly than it was worth.
Having built a Server-driven UI solution in the past at Judo, we learned first hand how important getting SDUI right for your use cases is. Not only does it require an understanding of current scope and permutations of your use cases, it requires a bit of a crystal ball view into how you may intend to use it in the future. Add to that the lift associated with making it multi-platform, and for many teams, it isn’t the best use of resources.
So how else can we make similar efficiency gains? One area of the UI publishing workflow where there is much room to drive efficiency is in the prototype-design-build aspect of your UI publishing journey. Specifically the steps of Design and Build. Most product teams have experienced inefficiency and friction here in the designer-developer hand off. Often referred to as ‘the hand off problem’, this inefficiency stems from the redlines, markups and redundant feedback loops that often occur when a design is handed off to development to be built. The results in workflow inefficiency and causes a significant drag on the pace with which a team can publish and iterate on UI.
In order to avoid this, designers and developers can tighten up this workflow by:
- Involving developers earlier in the process
- Creating useable, often Low-fidelity mock ups
- Use design systems to standardize components and build UI Faster
- Look at purpose-build products like Judo that combine design and build in to a shared canvas and workflow
Helping product teams work more effectively and ship better product is a topic we are very passionate about at Judo. Having spent a lot of time on Server-driven UI, we’ve come to understand that for many teams, there are better solutions to the underlying problem. Reducing the back and forth between design and development has the potential to yield impactful results, and we’ve seen it first hand. Give Judo a try for yourself and see how you can accelerate your UI publishing workflow and eliminate the handoff problem.
