UX & UI
Last updated
Was this helpful?
Last updated
Was this helpful?
The act of designing how an application looks and feels isn't an isolated moment within the project's timeline but rather a transversal process that contributes during most of the project's life. In fact, there is much work that can be done at the very early stages of the project. More information on that can be found in other documents. On this document, we focus on how design integrates with software.
Our creative process depends on 3 key moments when it comes to finding out how our products will behave and look. An early prototyping stage, before most decisions are settled; an initial design spike, where we try to determine the overall structure, behaviour and language; and the "just-in-time" individual contributions for the ongoing Epics or even Sprints.
At the start of every new cycle of development, typically a new Epic, the team gathers to look at upcoming User Stories. The idea is to make them clear so that we, as a team, achieve a strong shared understanding. We progress, one by one, doing individual sketches to represent how we imagine them to be. This type of exercise produces a large amount of solutions from which we will shape a more solid version of what is going to be built. By allowing everyone to participate with their opinion, we believe that each one will better understand the decisions that are being made. Discussing how things behave, enables everyone to contribute towards defining key attributes such as how long will a task take and who needs to work on it. This exercise may require one or sometimes several meetings, depending on complexity but when it's finished, everyone should be at a better place to do their job.
Having the User Stories in one hand and the results from the prototyping exercise on the other, the designer is now ready to create. Because we start planning ahead for the next Epic, there is time for the designer to work and find solutions as well as to introduce feedback in its work. The goal is to have a solid base structure to work with, by the time the engineers are done with any preceding work.
It's not uncommon for things to change along the way. It's part of how we work. We build products while allowing for valid feedback to be integrated. Sometimes that means that we need to make quick adjustments to what we had already designed. It's usually a less intensive stage, when we on day-to-day tasks that aim to create specific solutions on the spot.