The tried and tested double diamond process with a healthy dose of flexibility and experience driven intuition.
My experience in both business management and manufacturing has deeply informed my product development style. Toyota’s Six Sigma technique for process improvement applies just as well to modern day digital products as it did to automotive development. Teams must systematically gather customer feedback to garner actionable insights.
Experience of multiple product roles has led me understand the importance of understanding the initial needs of stakeholders. At first these requirements may be quite nebulous, and so I often use face to face interviews to get the heart of certain business objectives. The questions will obviously differ depending on the project, but at the core of it I look to understand the business imperative that drives the project, the surrounding context and any supporting evidence or current research that can form a good jumping off point. There are also technical, operational and business specific constraints that may need to be understood as early as possible to ensure potential solutions are feasible.
The questions will obviously differ depending on the project, but at the core of it I look to understand the business imperative that drives the project, the context surrounding that drive and any supporting evidence or current research that can form a good jumping off point. There are also technical, operational and business specific stipulations that may need to be adhered to. These are very important to understand as early on in the process as possible so that solutions can be tailored around them.
In every piece of work I do I ensure there is both qualitative and quantitative data supporting my design ideas, which allows for a more fruitful discovery process. The ideals of Poka-yoke (ポカヨケ) have always fascinated me, and has been a key driving philosophy. Through understanding the core of a problem the most ideal solution is one that eliminates the potential for error. In consumer products this act of mistake-proofing can vastly eliminate the frustrations of the user.
At this point in the project it is extremely useful to try and define some problem statements that help ground any future ideation. Problem statements are usually a few sentences at the most, and provide a strategic guiding metric. In order to get to a problem statement that is both valid and relevant I often undertake a heuristics and competitor analysis of the current solution (if there is one). Paired with any quantitative data that is available on user behaviour I can start to build a picture as to why products or features may be under-performing. If these processes don't yield enough understanding to start pulling together problem statements I often use remote or in-face usability testing to see first hand which areas users' are currently struggling with. If budgets or time is tight I am also experience in using user behaviour tracking tools, such as Hotjar, which allows you to view video clips of users' as they use a product.
If these processes don't yield enough understanding to start pulling together problem statements I often use remote or in-face usability testing to see first hand which areas users' are currently struggling with. If budgets or time is tight I am also experience in using user behaviour tracking tools, such as Hotjar, which allows you to view video clips of users' as they use a product.
To supplement the initial user research and dig a little deeper into user frustrations I often build journey maps, which look to draw out and visualise the current touch-points the users' interact with, and the levels of frustration or dissatisfaction at each step. This can be built during a workshop with stakeholders using all the data captured so far so that everyone is on the same page as to what in the current product is under-performing.
As a journey map is usually attributed to a certain user group it is good to utilise any personas the organisation has built to ensure we are addressing the correct needs for the correct segment. If personas have not yet been built I often like to spend time undertaking interviews with users', if the budget and timeline permits it, to truly understand what motivates certain users. This is extremely important when thinking of building new products, as it can help define what areas of their current lives this new product or feature will fit in to.
User flows allow a visual representation of a users' steps within a product. They are more low level than a journey map and so is more useful when determining how complex or long a journey truly is in practice. Once flows have been defined for each user group and status it is much easier to make sure no users' are forgotten about further down the ideation process. Often at this point it starts to become quite obvious which journeys can be simplified or re-imagined.
"Turn off your mind, relax and float down stream" - John Lennon
Now I have a good grasp on the current journeys, user frustrations and technical constraints it is time to look at potential solutions. Usually I start on paper or in a rough design file, caring less about fidelity and more about rapidly creating and testing ideas. At this stage it is a great idea to get the full product team and some stakeholders involved, as they may have ideas borne from their subject matter knowledge or experience. Although I used to exclusively use Sketch, I have begun to use Figma as my day to day design tool. The prototyping and collaboration features really speed up the process of getting an idea to a point of prototyping.
Once a few ideas have been fleshed out and have survived the test putting them in front of colleagues I find it useful to build one sentence hypotheses for each potential solution. This gives each option a little more weight behind them and ensures your reasoning for believing they will work is both rational and thought through.
At this stage there are usually few potential design solutions that bubble to the top, and once I add some draft content and flesh out the prototype I will undertake usability testing to understand which elements of each design are most intuitive. I have experience with both face to face moderated and un-moderated testing.
My style is open and inquisitive, prefer to let the designs speak for themselves to more adequately tease out areas of confusion. At a minimum I would test with five users that fit our target demographic, and repeat the process if multiple view-ports need to be evaluated.
I closely work with visual and UI designers during my design process. I have experience setting up design systems (using atomic design principles) and style guides, and often I can pull together high fidelity designs myself. If I believe the design would benefit from having a dedicated visual designer to take it over the line I can work collaboratively to ensure all usability and accessibility improvements are maintained.
Recently I have been using Zeplin as the repository for finalised designs. I ensure all design system components are also aligned within Zeplins' new styleguide integration. This ensures developers can interrogate designs are start using reusable modular components where possible. I have years of experience working closely with developers and am more than happy to demo and present designs fully to ensure they know exactly what to build. I also understand HTML, CSS and Javascript principles thoroughly, and so I am able to answer any questions concerning breakpoints, grids etc.
It is always important to understand how your new or updated products are performing, and so I will always monitor metrics post launch. Oftentimes my designs will bake in feedback loops, such as customer feedback forms to create natural qualitative channels that can be used for future product road mapping.
I also have experience with continuous improvement and conversation rate optimisation projects. Here I outline a series of potential optimisation tests that can be run through platforms such as Google Optimise. This approach can be very useful when you want to quickly test tweaks in design and get them to market rapidly.
