I believe that every product, every company, and every design team need a different process, suitable for their own needs, characteristics, restrictions, and competitive landscape, and I am flexible with any design process that your team is following.
The design process below is what I have followed for the projects in the past. I do not think that this process suits everyone; simply because no process suits everyone.
Step 1: Problem-spotting
I believe that problem-spotting is one of the most undervalued skills in the design field.
This is where our story starts. Most of the time, you will encounter a problem in your real life, whether it is a physical problem or a digital problem, and your journey will start from there. Perhaps, the most important thing is that a decent solution generates business value and that it is achievable within a relatively short time: You might build a well in a small town, and solve their thirst problem, but you won’t be able to solve the global shortage.
Understand the context of this problem: When, where, and how does it occur? As long as you think that you have a sufficient, even though vague, understanding of it, move to the next step: Don’t think over it, before doing any research; so you don’t marry to a pre-emptive solution.
Step 2: Problem-framing
The goal of this step is to verify and understand the problem in the most detailed way, and by the end of this step, the following questions are to be answered:
- What is our goal(s) with this product?
- Which tools suit the task(s) we need to complete for our goal(s)?
- What constraints do we face?
During this step, you will be conducting primary and secondary research, based on the constraints you have, such as time, money, energy, and available team members, and only then, you will be coming up with a problem statement. How detailed this statement should be, depends on you and your team.
Most of the time, I start with preliminary user interviews. I always prepare a core list of questions to ask my interviewees, but I let them talk about what they have in their minds concerning the core subject at hand: As long as you are open to listening, people will always share.
While conducting preliminary user interviews for Tomo, I learned from an interviewee that most of his fellow workers are extremely dissatisfied with the current task management tools. Even though I was designing it as a personal time management assistant, I have noticed that the core business proposition of Tomo, automated dynamic scheduling, can be used for task management by companies.
Then, given that there are enough resources before moving to the next step, I use surveys: They do not take much of participants’ time, any participant can complete a survey whenever they prefer, and it is much easier to see patterns in data. Almost in no case, surveys will be sufficient for your goals in conducting research; but it allows you to reach a much wider audience for a cheaper price. Most of the time, surveys should come after preliminary user interviews: You need to take a step into other people’s lives and understand them. This way, your survey will be much more in touch with reality.
Lastly, and I do not think that I can overemphasize this, I always conduct very extensive competitive analyses: We live in a tech world where there are infinitely many creative people, armed with extremely refined problem-solving skills, and the chances are that most solutions you have in your mind are already in the market. Learn from their successes, and failures, learn from their rights and wrongs. They paid a price for their successes and failures, but you don’t have to.
You have seen a product similar to the one you are just starting to design, but went out of business? Reach its co-founders: Even if 99% percent of their former customers were satisfied with the product, this does not suffice. Being a good product and being a profitable product are very different things, and our goal here is to create profitable products that meet business ends. Ask those co-founders why their business is no longer, and what they would do differently if they had another chance.
When you think that your understanding of the problem landscape is strong enough, move to the next step.
Step 3: Problem-solving
Always start with studying possible solutions to the problem you have framed in the previous step: You never have the best idea on your first try. Go crazy, even an idea that you think is the most stupid thing you have heard of can be extremely valuable on its completion, or its parts. Don’t be afraid to talk about what you have in your mind.
The product you are working on does not have to be ground-breaking, or completely new: Consider the tech landscape, with sooo many different products working on the same set of problems. Significantly improving an existing solution or combining the existing solutions into one product can yield much better results than coming up with a brand-new solution. You don’t win the game by being the first person there, you win it by being the best person there.
You don’t have to reinvent the wheel, just make sure you create a better one.
Tools and programming languages that you will be using are your constraints: Whether you use Figma (or Sketch, or whatever) or paper and pen, it does not matter much: Figma (or Sketch, or whatever) is better just for communicating your thoughts than pen and paper, but as long as you can communicate them with others, even by eye blinks, what tools you choose is just a matter of professional convenience.
Any design tool can be learned within a few days and can be mastered within a few weeks, anyway.
The important thing is to find a solution that meets the minimally acceptable criteria and build a product on it. Even if “solution” and “product” are used sometimes synonymously in this field, just know that a product is an embodiment of a solution: Every solution can be materialized into different products.
Once you have designed a product ready for the use of your users, then you are ready; and re-iteration begins.
Step 4: Back to problem-spotting.
In my opinion, what differentiates a beginner (not meaning a junior) from an expert (not meaning a senior) is how they deal with their users’ experience, and how they make their product better, based on the data they obtained.
The most important elements of this field are users and business, yet they are always intertwined. A better product generates more income, and more income enables the company to build a better product. I don’t believe that any designer can focus solely on one of these two. As long as you can improve your product based on your users’ experience of it, you will be fine.
To spot the current problems in my product, I love using usability tests: Even pure aesthetics of your product might make a huge difference, but if your product is not sufficiently usable (or God forbid, not usable at all), your current users will leave you (no one loves a breakup), and your business will lose its lifeline: Income. Usability tests, while might be not sufficient alone, will crack open the door of your users’ minds, and surely, you will learn a lot about them and from them.
Any designer, given that they have any time to spare, should be in direct contact with their users as much as possible: Conducting user interviews is industry-standard, but constantly checking your product’s Google Play Store and Apple Store reviews, your company’s Facebook page, and support tickets enable you to observe your users and their problems with your product in a neutral space where they express themselves freely, without an observer effect.
Once you infer that there is an issue with your product, then you are back to the problem-framing: It does not matter how big or small (not meaning its importance) the problem in hand is, as long as the resources allocated are proportional, every problem deserves equal attention: Opening your fridge and finding out that there is nothing to eat is a problem, just as the global shortage is.
This is the first draft, and there will be a second one quite soon.
I wish you’ve enjoyed reading this. Let me know what you think!
