Łukasz: Tell me, how does your work look like at Pragmatic Coders?
Anna: Working at Pragmatic Coders is different from a typical product company as here many products are being developed instead of only one. Our goal is to help startups get their products to market as quickly as possible. We want to check the assumptions developed during the research as soon as possible. We test whether they are good or meet market needs.
To achieve this, we need to focus on the essential functions of a given product. It is not important to improve the product at the initial stage but to determine what is necessary to implement the MVP (Minimum Viable Product).
Ł: I think it isn’t easy to find an answer to the question you asked. How do you determine what to include in the MVP?
A: It is not just my decision. We undertake it together with the Product Manager, team, and client. First, we need to define the problem we want to solve. Consider potential solutions, consult these ideas with programmers. We look at what the user needs most, what can be programmed the fastest, what is the most important from the UX point of view. The decision on the content of the MVP is a sensible compromise between different perspectives.
Besides, the so-called “Nice to have” list is created. This list may include some cool animations or components that need to be crafted from scratch, items for which there is no time at such an early stage.
Ł: From what I hear, you see the problem and potential solutions from many different perspectives. Are you contracting the MVP scope, and what’s next?
A: Together with the Product Owner (PO), we develop an action plan. We divide a given function into the first and second stages of implementation. The first version is the most hewn; it just answers a specific problem. The second iteration is a full feature that provides good UX.
Thanks to this approach, the end-user quickly starts working with the product, which brings value to the business.
Contact with real users is of great value to us. We check the response, interest, and try to talk to them if that’s possible.
Ł: How do you involve the client in creating the product?
A: We have contact with the customer all the time. Every day, through meetings or a conversation on Slack. Now and then, we organize “Design Sessions,” where the client talks about business needs. Then together, we try to find solutions that will be useful. We check the context of the product’s operation and why a given function is desired. We ask questions to help understand the context. Then we work out how the product is supposed to work.
Ł: Does the client come with a ready list of functionalities, and you are wondering how to implement them in the best possible way? Or does the client not have a complete list, and you are working with end-users to develop functionalities?
A: It depends. For example, in the current project, before the product was released into the world, we had to make assumptions, there was no time to research the market, and there was no contact with end-users. Later, we completely removed some inferences from the product. It turned out that the reality is entirely different.
When a product begins to live its own life and serve users, new business needs arise that we could not have foreseen and which need to be addressed quickly.
Ł: What do you think is the most crucial element of your work?
A: For me, the essential thing in the work of a Product Designer is good communication with the client, cooperation with the technical team, and feedback from end-users. Thanks to this, from the UX perspective, we provide valuable products that do the job they were supposed to do (JTBD) and do it well.
I’ve also noticed that when technical people are involved in the design process and given the possibility to influence how a product feature is supposed to work are later more involved in developing the application code. I know that they feel like co-authors of this solution.
Ł: So you are saying that the entire team’s early involvement influences the motivation?
A: Yes, but I think in Pragmatic Coders, it’s not only early engagement that helps make a product successful. In our company, programmers have their motivation and passion for software development.
Ł: Suppose you come across a person with whom you disagree entirely about a given feature of the product. How do you solve this situation?
A: Few people like to do things with which they disagree. The work is then more difficult than on the solutions that have been agreed upon with the person. In such situations, there is a discussion of arguments. Sometimes there is a stalemate, and you have to involve another person to get to know their point of view.
It is hard to get rid of such strictly human beliefs as “I think it’s better this way.” It is worth recalling that the product is not for the team member but the end-user. I try to use strictly substantive arguments. Sometimes it is me who is wrong 🙂.
It is essential to assume that iteration is necessary to achieve success at the very beginning of your work. In the current project, I had three approaches to one product function, but we are convinced that we have worked out the best possible solution.
Ł: How do you know when a product or part of it is good?
A: In the case of a working product, the functionality must work well from the UX and back-end perspective. Sometimes it’s impossible to separate the two. Because if a feature does not work in terms of technology, then it is difficult for me to assess whether a given solution is right in terms of UX. It is crucial to check whether the given function of the product is being used. I often use the https://lookback.io/ tool.
Also, we get feedback from the customer about the product and how users use a given function or what they experience troublesome.
Ł: Recently, what new thing have you learned that helped you in your Product Designer work?
A: After joining Pragmatic Coders, I learned how to “trim” a product scope and reduce design time. It seems that this can be troublesome for the designer because you often seek the comfort of time while working on one product.
At Pragmatic Coders, I have learned that focusing on the most critical things in situations where time matters because we want to launch the product on the market as soon as possible results in looking for the most accurate solutions and focusing only on them. This is really cool.
Recently, we have been doing Proof of Concept (POC) for a client. We gave up a few product features that would not be included in the POC because they did not add value at this stage. There was a fascinating discussion. This kind of education does not come from school.
Ł: What design tool has surprised you positively recently?
A: I recently refreshed the capabilities of the https://www.protopie.io/ tool because a lot more features have come in since I was using it. The tool allows you to create a clickable prototype that looks like the target product.
Ł: Where do you get the knowledge about new trends in product design?
A: I really appreciate UX Collective, and I read https://uxdesign.cc/. They describe various exciting design issues and problems in their articles very well. For example, I recently read an article on how to start being a designer. I wanted to send this article to a friend at the Academy of Fine Arts for him to show students who are getting started with designing applications. Their vision of how it should be done later clashes with reality quite strongly.
I get much knowledge from the N / N group https://www.nngroup.com/. I appreciate https://cadence.cc/. I highly recommend the book “Start With Why” by Simon Sinek. I believe everyone should read it. When I say everyone, I mean a designer, technologist, or product originator.
Ł: Thank you, Ania, for the meeting.
A: Thank you too, 🙂. This was probably my first interview in my life.