Design as an Incremental and Agile Process

The year is 2017 and despite all advances in software development methodologies, many product teams still tend to separate – or even dissociate – the design process from the development workflow.

When talking about engineering, most teams work using agile methodologies, i.e., they develop things defined within short sprints, and constantly iterate and re-define priorities in order to evolve the product in the most efficient way.

When it comes to design, product teams usually expect it to be a separate process that outputs a series of mock-ups, which will then be implemented by the engineering team in a separate flow (as in a waterfall model)

The tendency to dissociate the design and development processes seems to come from a civil engineering background, in which the design comes from the architect, and the engineer’s role is to build it, with little to none room for modification.

Moreover, most education systems teach designers and engineers isolatedly, and rarely put them to work together with the goal of building a digital product together. Designers, on one hand, conceive products during college that rarely get implemented, whilst engineers receive pre-conceived mockups ready to be implemented, with little margin for modification.

What usually isn’t taken into account is that, in contrast to a making a building, a digital application is a mutating and continuously-evolving system that shouldn’t be thought of as a monolith. For not being physical and immutable, it can be built like LEGO blocks, iteratively.

I’m not saying that things are always easy to change, but a solid codebase and well-thought components definitely make it easier to change and evolve interfaces according to user feedback.

The downsides of the classic approach

From a product perspective, it’s simple to point out some flaws in the classic design-engineering collaboration approach:

Designers don’t take development time into account when creating interfaces, which might considerably increase the budget necessary to build the application

An example of this case is when using components that aren’t native to the platform the application is being designed to. For instance, it is really common to see iOS apps using side navigation drawers (albeit product teams eventually realize this is probably not the best idea, as did Spotify).

Although it is easy to implement this “hamburger menu” on Android (since it is a native Material UI component), it is not natively supported by the iOS Software Development Kit (SDK), and therefore takes some time to get it done right.

The solution? Have the design team talk to the development team, and realize that things can be implemented much faster (and with a better experience) if we use the components that are native to each platform.

Engineers, on the other hand, don’t suggest development libraries that could easily implement some animations and UI elements that a designer wouldn’t consider at first, for thinking they might be too complex to implement

Engineers take the advantage of having handy a lot of awesome open-source development libraries which are, well, awesome. Some animations and transitions, which are fairly difficult to implement from scratch, can be easily done with a couple of code lines, thanks to many engineers who have contributed at their will to create tools to make a shortcut to this implementation available to the world, such as, JellyToolbar, gliding-collection and Bubble-Picker.

Design and requisite flaws take longer to be tracked, and the design team might already have shifted context when they are presented with modification requirements

As in the waterfall methodology briefly mentioned before, design teams tend to deliver the mockups and assets and move on. Since the implementation takes a considerable amount of time, it might take a while before an engineer notices that they need some changes to be done in order to fulfill the requirements.

By the time the flaws are noticed, it often happens that the design team has already shifted context, which might cause them to take a while to re-integrate to the project (when possible, due to time constraints) and be able to propose solutions, which will then need to be re-validated and implemented. What is more, sometimes the designer that will perform those tweaks wasn’t part of the original project team, which might even increase the onboarding timespan.

This intricate process isn’t beneficial for either engineers or designers, and it negatively impacts the bigger goal: the product the whole team is building.

Tips to overcome these problems

Plan & Iterate Together

Bringing together designers and developers at product/project meeting will certainly prevent hiccups in the long run. Having both visions while planning will ensure that your team will spend the minimum effort possible to develop a new feature/functionality.

Build Together

Designers and engineers should stay close when building things. It is fundamental (whenever possible) to have them be able to assess each other whenever needed, making sure the team is in sync and performing tweaks as needed, in order to have a smooth product build cycle.

If your team is geographically distributed, tools like Slack and Hangouts enable straight communication and screen sharing sessions – make use of those awesome and free tools! 🙂

Be flexible

Everyone in the team should be able to contribute and leverage their experience, regardless of their focus discipline. Both engineering and design fronts should keep their mind open about changes, since they’re all working towards the same goal: building an amazing product.

Wrapping Up

When creating software, you usually don’t know what you’re building yet. Once in a chat with Travis Kalanick, he pointed out – along with his signature quote, “Done is better than perfect” – to Cheesecake Labs’ CEO, Victor Oliveira, that it doesn’t make sense to create a long and lasting design & development process at an early stage of a product – it is time-consuming and rarely accurate.

The concept of perfection is misleading, as anything can always be improved. It is better to have a product on the market that can be improved, instead of a project that will never be released and finished. Therefore, designers and engineers should work rapidly and iteratively together to test and release any new functionalities as soon as possible.