
Introduction to RUX Sprint
The communication framework for small teams.
Rationale
At RedSquare, the biggest challenges we face in developing digital products come in the form of communication. Whether is misinterpreting what a product owner wants, or setting way too much of an expectation for clients. Often, this leads to ambiguity on what they product owner wants.
The go-to solution to solve this problem is to run a workshop such as Google’s Design Sprint. This allows the entire product team, from developers & designers to business executives to come together and bring into existence a new product or service, powered by an app or website. However, the Design Sprint framework, assumes a few things;
- Any software solution thought of can be built.
- A large software team of multiple expertise is at disposal.
- There is perfect communication between designers and developers during the product development phase.
- Business executives understand the limitations of the developer team.
The Design Sprint was conceived of in Silicon Valley by Google, and as that factor suggests, it is made with the expectation that world-class designers, developers and business executives with technology experience are available. But for small teams with relatively fewer developers and first time tech business founder, Design Sprint begins to show its limitations. RUX Sprint aims to solve this by providing steps in which the developer teams can show their abilities and limits, and business executives can understand them while being part of the prototyping phase. The most important thing RUX Sprints solves is the ability to establish feasibility.
We developed RUX (RedSquare User eXperience) Sprint to fit our existing team of 5 developers & designers, in Malaysia, where tech talent is not abundant. One important thing to understand is that RUX Sprint is NOT a replacement for Design Sprint, but a complimentary element to it. For those familiar with Design Sprint(a 5 day workshop), RUX Sprint meant to be run on Day 2-Sketch & day 4- Prototype of the Design Sprint.
RUX Components
As will be discussed in depth in a later article, RUX Components are essential to highlight the capabilities of a developer team. For now, it is sufficient to understand that RUX Components are pre-built, reusable components that can be plugged into a project without requiring a lot of modifications.
For example, if you are building a fullstack web application using Django or Rails, a RUX Component which does “Search” needs to be its own ‘app’, with its own model and templates without any dependencies. If you are building a mobile phone application, the RUX Component for “Search” should include UI libraries in the front end and an API component with models on the back end.
At RedSquare, we found that the most efficient technology stack to deal with this framework is React, React Native, Django & GraphQL. We will provide more details on how to qualify a collection of code into a RUX Component as we standardize it soon.
Know Your Limits
In 2018, most digital products don’t only live in the web, they often have complimenting mobile apps to reach as many users as possible. Another reason why mobile apps are becoming essential to an organization’s digital strategy is due to the limitations of web applications to use location, push notifications and retain users.
So it is best for digital products to be designed, at least at the prototype stage, as an iPhone 5S application. The constraints in screen size, RAM and iOS’ UI components will exhibit very clearly the limitations of the tech team and designer. At the very least, even if your product owner only wants a web application, design it with iPhone 5S’ screen in mind. There is no excuse for web apps to not be mobile responsive in 2018.
The Team
For the best execution of RUX Sprint, a minimum viable team must be present. This include;
- A business executive with authority to modify the product.
- A business executive with authority to communicate with customers.
- A business executive with authority to allocation funding.
- A backend developer who understand how to design databases.
- A designer with experience in Bootstrap, Material Design and/or UIKit.
Although this team will be sufficient, it’s also advisable to have as many members of the organization as possible in the workshop.
The Four Step Process
Let’s get to it.

Sketch
Your app is not the product, it’s a medium of delivering a service. In most companies, services are often delivered through non-technical business processes. There is always an expectation of developers to deliver software that overcomes all of these limitations. But in most cases this is not realistic. The goal of this step is to identify whether the business has the business process ability to execute the functions that the tech team is about to build.
Begin by getting the business executives to sketch out a rough idea on what the app they want will look like. 3–4 screes should suffice, but it must show a complete user transaction. Then begin labeling each component in the app with the business unit necessary for executing the service associated with that component.
Here’s an example with Grab.

Once labeled, begin a discussion with the head of each business unit mentioned. Ask them to explain in depth how their plan to execute business processes necessary to perform the service. Once all the unit have given consent, proceed. If not, remove the component and repeat the exercise until you have a sketch that does not have a business process bottleneck.

Model
Software takes no bullshit. In order to build something, developers need full, logical understanding on how a particular component is going to perform. Vagueness creates bugs.
I’ve been in many meetings with products owners where I got seemingly illogical product features. Often, these requests are not present in any other product to serve as a design reference, nor are they efficient to build. This happens more often than not, and a software developer, we’re inclined to say yes before knowing if the request is buildable. So how do we solve this?
Start by having the back-end developer draw out a UML representing each of the approved sketches. This should not take more than 20 mins. If it does, the model is probably too complex for an MVP. Consider this seemingly simple example of a site teaching coding;

It will have a corresponding UML which looks like this;

Looks good, but wait. One more important thing to identify is the exhaustive nature of a query. Notice how in this particular page, each video has likes. Every time the page is loaded, with this specific database design, it need to count every like associated with a video, and repeat that process for every video on the home page. This is very resources intensive and makes the page slower.
In scenario like this, its important reassess whether the “Likes” component is important. If is it, consider the fact that a lot more work is needed to do things like caching and background counting to make it happen. Also consider if the relevant expertise is present in the developer team.
The beauty of this step is that it quickly puts business executives in a position where they have see the limits of their imagination.
Verify

This is the UI Verification step. This is pretty straight forward. The most important thing here is to verify layout. The most time spent by developers is adjusting layout, especially when the team’s designer is not well versed in grid systems such as the one in Bootstrap. Most mobile app UI grids follow a similar 12-point flex based layout.

Start with a iPhone 5S wireframe and start fitting the sketches which pass the modelling step. Pay close attention to how the layout collapses into mobile view.
In order to make the most out of RUX Sprint, it is highly recommended that you have a collection of components you have built before. If you don’t, it’s still ok. However, it is important to make platform specific checks to see if a specific component like a calendar widget is available, especially in iOS.
Test

When planning to build something, its also important to put a component through a series of test. Often, product owners come up with random ideas that they want to implement, without having something to prove. The purpose of this step is to put the burden of proof on the product owner, forcing them prove the validity of their idea.
When we say test, it actually happens in three phases.
First is to test user flow before you build. We recommended using a prototyping tool like Figma, and make the sketches interactive. Get a few users in your office, let them use the prototype, see if they get stuck. 3–5 users of various demography should suffice for this as this a Qualitative Test. You don’t need 50 people to fall in a hole before you discover that there’s a hole.
Second is to test production code at beta phase. This is not a unit test. This is to identify any product breakages during the course of usage of the product by the user. We highly recommend integrating a tool like Sentry. During the workshop, its also important to establish how to check breakage points to non-technical staff.
The point of the sprint is also to establish what to test after launch. These are Quantitative tests. Establish what your business wants to achieve and establish an essential metric. The metric you want to measure should be connected to the feature the product owner proposed.
Conclusion
The mentioned steps were based on our experience in RedSquare to deal with problems that we had. Since standardizing this into our client communication workflow, we’ve seen product development speeds increase up to 30%.
This framework is a work in progress and we still have a lot to do. Over the coming month’s we will be digging deeper into how these steps play into the wider Design Sprint workflow, as well as release some of our RUX Components which pass usage tests. Stay tuned!

