Introduction
To better adapt and handle new scenarios and problems accordingly, our design and development teams simultaneously create, learn and experiment as the project progresses. Naturally, this comes with it’s own set of workflows, which I think work really well. Agile design is my preferred approach to design, but of course ones choice of process is highly situational.
Iterative Functionality
Experimenting
Creative projects often start off with undefined expectations and requirements. For the most part, we understand what is desired on a surface level, but the core of the problem needs further discovery. As a result we need to use this opportunity to take what is given to us, draw out as much ideation as possible, and converge on creating something that undoubtedly adds value. We know that having plenty of flexibility regarding what to implement and how to approach the design goes a long way during this part of the effort.
In the beginning, our goal is to test out new ideas. In this process as a designer, I feel refreshed and my eyes are open to what really works, and what doesn’t, and why. After which, every decision becomes more empowered and justified. Working with development in this way is a constant dialogue and exchange of assets, and fortunately, working with Sketch and Invision Version Control we can have a simplified process of keeping new designs in one place for dev and clients to reference as time and deliverables progress.
Confirmation
The confirmation process starts based on feedback. Confirmation and experimenting is often times a back and forth cycle of design changes, adjustments and new ideas that involves everyone. During project meetings we gather specific feedback on specific parts of the project, and to make sure we were at a reasonable position with a certain part of the site, we run through a checklist of what it accomplishes. If we were all satisfied, we commit to it as a main feature of the final product. As we keep pushing forward, we confidently put our pencils down and decide how that part of the site is going to work.
Visuals
How decisions are made
Visually, we experiment in a similar way. We present different stylistic approaches for a section of the site, and after conversation and a few tweaks, we commit to one of them. Often times we don’t need to go as far as asking dev to implement a variety of visual adjustments and ideas, but every now and then we do need to swap out some previous designs, solely because we came up with a better idea later on.
Jira approach to QA adjustments
As time goes on in a project, and the visuals come together with functionality, there are, of course, a few areas that needed to be touched on. As a team, we go over the project and as development progresses, we transition away from depending on our master design-to-dev handoff specification documents and design files. Relying on a master design-dev handoff doc makes it difficult to keep track of changes to specific areas or adjustments overal that needed to be made to the dev site after the doc is completelyed, so we delve deeper into Jira for QA based task creation for these change requests.
In this phase design and development happen simultaneously as well. Design changes pass a “development sanity check” before becoming a design mockup for review followed by small, descriptive issues created in Jira, added to our backlog of tasks to be implemented by Development.
The process works well as it gives us a lot of flexibility, allowing us to communicate more fluidly, having a more experimental approach to design without pushing the scope of the project too much. Another benefit is that everyone is involved a in the design, development and business decisions. People aren’t siloed off from one another and everyone’s voice is heard. Many of decisions ended up being a joint call and we were consistently on the same page.
