Agile Design Workflow
Design can become a chaotic workflow, especially in an agile environment if not made accountable and measurable.
Context
Designing for an internal product
While working with a Fortune 500 company on their internal product, four products were to be consolidated into one. The development was phasing into the agile sprint model while the design was still pre-mature in the team. As the only designer on the product, it was on me to find a way to bring accountability, visibility and documentation approach in design to defend against misconceptions about design work, overload of work and bring efficiency in handoff. This gave rise to agile design workflow as a side project with the right environment to test it out.
Major Learnings
Accountability and visibility in the design process not only safeguard the designer from an overload of work but help realise design workflow styles while factually pointing out external inefficiencies that affect design flow
Non-design stakeholders
PM is the most important stakeholder out of developers, feature requesters(product stakeholders) and business folks. PM has the visibility of what process will work for all and can help optimise the agile flow. It was equally important to find out problems with design faced by other stakeholders on one-on-one interviews to design systemic agile workflow.
Agile method that considers exploration
By nature, design is exploratory; hence, the scrum model did not prove to be apt for this. Kanban is a better approach, as it is a flow model and can be tracked if blocked by an external dependency. It is very important to loop in stakeholders on the board to tag them for releasing blockers. This helps to close the discovery and framing phase efficiently.
Finding efficency
A few pointers help to make the design process efficient by multiple folds. First is to loop in the stakeholders who are blocking the progress while making it visible to the PM. Next is to create a parking lane for blocked tickets and tag identifiers for design tasks(exploration, wire-framing, handoff, etc) via labels. This helps work on inefficiencies in retrospections. Lastly, make sure to add all relevant people as watchers in the ticket.
Building the agile process
This is your Services section. This is a great place to give more information about the services you provide. You can write a general description of what your business offers then add more details below.
​
This section can be adapted for your website. You may choose to highlight other things like courses or programs, or to share special features about your business that you want to promote. Double click on the text box to edit the text and make it your own.
.png)
Process insights
1
Design<>Agile
The design workflow seems to be agile by nature. Both of them do not really have an end but just a mere milestone. If it does not work it loops back in an iteration cycle. If it works, it loops back in an enhancement cycle. Scrum model is also possible for design but it is highly subjective to the team culture and business processes & expectations.
2
People over process
Any process should help all stakeholders to grow. Processes are not to be enforced or adapted, but to be adopted willingly by stakeholders. Also, the Kanban I conceptualised has been working well for me. This does not mean it should work for all. Moreover, teams have adopted different swimlanes. What is important is to document and communicate the 'WHY' behind every decision. As long as the vision is intact, any modification will help the process evolve constructively.
3
Role of numbers
Graphs and numbers produced as a result of following a process need to be given a constructive narrative. If time and effort is not spent to find constructive insights, soon the feedback sessions are at a risk of becoming blame game which will cascade down to people fearing to follow the process honestly. This is also why I believe the 'WHY' behind the process decision is more important than the process itself.