Designing a Solution for Scott: From Blank Canvas to Faster UI Development
Low-code platforms like OutSystems provide the simplicity of drag and drop, dozens of ready-to-use widgets that include built-in features like RTL (that’s right-to-left for those who don’t know), accessibility, and responsiveness, making application development a breeze. However, despite this, creating something from a blank canvas can be really tough, especially when you have an idea or a goal but no UI references whatsoever.
At OutSystems, we strive to provide an end-to-end solution for accelerating all stages of the development process. With this in mind, last year, we started focusing on that goal for something that would take UI development to the next level.
This is the story of the project we call faster UI development; it was recently unveiled with OutSystems 11. I am going to bring you the inside scoop of how our teams collaborated, made hard decisions, struggled, and ultimately handled this project here at OutSystems. And I’m going to introduce you to Scott, our imaginary friend, who helped us through the whole project
Starting From a Blank Canvas
Creating web or mobile applications from scratch is hard; the market demands fast solutions and for value to be delivered faster than ever. Imagine you want to create a directory application for your company. You’ll want to show people a working app that is consistent with all the other applications as soon as possible, right? To achieve this, you’ll need UI and UX resources to craft all the screens and interactions while following the brand style guide.
In 2015, OutSystems launched a UI framework to accelerate app development through pattern composition and also provided templates for built-in screens. We felt that we could go even further. So we worked on making the screens easier to use, and we included a wider variety of screens that are smarter in the way they are adapted to your data.
The Discovery Phase
At the beginning of this project, all we had was this blank canvas problem, the idea that screen templates would be a major improvement for UI development, and that there was a lot to learn.
We built a multidisciplinary discovery-phase team with people who had recently worked on UI development. The team had all kinds of roles — product owners, product managers, developers, and more — because we invited anyone who could contribute knowledge, insights, and perspectives to the project. This broad skill set was vital for the project’s success, enabling us to discuss the problem from different angles from day one.
Recent projects where we explored development by composition were another important source of information. By analyzing what we’d already worked on, we were able to identify areas of improvement and also issues that matched the limitations we’d identified in our blank canvas problem. We gathered all our data, conclusions, and notes to get closer to reaching a solution.
When we believed we had enough information to work with, we held a design session with our product design team and discovery-phase team. In this session, we presented the research, brainstormed, sketched several ideas, and reached the agreement that we had enough support to set up a team that would keep maturing the project, even though we still had a few unanswered questions.
The Setup of the Project
We knew what we wanted to achieve, but there was a very foggy road ahead. Without a solid goal, personas, or risk management, we could easily lose focus or hit a wall mid-project. In addition, this initiative would require different product areas to collaborate with one another.
In the beginning, one of the most difficult conversations was about the ultimate goal. Every other meeting for the project had a new ultimate goal change. Even if it was a very slight change, we kept questioning the goal until we were certain that it would keep us on the right track for the project to succeed.
Another very important discussion was about the personas:
- Who will benefit more from this feature?
- What kind of developer are we targeting?
I’m passionate about the work we do at OutSystems. I’m always excited to start a new project, and in my excitement, I start looking for solutions right away. I have to confess that at the time I didn’t really see the value in defining a rock-solid goal and personas, and I wasn’t very interested in the small tweaks we kept making. I thought that they wouldn’t have an impact in the long run because we already had a pretty decent idea of the features we would deliver with the project.
But, later on, when we had some hard choices to make, our definitions of the goal and personas really helped us stay on track, and this is when I realized how important this planning was and how mistaken I had been at the beginning.
Meet Scott
Clarifying the goal and personas is crucial in any project. If you have several goals, you’ll end up missing most of them, if not all. Our goal was to provide the most acceleration possible to the most common type of developer: a recently trained developer with only a few months of experience. We named this guy Scott, and for some reason, his name would make all the difference.
Starting the Project
Although we had already extensively researched screen templates, we held a design session where we gathered a lot of ideas and even designed a prototype. We were heading into uncharted territory. We were going for something new that we couldn’t compare with anything we’d done before, so we had to deal with a lot of uncertainty. It was clear that we still needed more research, we had to understand the problem at a deeper level, and we needed to walk in Scott’s shoes and focus on the right problems, applying the 80–20 rule.
The team decided to have a “milestone 0.” At this stage, we would not start development. Instead, we’d research our target persona more thoroughly, and we’d look at our competitors and hold more design sessions focusing on our product. Two interesting things happened:
- When we looked at our competitors, we discovered that what we were trying to achieve hadn’t been done before. We wanted to offer fully working screens with minimum effort, while everyone else provided only UI elements with no data or logic of any kind.
- We took a step back and used OutSystems 10 to build some of these screens by hand, so we could better understand the struggles, the pain points, the most repetitive tasks, and how we’d best simplify this work.
Milestone 0 resulted in a slide deck of over 300 slides! We dealt with (very) frustrating experiences and issues, and we identified some clear areas of improvement in our own product. Each slide represented a single step that Scott would need to take when creating a screen, if he needed more than five steps to perform a simple task, we raised a red flag!
As part of this process, we gathered all the people who had been involved to go over and discuss all the new evidence we had collected. Finally, we could begin to get our hands dirty. We had a clear goal, target persona, and the teams were ready to create something amazing.
Cross-Team Collaboration and the Be Helpful Rule
The project involved three development teams — five if we include the product design and technical communication teams. Although we all had the same goals, each team had different responsibilities in the project; it’s important to make sure everyone is focused on the right tasks.
Our system owners and team captains were able to split the project into small stories. The teams estimated how much time they’d require to be implemented, so now we had what we needed to create a project timeline. Right away we encountered some problems.
Availability
Some teams had other ongoing initiatives and could only deliver their part of this project later on. Due to dependencies, that would block another team, delaying the project further than the OutSystems 11 release, so we had to get creative, and we did. We identified the teams’ expertise and knowledge of the product, so we could have another team start on their story, avoiding a delay.
End-to-End Vision
The teams had to constantly align because the project would only be a success when all the stories were merged. The teams couldn’t focus only on their part of the project. My team was responsible for the research and development of the screen templates, but we needed to keep in mind the big picture, the performance, user experience, scalability, and all kinds of requirements to provide Scott with the best experience possible.
Team Sync
Three product teams started development, and we needed to make sure everyone was aligned and red flags were raised whenever necessary. We don’t have a secret tip or magic alignment recipe; we opted for the classic Scrum with all the teams. Once everything was smooth sailing, the team captains used a shared document as a means to communicate between themselves every two weeks, and this was enough.
First Steps and In(f)ternal Feedback
Soon we were able to merge the first parts of the project, and things actually worked! We shared the very rough solution with the R&D department, and this provided its own set advantages and challenges.
The good: we could test in the early stages. This gave us a pretty good idea of what to keep and what to discard. It kept everyone motivated, and we could see the impact of our work, even if only internally at this stage.
The bad: internal feedback about work that is under development is usually a mess. It’s hard to track, hard to manage, hard to categorize, and hard to prioritize. Most of it has to be discarded because “It’s not going to look like that in the end, it’s still in development!!!!”. Indeed, my team asked me to name this separator “infernal feedback” instead.
Working with different teams that are eager to be helpful is cool and all, but it’s not a road only paved with love. Involving a lot of people brings a lot of opinions, ideas, perspectives, and discussions. Not everyone will agree on the best solution for a given problem, so we counted on following the solution that was supported by the majority of the team. We stuck with that decision and supported the team if things didn’t work out as planned. No fingers were pointed, because we learn through these failures.
To keep things running smoothly, we must always be pragmatic. We can’t afford endless discussions and infinite prototypes for a solution. We need to keep moving while confident in our decisions, and for that, we have the support of something we defined early on: ultimate goal and our friend Scott.
We always include some slack in our planning so we can be flexible about where we should invest, and we knew we would be constantly iterating on top of feedback. In projects with a lot of uncertainty, it’s also common to have some kind of dual-track discovery; we tackle small problems while starting to research the next ones, and this gives us the confidence that we will never hit a roadblock and get stuck at some stage of the project.
User Testing, End-to-End Tests, and Gut-Wrenching Feedback
After the initial internal feedback and after making some progress with the project, we started to feel confident in what we achieved so far. So, it was time for the next stage of testing: real users.
This was another part of the project where we had to get creative: you see, “Scotts” aren’t easy to find, especially Scotts who are available to collaborate with us while being observed using the new features. Fortunately, OutSystems is growing really fast, which means that every week, we have new colleagues around the office. Many ramp-up by following our product training; this was almost perfect, so we decided to have usability tests with our newcomers.
These kind of tests are very valuable. They ensure we’re on the right track, but they are also very hard to do, because:
- Every user is different and perceives features differently. A lot of tweaking and redesigning are needed to deliver something that all users will understand and love at first sight.
- You never really test a single feature. Instead, you’re changing the first experience for every user of the product. In the middle, you will discover problems that were not directly related to the new feature, but with existing parts of the product.
Many of these user tests were gut-wrenching. It’s not easy to see five out of six users not understand how to use something you worked on for an entire month and were certain would be so easy to use. But it’s better to do this early on to allow time to act on it and to make it right!
Measure Everything and React Fast
We had a three-month window to test all the features with early access users, but external feedback usually takes a long time to reach us. So, we needed a quick way to measure adoption, collect feedback, and then act on it to measure again. This sounds crazy, and it is.
Our solution was to have telemetry everywhere. We had to know how users created screens, If they used templates, we wanted to determine which were used the most, how many clicks, how long they explored the window, how many times they canceled or pressed undo. We also wanted to capture the time from creating a new app until they 1-Click Publish. We brought together the different teams and listed all the questions we wanted to answer. Later, we implemented all the events to capture the information we needed.
The first results were positive, but we had to take them with a grain of salt. After all, it was a new feature, and the adoption curve is usually very high. The problem is keeping it there in the long run.
The Go Live
Before releasing OutSystems 11, we still had time to act on feedback from the early access program, tweak a few details, and ship a feature we’re proud of. But it’s not over, we’re watching the usage metrics and reacting on the feedback we receive; we’re listening to community ideas and providing more screen templates continuously.
A Journey, Not a Destination
Scott is part of a long-term journey, which has only just started. During this project, we were able to brainstorm ideas and collect a lot of evidence that confirms that there’s much more to do. We’re just at the dawning of UI development, and it can be even faster. All we need to do is believe it and work hard to achieve it.
We know Scott would be proud. We are.
