Are you interested? Call us!

Ti abbiamo interessato? Contattaci!

Zainteresowaliśmy Cię? Odezwij się!

Check what we have been living lately

Scoprite con cosa abbiamo vissuto di recente

Sprawdź, czym ostatnio żyjemy

Do you want to know our offer and talk about the needs of your business? Write to us, we will surely find the best solution.

Leave a number. We will call you back within 30 minutes.

Chcesz poznać nasza ofertę i porozmawiać na temat potrzeb Twojego biznesu? Napisz do nas, na pewno znajdziemy najlepsze rozwiązanie.

Zostaw numer. Oddzwonimy w przeciągu 30 minut.

We bring value by using the best, the most reliable technologies available on the eCommerce market. Our team makes sure that our clients have the ability to achieve their business goals in a way that is safe, predictable and at the highest level.
We have been operating since 2011, and our team consists of 80 people whose competences and knowledge are certified. Our goal is to always achieve the goal, and our know-how is the selection, implementation and development of the best and the most reliable eCommerce technologies. The success in Europe, Asia and North America, along with our experience in numerous industries and in various business models have established our position in the eCommerce world. However, as we believe that the only constant is change, we remain one step ahead at all times, following global trends in the online sales market.

This website uses cookies. By staying on this website, you consent to the use of cookies. Find out more on the <a href="/en/privacy-policy"> website </a>.

Monogo has joined the elite club of Business Gazelles, a group of the most dynamically developing polish companies.

Business Gazelle 2022 for Monogo

Featured products:

<a href="tel:+48531338668">+48 531 338 668</a> <a href="mailto:hello@monogo.pl">hello@monogo.pl</a>

Monogo

Lublin (HQ)

Aleje Jerozolimskie 181, 4th floor Poland

Warsaw

Parkland, 7527 NW 61st Ter, Florida USA

Florida, USA

Parkland, 7527 NW 61st Ter, Florida Usa

<a href="tel:+48531338668">+48 531 338 668</a> <a href="mailto:hello@monogo.pl">hello@monogo.pl</a>

About Monogo

E-Commerce

AI AND AUTOMATION

CLOUD INFRASTRUCTURE

KNOWLEDGE BASE

KONWLEDGE BASE

Questo sito web utilizza i cookie. Restando su questo sito acconsenti all'utilizzo dei cookie. Scopri di più sul sito web <a href="/en/privacy-policy"> </a>.

Prodotti sponsorizzati:

AI E AUTOMAZIONE

Akeneo PIM – here we go

I have been designing user interfaces for over 10 years. I've seen big ideas fail despite huge budgets, a committed team and a theoretically good product. I wondered what this was due to and promised myself that when I was more empowered I would not allow failure. I started to analyse products that had failed or not even launched, as initial user feedback indicated that the product did not solve any of the problems they were facing. Often they were something 'fancy' but didn't actually change the customer experience in a significant way. At other times, they were based on an almost dogma - our customer will accept anything and no matter how 'fancy' the process is, they will still humbly go through it. Of course, in the end there was a verification and a clash with reality.

core/paragraph

I have been designing user interfaces for over 10 years. I've seen big ideas fail despite huge budgets, a committed team and a theoretically good product. I wondered what this was due to and promised myself that when I was more empowered I would not allow failure. I started to analyse products that had failed or not even launched, as initial user feedback indicated that the product did not solve any of the problems they were facing. Often they were something 'fancy' but didn't actually change the customer experience in a significant way. At other times, they were based on an almost dogma - our customer will accept anything and no matter how 'fancy' the process is, they will still humbly go through it. Of course, in the end there was a verification and a clash with reality.

What did all these failed products have in common? They had one common denominator - they only pursued business goals, without involving the user in the process. That's for sure. Another distinguishing characteristic of unsuccessful products is the focus in the analysis phase only on the functionalities that the customer provided. This is often done by the client providing a document describing the product they want to create. The development team then prices the 'coding' of these functionalities, a timeframe is set, mock-ups are created somewhere and... it begins. Suddenly, it turns out that the functionalities described in the request did not include some aspects that came up when the designer started drawing the mock-ups and thought empathetically about the end user, or some functionalities were missing to be able to successfully go through the whole process as a user at all. What causes this? It has cosmic consequences - because the time of the project changes, the price of the project also changes and we start to lose control over the final form of the product. In addition, we are never sure that everyone understands the product in the same way and what the main goal of the project is. And ultimately - is our goal the right one at all? To answer this question - all we need to do in the analysis/discovery phase is to find space for workshops in the design thinking methodology. But what is it really all about?

