8 minute read
Search for 'product design process' in your favourite image search engine and you'll be met with an interesting split of opinions.
Some teams favour a very traditional, linear process. Various steps are defined, neatly siloed from each other, and deliverables from each step are neatly tied off and handed over before proceeding to the next.
This waterfall-style methodology certainly gets a job done, but doesn't lend itself well to the complexities of modern apps or the rapidly changing environment of web technologies.
I'm a passionate proponent of the alternative — a more agile approach. One in which reflection and revision are baked into the process from the start. Progress through the steps is initially much faster, but with the expectation that we'll regularly step backwards in our process to re-work our solutions as our understanding of the problem evolves.
There's still a strong linearity to this method, but it acknowledges how vulnerable each stage is to the insights we glean along the way and the recalibration/redirection that results.
So, what's involved through each stage?
This is the stage that a lot of our "Why?", "What?", and "How?" questions should be asked. If we're opening Sketch at this stage, we're probably doing it wrong.
This is our chance to fill in blanks in our understanding, either with user research or competitor analysis. And no, it's still not the time to be reaching for a design tool!
By this stage we've hopefully done our due-diligence and we can speak confidently on behalf of our users. We should have a clear sense of what challenges they face and how our end-product will improve their experience.
Taking a tool-agnostic approach, work up whatever assets are needed to quickly and efficiently communicate thinking, be that sketches on paper, low fidelity wireframes, Sketch files, static HTML prototypes, or a Git branch of the actual product.
The key here is speed. Your first pass at designs is not to meant to produce a finished product. You just need an adequate enough representation of your thinking that you can begin to prove it with users and stakeholders.
Armed with designs/scribbles/prototypes, we can now begin to learn where our understanding ends and assumptions begin.
Given the costliness of testing with users, it pays to get these early-stage concepts in front of knowledgeable team members as a priority. Engineers, project managers, support staff, stakeholders, etc. can all give valuable insight before you commit to user interviews.
Whatever the feedback, prepare to be jumping back and forth between 'Ideate' and 'Prove' quite a bit…
Gone are the days of 'throwing a design over the wall' and leaving an engineering team to decipher your intentions. Even if you've carefully prototyped your interactions and designed all your error states, digital projects still have a way of throwing you curveballs during the build process.
Once you've got a solution signed off, carry on championing your designs throughout the implementation stage, and be prepared to pair with engineers on
Shipped? Nice work! The next big project is probably pressuring you to move on, but launch day shouldn't be seen as the end of our process. Following up on a project gives us a chance to learn from both our successes and missteps.