A lot of people will ask about my process, and while its difficult to answer without proper context.

In an effort to apply the blanket process to all design challenges ever, I'll prefer to follow the double diamond approach:

diverge. converge. diverge. converge.

Discover. This is really about the problem space, making sure we are solving the right problem. We'll try and gather as much insight into the space as possible and gain context for the next step.

Define. Here is where we would want to narrow down the focus to a point. We want to be able to define and come up with a problem statement as an output. A problem statement is something that everyone can agree on and needs to agree on before moving ahead.

Develop. I think of this double diamond process as being used in many places in a product lifecycle, here we could be talking about developing our designs and prototypes to begin testing at that level. Whereas at the same time this is where developers might be developing builds and having QA done. Same same but different. Basically we are looking at all the potential solutions.

Delivery. This is where we are either releasing to the market/production, or we'd be about to start sprint 0 and are preparing designs for production (where the process comes full-circle and starts again). The focus is on delivering solutions that work and then collecting valuable feedback to educate the next iteration.

I get that as a designer working in this way is a bit of a luxury nowadays. It seems like most bigger companies still really struggle with agile unless they have broken off their tech/innovation arms from the larger group.

Being able to have an adequate ramp up and research (discovery phase) will help ensure the success of the agile delivery. We want to bring developers, pm's, qa's, basically everyone who has buy in along the journey will us.

This ensures there is no design easter eggs for the team when we enter sprint 1 and being the delivery phase. It just doesn't work as well when solutions are chucked over the fence at team members who will need to make sense of things.

That being said, once potential solutions are validated and iterated on then we could move on to mapping out a roadmap for delivery and start gathering requirements for implementation.

When designing in sprint, i feel its best to become another developer. Try an learn as much as you can about developing and what their challenges are. You should already be familiar enough with the solution, so it really becomes about solving problems that come up on the fly or were simply unknown during the previous phase.

Anyway these are just some of my ramblings, i don't expect this to be on medium anytime soon. lol.

Words by @zacdicko / Powered by Super