Results Digitais is the company that develops RD Station, a web-based tool for Digital Marketing that, during the last two years, jumped from 80 to 1600 customers and from 15 employees to more than 100. During these two years that I followed As the company and the product grow, we apply and test different ways to develop new features.
The list of topics below is not a cake recipe, but a sharing of our experiences. There are 11 steps that summarize the process we used to build the great features of RD Station launched in 2014. The process, which is in constant evolution, helped us a lot in the initial phase of accelerated growth. The purpose of the following steps – which are part of our Product Kanban – is to bring the designer’s vision into the completely new feature development cycle.
Quite simply: any idea can become a project for the product area and the place where we keep these ideas is what we call a Sandbox. Customer feedback, support tickets, hallway conversations, market strategies, internal and external seminars – all these events are excellent idea generators.
Each quarter, the entire company promotes a priority alignment that defines the KPIs (Key Performance Indicator) of all areas in the short and medium-term. These indicators help to define which projects will be pulled from the Sandbox to the Backlog, as well as defining the priority of each one.
Before thinking about any solution, we first seek to understand the real problem faced by our user. More important than creating hypotheses in our head is to validate them with our base. That’s when we get in touch with customers in their different personas and validate that we’re all talking about the same problem.
We are a Startup Lean, it’s something that’s in our DNA (and Culture Code too!). Therefore, we look for which products or services have already gone through the same problem. We don’t want – and don’t even have time to – reinvent the wheel. We seek to find out how these companies have solved the problem we are facing, and during the investigation, we avoid assuming whether the solution found from the outside is good or bad. In benchmarking, the important thing is to get different perspectives. Again we may contact some customers and find out how they are handling the same topic.
Problem identified and benchmarking done: it’s time to put together a proposed solution. The alternatives raised in the benchmarking study are useful – but none of them will satisfactorily solve our customer/user problem. They are just references.
At this stage, as a designer, I start with an outline of the solution, and based on it, I carry out a series of tests to understand if this proposal can consistently solve the problem raised. An important point here is not to settle for the first results, even if they were already satisfactory. In this way, we are always striving for excellence in what we propose to do. Only after analyzing different approaches to the solution do I move on to something more structured and present it again to the stakeholders.
One technique I’ve been training with is to avoid using slides during this type of presentation. If I really understand the problem and the solution I’m working on, I don’t need slides. Everything I need I already have inside my head (I use a whiteboard at most). The data that is not important will be forgotten however, the ones that really matter will be intact in memory and will be remembered when requested. I am aware that this dynamic is only possible in a few companies and/or projects. Still, training presentations without slides can pay off in any situation.
Another very important point in this “conversation” with stakeholders is to listen carefully to their feedback. We are at a point where the solution can still change course radically without great cost to the project. As in the study of the problem, the proposed solution must also be well understood by everyone – there can be no doubts about the concept. This is the time everyone buys the same idea.
It is also at this stage that we establish, more precisely, the goals that the solution, after being implemented, must achieve. Some examples of these success metrics: increase hits by 3%, increase engagement by 10%, hit 0.95 on Apdex, decrease support tickets, etc.
The MVP phase is when we need concrete clues to identify if our hypothesis is on the right track. His idea is to design a quick fix, apply it and understand if it has the potential for success. For this validation, it is not necessary to develop the product in a traditional and complete way. We can test some smaller hypotheses using user/customer surveys, extract usage or engagement numbers for the product, survey other products (competitors), etc.
Finding out whether success metrics will be met is what can define the “go/no go” of the solution – and even the project. Up to this point, it can be easily aborted. Some factors can put the proposal on standby or radically change the course of the project. Among them are the collection of unexpected results and changes in priorities in the area.
At this point, we begin to visualize the concepts from the previous steps. In the beginning, I use pencil and paper to draw the marking of some points that will be useful later on and the flow of using the new functionality. Pencil and paper do not go beyond that. In the case of RD Station, we already have a robust HTML, CSS and JS framework installed in the product – which makes it much easier to quickly create prototypes in HTML. I’ll go deeper into this subject in an upcoming post.
Even as a designer, advancing in front-end studies brought a series of advantages to the interaction design stage. Prototyping in HTML, it is possible to run some tests of the interface with the proposal under development. The process is initiated by the designer himself testing the functionality flow. Afterward, they call on other designers, developers, colleagues from other areas of the company or even friends and relatives. In the case of Digital Results, we still have internal customers who are available for testing at any time. When necessary, we still recruit some customers and test them remotely (using Skype).
The order at this stage is to experiment and test different approaches until we are confident to move forward in development.
The presence of a developer is important at all stages, but it is at this stage that he will have more active participation. It is in the integration with the software that the gears start to turn and the real problems appear.
It’s possible—and even likely—that some interaction design changes will be needed. That’s when you realize that the effort to discuss the problem and the solution makes a difference, as it will be these arguments that will keep the evolution of development on track. The danger is that you end up focusing on interface issues and forgetting the real customer issue.
Again, front-end knowledge becomes an advantage as it is possible for the designer to make changes directly to the code. This makes the process very agile and prevents you from getting stuck in solving errors. In addition to ensuring the visual quality of what was planned.
In alpha, in addition to watching real users using the new features, we test the feature’s release and how it will communicate. This is not the final version of the project and is usually released in the final stretch of development.
For design, the main purpose of alpha is to test a solution and gather feedback. In this step, we select a sample of customers and release a preliminary version of the new functionality. This is when we are able to cut the product with greater precision and there is still the possibility of carrying out changes without major damage to the project planning.
One of the big secrets of the release phase is keeping the success criteria of the new feature in mind. Some examples of these criteria are: improving sales numbers, increasing the average ticket of base customers or decreasing the number of cancellations. And the launch must have clear strategies and actions to achieve these criteria. Engaging and Activating customers is a cause to consequently and actively achieve the project objective.
Going back to the beginning of the project, we remember that our quest was to solve a problem. To do this, we developed a solution with the expectation of achieving certain metrics. It is in the results phase that we assess the success – or not – of the proposal. Regardless of whether the expected result was achieved, this is the moment when we learn and effectively improve our processes and repertoires.
Often, the results of the project that ended recently already start to supply our Sandbox and, consequently, our Backlog.
As I wrote earlier, this is all an evolving process and it has served us very well as the team and our customer base grew at an accelerated pace. It is very likely that during the next challenges of Resultados Digitais, this process will undergo adaptations again in order to remain agile and avoid wasting the team’s effort.
Finally, I would like to reinforce two points that were repeated a lot in almost every step and that serve to improve even the process itself:
- Test constantly and consistently. Ever.
- Gather feedback. Ever.