What did all these failed products have in common? They had one common denominator - they only pursued business goals, without involving the user in the process. That's for sure. Another distinguishing characteristic of unsuccessful products is the focus in the analysis phase only on the functionalities that the customer provided. This is often done by the client providing a document describing the product they want to create. The development team then prices the 'coding' of these functionalities, a timeframe is set, mock-ups are created somewhere and... it begins. Suddenly, it turns out that the functionalities described in the request did not include some aspects that came up when the designer started drawing the mock-ups and thought empathetically about the end user, or some functionalities were missing to be able to successfully go through the whole process as a user at all. What causes this? It has cosmic consequences - because the time of the project changes, the price of the project also changes and we start to lose control over the final form of the product. In addition, we are never sure that everyone understands the product in the same way and what the main goal of the project is. And ultimately - is our goal the right one at all? To answer this question - all we need to do in the analysis/discovery phase is to find space for workshops in the design thinking methodology. But what is it really all about?

Design thinking is primarily based on empathy. Empathy is the most important quality that helps us understand the needs of others. We want to understand the end user - it is for them that we create the product. We try to map the user's needs and business goals and bring them together in harmony. To understand the user we use empathy maps. This is a simple map that focuses on several aspects. What the user thinks, hears, says and does. Filling in this chart allows us to place the user and the product in a specific context - a situation in which we have to navigate as suppliers. This has one important aspect - we are sure that both the client and the project team perceive the user in the same way. Imagine a football team where the defence and the offence analyse the opposing team separately - in two different rooms. It's hard to have understanding during a match in such a situation. What the design thinking workshops manage to bridge is the difference in the tower between the customer and the supplier. We form one team playing to one goal. Then when we understand the user, we have empathy maps filled in, we slowly start to define the goal of the product. To define the goal, we need to define all the pain points of the user and the business. There are several methods for defining these pain points - they are chosen according to the group present in the workshop. We can use simple brainstorming, the 'roses, thorns and doughnuts' method or a number of other methodologies, which I will describe in the next article. The consequence of this stage is a map or board of all the ills we want to address.

Design thinking is primarily based on empathy. Empathy is the most important quality that helps us understand the needs of others. We want to understand the end user - it is for them that we create the product. We try to map the user's needs and business goals and bring them together in harmony. To understand the user we use empathy maps. This is a simple map that focuses on several aspects. What the user thinks, hears, says and does. Filling in this chart allows us to place the user and the product in a specific context - a situation in which we have to navigate as suppliers. This has one important aspect - we are sure that both the client and the project team perceive the user in the same way. Imagine a football team where the defence and the offence analyse the opposing team separately - in two different rooms. It's hard to have understanding during a match in such a situation. What the design thinking workshops manage to bridge is the difference in the tower between the customer and the supplier. We form one team playing to one goal. Then when we understand the user, we have empathy maps filled in, we slowly start to define the goal of the product. To define the goal, we need to define all the pain points of the user and the business. There are several methods for defining these pain points - they are chosen according to the group present in the workshop. We can use simple brainstorming, the 'roses, thorns and doughnuts' method or a number of other methodologies, which I will describe in the next article. The consequence of this stage is a map or board of all the ills we want to address.

The problems need to be looked at broadly. Think about every contact a user has with the brand and map out all the pain points. We then select the ones we want to solve first - with the greatest benefit to our business and the user.

The problems need to be looked at broadly. Think about every contact a user has with the brand and map out all the pain points. We then select the ones we want to solve first - with the greatest benefit to our business and the user.

Stage three is the most enjoyable stage, as this is where we start to focus on solutions to the problems previously detailed. This is where the picture of our product begins to be drawn. Many times in projects, stages one and two are forgotten, starting straight away with ideas. Customers may carry out an internal analysis of problems and customers, but without the participation of suppliers there is cognitive dissonance. The supplier does not understand why they are creating the product - which leads to frequent misunderstandings. However, with problem-solving ideas, we can define the goal. When everyone understands the purpose, we can move on to the next stage - Mock-ups and prototyping.

Stage three is the most enjoyable stage, as this is where we start to focus on solutions to the problems previously detailed. This is where the picture of our product begins to be drawn. Many times in projects, stages one and two are forgotten, starting straight away with ideas. Customers may carry out an internal analysis of problems and customers, but without the participation of suppliers there is cognitive dissonance. The supplier does not understand why they are creating the product - which leads to frequent misunderstandings. However, with problem-solving ideas, we can define the goal. When everyone understands the purpose, we can move on to the next stage - Mock-ups and prototyping.

While everyone understands what mock-ups and prototypes are, not everyone appreciates their preparation as part of the analysis or discovery phase. Often, the mock-ups come after the functionality analysis and cost estimation. This approach generates several problems, which I mentioned in the introduction to this article. We cannot accurately determine all the functionalities without mock-ups and the final cost of development when we cannot see what the product looks like. If you want to control costs and time accurately then you should ask the supplier to prepare mock-ups (can be wireframes of the main functionalities and paths) as part of the analysis. As well as being able to determine the cost - you can see an outline of your product and whether it meets a predefined need. The biggest treasure trove of mock-ups, however, is the ability to conduct the next stage - testing.

