Design Sprints and Low Code on Why They Work
High energy, a breathtaking prototype and insightful feedback. If that’s what you’ve got after a design sprint, it has been a successful one. Now you’re up for a challenge, how are you going to maintain this level of involvement and velocity?
In my last article, I already described how some additional ingredients can complement your design sprint to prepare you for the development and roll-out of a working product. One of the technologies that you can use to develop that product is Low Code.
I’ve spent the last five years developing with Mendix and Outsystems, two market-leading Low Code platforms. Both platforms allow you to build applications while using very little code. They accelerate the development of 80% of your functionality and will allow you to custom-code the last 20%.
This marks a clear difference between Low Code and No Code. In the latter, you can’t customize your front- or back-end using good-old code and instead will fully configure your product using building blocks. When coming from a Design Sprint, this is a crucial detail. You don’t want to tell you Sprint team that some design elements can’t be built with your platform.
Forrester reported that in 2018, 23% of all developers used low code, with an additional 22% that was planning to use it in 2019. So while some skepticism still exists among code-lovers, the numbers show that this accelerating technology is hard to ignore.
I’m a big fan of both Design Sprints and Low Code. This is because of the benefits of the unique concepts, but also because of the common concepts that exist in both ‘methodologies’. The overlapping philosophy makes them a perfect combination. In this article, I explain the common concepts.
They put Process first
During a Design Sprint, you don’t want to get distracted by technological complexity. You want to focus on the goal of the Sprint and the map that your users will follow to reach their goals.
Low code takes the same perspective. Instead of learning a new programming language, you can focus on the right way of working. Low code platforms typically offer a Model View Controller framework, in which you set up your data model, your pages and the logic that connects everything. Adding something to one layer will show the effect on other layers. The platform thereby makes it easy to build feature by feature while you continuously improve each of the layers.
Integrations can be bootstrapped by importing example structures. You drag and drop some logic to define how the outgoing or incoming data should be processed, which encourages you to focus on the how of your integrations, instead of the what.
They facilitate participation
The fact that Design Sprints facilitate participation does not need to be explained. It’s the core of the methodology and it’s the core of its effectiveness.
Low code facilitates participation in two ways. It empowers stakeholders on your project and makes the product development easy to show to people with no or little IT knowledge.
Empowering stakeholders could come with some risks though. Many low code platform providers promote ‘Citizen Developership’, which means that anyone can build applications. Unfortunately, if you make it too easy to build an application, it will also be too easy to build a bad application.
Slowly, the platforms are realizing this and are clarifying that part of your development team, the part with an IT background, should develop reusable components. The team members without IT knowledge can assemble these components into the screens and logic they want.
Regardless of IT background, Low Code makes it super easy to involve the whole team in what your building. Instead of showing many lines of code, you can show a flow of named action blocks and decisions. Instead of showing plain database tables, you can show a meaningful entity-relationship diagram. Instead of showing HTML and CSS code, you can show a What You See Is What You Get front-end development environment.
They stimulate the reuse of proven ideas
The lightning demos in Design Sprints teach an important lesson in usability design. To design a user-friendly product, you should not aim for revolutionary navigation and interface. Instead, you should aim to reuse proven concepts and combine them in a way that supports your user’s process.
Outsystems has found a very effective way to fill their component library. The company has studied the world’s most-used applications and ‘copied’ all components that are necessary to build 80% of those applications. As an effect, you will find almost every component that is needed to create your Design Sprint’s results.
If a component does not exist yet, you just build it using whatever language is supported by the platform. Most of the Low Code platforms have a marketplace in which you can offer your reusable components to the community. And if your component is popular enough, it might be incorporated into the platform soon.
They make prototyping work
There’s usually one difficult decision to make after finishing the sketching & storyboarding parts of the Design Sprint. Will we start building ‘just’ a visual prototype, using, for example, Figma, InVision or even PowerPoint? Or are we going to develop the prototype on our Low Code platform?
The answer is, as expected, it depends. It depends on the prototyping qualities of your team, on what you're trying to validate and on the complexity of the screens.
However, when you choose to go for your Low Code prototype, it is remarkably easy to add interactions and data to the screens. Additionally, it will allow you to quickly validate other aspects than the visuals. In some cases, I’d like to find out whether a certain data structure will work, or whether integration can be made instantly.
Low Code platforms allow you to test that in a matter of hours, saving you plenty of time that can then be spent by validating deliverables with your future users.
Design Sprints and Low Code platforms. They are two of the most mentioned and fastest rising concepts in the last decade of application delivery. They have a fundament that covers the user process, stakeholder involvement, reuse and fast validation. It’s this fundament that will probably make them last and that will allow organizations to deliver the right products.
