My Design Workflow
The designer is both an artist and a craftsman. On the one hand he is looking for inspiration and wants to find something original, to mark the product with himself. On the other hand, there are standards, processes and repetitive actions. Below you will find the process when I start the new project.
Know the product, business expectations and what the customer problem this product solves
To solve a problem, you need to understand the product, its context and business expectations. Without this knowledge you rely only on experience and assumptions, and these can often lead you to bad decisions. So you gather information like a seasoned detective and try not to understand what's going on here.
Trying to understand the available data and what questions are not answered
The information you collect is like collecting data during an investigation. You check various sources, analyze data and try to find connections. You connect the dots and get to the point where you can "feel" the situation, the product and its problems.
Preparing a product structure that is simple, logical and expected
By understanding the context and the available data, you can prepare the product structure and indicate its improvements and simplifications. The risk of missing an important element is less when you have so much product knowledge in your head.
Product wireframes and test planning
While working on specific screens, a lot of questions will appear in your head. "Will it work?", "Will they notice it, understand?" That is why for me it is also a perfect moment to prepare a list of questions and doubts, from which you can create a User Testing scenario.
Product design close to target
Once we know what and how it is going to be built, we can focus on how it is going to look. At this stage we can also build a prototype, which will be useful not only for testing with users, but also for presenting progress inside the company.
Testing (if possible) of the project and the target product version after improvements
Testing and Research are critical to the success of the product. Not only do they give us confidence that something is built correctly, but they also reduce the cost of unnecessary development. In practice, however, many companies are in a hurry to release a live product and skip tests or want to do them later. At this stage, communicating the risks and possible costs of corrections is one of the main tasks I have in mind.