While everyone understands what mock-ups and prototypes are, not everyone appreciates their preparation as part of the analysis or discovery phase. Often, the mock-ups come after the functionality analysis and cost estimation. This approach generates several problems, which I mentioned in the introduction to this article. We cannot accurately determine all the functionalities without mock-ups and the final cost of development when we cannot see what the product looks like. If you want to control costs and time accurately then you should ask the supplier to prepare mock-ups (can be wireframes of the main functionalities and paths) as part of the analysis. As well as being able to determine the cost - you can see an outline of your product and whether it meets a predefined need. The biggest treasure trove of mock-ups, however, is the ability to conduct the next stage - testing.

The mock-up or prototype testing stage allows the solution to be evaluated by a focus group - i.e. real users. It is here, using Maze or other tools, that you have the opportunity to test the whole concept, or main trends and paths, before releasing the development budget. This is where you find out if your product meets business and user expectations. This is a good time to back out of unnecessary features or add what might make for success. You get a report, data, figures and on this basis you can decide on the final shape of the product.

The mock-up or prototype testing stage allows the solution to be evaluated by a focus group - i.e. real users. It is here, using Maze or other tools, that you have the opportunity to test the whole concept, or main trends and paths, before releasing the development budget. This is where you find out if your product meets business and user expectations. This is a good time to back out of unnecessary features or add what might make for success. You get a report, data, figures and on this basis you can decide on the final shape of the product.

You already know what design thinking is and how it can help you with budget planning and determining the final form of the product. But how do you implement this methodology in such a way that you can apply it to agile projects? It's relatively simple. Many of the teams I've had the opportunity to work with follow this approach:

You already know what design thinking is and how it can help you with budget planning and determining the final form of the product. But how do you implement this methodology in such a way that you can apply it to agile projects? It's relatively simple. Many of the teams I've had the opportunity to work with follow this approach:

Analyst defines the problem -&gt; Task goes into backlog -&gt; mockups are created -&gt; development -&gt; solution tests

Analyst defines the problem -&gt; Task goes into backlog -&gt; mockups are created -&gt; development -&gt; solution tests

core/image

core/column

core/columns

my proposed process in the spirit of design thinking:

my proposed process in the spirit of design thinking:

Analyst defines problem -&gt; mock-ups are created -&gt; solution tests -&gt; task goes to backlog -&gt; development.

Analyst defines problem -&gt; mock-ups are created -&gt; solution tests -&gt; task goes to backlog -&gt; development.

The difference is apparent. Already tested solutions at the mock-up stage go into the backlog. Of course, post go-live analysis is recommended but we reduce the risk to market of an inadequate product to a minimum. We also reduce the number of iterations and code changes to a minimum. Finally, the last point - we can launch the bare minimum, solving the biggest pain points, rather than taking an almost 'waterfall' approach to the product - all functionality at once. As long as we have hit the users' needs, the 'waterfall' approach is not bad. It's worse if we have spent a year or more creating a solution that does not address market needs and, because of a lack of testing at the mock-up stage, we have failed to notice the problem.

The difference is apparent. Already tested solutions at the mock-up stage go into the backlog. Of course, post go-live analysis is recommended but we reduce the risk to market of an inadequate product to a minimum. We also reduce the number of iterations and code changes to a minimum. Finally, the last point - we can launch the bare minimum, solving the biggest pain points, rather than taking an almost 'waterfall' approach to the product - all functionality at once. As long as we have hit the users' needs, the 'waterfall' approach is not bad. It's worse if we have spent a year or more creating a solution that does not address market needs and, because of a lack of testing at the mock-up stage, we have failed to notice the problem.

The design thinking approach helps not only to deliver products that are beautiful and useful, but also to optimise the budget. If you are interested in implementing design thinking in your organisation or in your product development process - contact me for a free, no-obligation consultation:

The design thinking approach helps not only to deliver products that are beautiful and useful, but also to optimise the budget. If you are interested in implementing design thinking in your organisation or in your product development process - contact me for a free, no-obligation consultation:

core/button

<div class="wp-block-button"><a class="wp-block-button__link" href="https://calendar.google.com/calendar/u/0/appointments/schedules/AcZssZ31GSepTin1DcRcuj3E8j_fOUqB8KFDjx2UrZDgZoqRW6iw78ZDxTJ0_mi7vj6j2TU2CByHuVlP" target="_blank" rel="noreferrer noopener">Book a consultation date</a></div>

core/buttons

IT projects are created based on requirements collected internally by the client and workshops detailing the scope of the project. The supplier prepares a quote, if there is an agreement on the budget and expectations then the project team proceeds to create the product. Then all that's left is the production launch. Further on, we have changes due to user needs. We recognize this as a normal state of affairs, but is this a good approach? Can we limit the number of post-implementation changes so as to maximize the budget for developing only the needed functionality, creating the perfect product? It turns out that yes - the answer is Design Thinking and User Centered Design.

The power of design thinking in designing for IT

5 rzeczy, bez których Black Friday będzie porażką w Twoim sklepie

Is Magento the Best Ecommerce Platform Out There

Adobe Summit 2024  – 3 highlights from the conference

Monogo: AI media opitimisation in e-commerce