I was recently asked about my approach to designing software, and my initial reaction was that I would have no problem explaining my method, having worked as a designer for 20+ years. But the reality was, I had to stop and think for a moment about exactly what that process entailed. I do have a design method that I find highly effective in the software development process and I follow it consistently, but at this point in my career it is more of an instinctive process rather than a specific checklist I follow.
However, in reflecting on the different products I’ve designed, I found the commonality among them all, regardless of product or scope of the project, is that my design approach is to move the concept from the initial 60,000-foot idea into a user-centric design solution that meets the business needs.
Still, telling someone that I “do stuff” isn’t very helpful. So, I began to run through my thought process when working on a new product and capture the details in a shareable medium. Since I design primarily in the software world, I thought the best way to show my process is with a diagram.
For those familiar with software design, this isn’t some groundbreaking method. Many designers in the industry tend to use at least some version of these steps. What the diagram does show is that each step in the progression builds upon the knowledge coming out of the prior step. The progression is fluid in that there’s often movement back and forth between the different steps outlined above, updating the living documents created in each step as additional information is uncovered and we learn more..
Starting at the left of the diagram, I begin with design thinking in order to understand the users, the impact the problem has on them, their motivation, and the barriers they’re running up against. This foundational data gathering allows me to better explore the problem space in the context of that user and begin to define the process and workflows that will address their needs. It helps me to craft a strategy on how we can solve the problem.
From there, I move into user experience design and start sketching out how the flows translate into screens. Each iteration and refinement of those ideas brings the design from a rough sketch into low-fidelity wireframes, ultimately finishing out the final designs in high-fidelity wireframes or prototypes. The end result is having designs that visually show the look and behavior of the final product.
An integral part of designing software is incorporating research and feedback throughout the design process by involving the client stakeholders and end users whenever possible. Their feedback helps to validate and/or course-correct the design direction, and is invaluable in uncovering any gaps in my thinking. As we all know, it’s much quicker to course correct at this stage than after the software is released.
In summary, yes, I “do stuff.” BUT I do it by employing a method that is repeatable yet flexible enough to meet the needs of a project.
Alice Toth
