I have often contemplated the need to put down my thoughts, especially in a blog. Isn't it enough to just have it as a journal for personal reflection? Should it be open to the world? The vulnerability that comes with it is the need to be factually correct, or rather, the fear of being ridiculed if the personal biases get found out.
The last two posts have been immensely helpful to me, as a reminder of a thought nugget, a framework borne out of experience, or an avenue for thought experiments. The fact that it is published helps me easily refer to it from anywhere in the world and from any device. It also helps me to remind myself of the thought journey; to use some of the wisdom acquired in the past to be applied to problems in the future, lest I forget.
There is also another aspect to it that is hardly ever mentioned by anyone. The fact that following one'sown advice is always the hardest and most ignored.
If photographs are the visual representation of a point in time, I believe writing is a representation of thought at that particular time. Thought could be seen as a process, outcome, or maturity. The story of the thought would be complete only when looking backwards (and in the future).
This is part 2 (and a more detailed explanation) of the series on Test-Driven Design approach. Read Part 1 here.
Why Unit Test Case?
If development, despite containing thousands of lines of code, can function well, there's surely something right about that approach that we can look into. Also, how can we remove the subjectivity associated with UX and UI design? Metrics are effective once the product is shipped; a scientific approach, to how design is optimised, can greatly enhance the ability to solve some of the core product issues. After all, theories and concepts are formulated by testing hypotheses.
What if we define the assumptions of a user and their behaviour at the very start of the design process? Test the assumptions first, before taking the product to the actual users. Test, modify and refine the assumptions. This will help us gain a deeper understanding of the targeted user(s).
The design process or the art of crafting, now, becomes less about the designer's preference and more about the user. How it is supposed to be, in an ideal world. What this could lead to is an obsession to find out what the user really wants, taking into account the beautiful ways our mind behaves irrationally on various occasions.
Breaking down the user interaction journey into multiple test-cases helps us solve targeted areas of behaviour through optimisation. Think milestones. Each test case has to pass at the behavioural level, for a successful completion of the user flow. Or what if we set the milestones based on behavioural cues instead of technical steps, unlike how it is done currently? It makes complete sense for developers to label it that way because they are engineering it. But designers' goals are different. Let's take an example of a small scale e-commerce or D2C app: sign in > product listing > favourite, etc are reframed to user encountering the brand for the first time, getting to know more about it and then gaining more controls over the product feature, evaluation, shortlist, and so on. Reframing makes the actions that need to go into getting the desired outcome different too.
Would a scientific method reduce the creative 'gut' abilities of a designer?
No. The goal would be to make it pass the unit-test case, putting the designer(s) in a better position to use their creative abilities for a well defined goal. Constraints bring out the best ideas, showcasing the value of creative thinking to a greater extent for the product team.
We have come across Test-Driven Development (TDD) used in Agile methodology. The iterative method of writing a unit test, which fails at the start and progressively passes the test, has become fairly popular in the dev world. Now, what if we borrowed this analogy for design practise?
Instead of getting into the flows, sequencing, and fixing elements on any particular screen, we begin with the first and fundamental question.
"Why would or wouldn't a user use this product or service?"
We could make a list of friction factors that would come into play; including lack of motivation and needs. Well, I know what you're thinking: this could potentially derail the purpose of the product. When there is so much funding that goes into product development, which is likely the reason you're employed in the first place, why would we question the very existence of the product!
Not necessarily in a bad way, though. Knowing the shortcomings about why a user would not prefer to use this product is a very good starting point to solving problems in the long run. The approach, now, shifts to creating and convincing the value of the product to the user. Looks like a more real-world scenario, doesn't it! While the point is not to suggest that we need to bombard the user(s) with information at every step on why it is useful for them, we need to be well aware of what other factors (or friction points) could come into play to derail them from the flow.
This is a good way to incorporate the mental models of users early in the design process. For each step, consider the factors (external and internal) that might influence the user to drop off. You can use wireframes or low-fidelity designs to come up with creative solutions to fix it until, you think, will keep the user engaged. The result might look totally different from other applications on the market. That is okay, as long as you're addressing the needs of users better. Test it internally. Take it one step ahead: test it with real people, who you think, would resemble an actual user of the product.
Perfection is an art; mastered in stages.
Whether we can also call this a value-driven or an impact-oriented approach, does not really matter. Outcomes do.
