<p>Published on <a href="http://ift.tt/2lHkSuB">| Prototyping: From UX to Front End &mdash; Medium</a> muditha batagoda </p>
<h4>How Not to Mess up as Product Designer</h4>
<p><img alt="" src="http://ift.tt/2mDaTeZ"></p>
<p>As a product designer, I always wanted to design cool things that people would love to work with day in and out in their everyday use, no matter whether they are using them in their work, at home, way home or in the gym. Designing is an addiction when it is your hobby. That happy feeling when you get when your designs are recognized and valued by your clients is the best feeling that you can get when you are a product designer. But there is a huge problem some product designers encounter in their day-to-day work. It is to work with extremely conflicting requirements coming through different channels for the same problem that the designer is trying to solve.</p>
<h4>Why does that happen?</h4>
<p>Usually, the requirement comes from the client, and the product/UX designer couple with a Business analyst (or him/herself) to talk to the client and understand what they want. This helps us understand what client expectations are for the product. If the product designer does not have first-hand experience with the client, it will distance the them from asking the best questions from the perspective of the user. The client and the product designer should have proper communication so the client actually knows what happens in the product, and so the product designer has total understanding of the product design or revamp being done. If the communication channel is broken the product will have a bigger risk of being a failure, no matter how cool the product ends up looking.</p>
<blockquote><p>No Matter how beautiful and eye-catching your car looks like there is no point if you don’t know how to drive it.</p></blockquote>
<p><img alt="" src="http://ift.tt/2lHkqNd">you will be left alone</p>
<h4>What problems can be caused by conflicting requirements?</h4>
<ol>
<li><strong>Designer will be in doubt. </strong>— A designer analyzes the requirements before going in, to start grouping them to understand: the user types, the behaviour of the data that is being represented in the system, and what the problem that the user needs to be solved. <br />When the designer discovers if the requirements for designing a module or a page has a gap he/she will try to find why that happened. Maybe by going through the documents, or given voice cuts by the clients to understand what the problem is. This problem can be fixed if the client has direct requirements clarified with the designer. But the involvement of third parties to give requirements to the product that has a direct impact towards the part where the designer is trying to revamp, the design would cause this problem. The user has to go back and forward on a couple of channels to get clarifications again. This will delay the design process and the designer has to deviate from original concept or problem that need to be solved at the initial state.</li>
<li><strong>Product quality will go down</strong> — One of the best things a company can achieve when the designing product is the best in understandability and the discoverability of that particular product. In simple words, these two factors are the some of the direct impacts of the quality of the product. If the system is made with gaps that are created by conflicting requirements that would have functional gaps that leave the user hanging or to have a sudden stop to the end point of the task in hand. This will be a major setback to the user when getting the work done.</li>
<li><strong>Design get too cluttered </strong>— It’s something of a defect that has both parties are involved. When the requirements are not clarified and the management wants new parts squeezed into the design with the requirements given by the client, the design gets too cluttered and makes the user feel uncomfortable to work with the system. If the systems tell the users to fill in the same set of data over and over again to complete a certain set of tasks that would be a disaster for the user in terms of time-consuming as well as rework on the same set of information.</li>
<li><strong>Spoonfed clients </strong>— This happens when the client does not understand what they actually need. Most of the times when coming to feedback sessions the party who interviews the clients tend to give ideas in a way that the client can not resist. Not being able to resist means that most of the time, clients do not understand what they need to have to improve their products. So they are open to suggestions. When the suggestions are given by the interviewing party, they have to use the language that gives out suggestions by the client him/ her self-understanding the scope that the change is needed or the value addition is needed. Otherwise, if the interviewing party gives tells the client “<em>We should have this, Don’t you need it?</em>” the client will have doubts and scars since most of the time they want anything that would help them. In many cases, these type of spoon feeding leads to problems in the design allowing unnecessary modules to be displayed in the system that does not give any business value to the client.</li>
</ol>
<h4>How to overcome these scenarios?</h4>
<p><img alt="" src="http://ift.tt/2mDfUnX">Its really simple, its called people thinking and doing</p>
<p>When coming to conflicting requirements the designer should always be ready to ask questions from the client, and should be very much forwards with his/her idea about the design changes, telling whether this idea is a one that going to solve the problem that they are addressing at the moment. Yes it is not a good thing to say that the client or the third-parties ideas regarding the system are not good but we can always come up to a common ground by negotiations and proper design level communication with the client showing what is really happening in the product and what type of impact that would create the design by the modification or the addition or the change in the design rather than talking about it since visual cues are much more better than letters and words.</p>
<p><em>If the requirements are coming from two different ends get them both into the same meeting and let them battle it out if you have to. Believe me it works wonders.</em></p>
<p>Apart from that we can really use Design Thinking to avoid these kind of situations.</p>
<h4>How can we bring Design Thinking into this?</h4>
<ol>
<li><strong>Vision</strong> — The vision towards a product is to understand what are the features that the designers are to create and we can skin this in to who is being impacted by this features now and in the future. This will help the designers to understand who are being impacted and what they really want to have in their product. Then when the communication happens there will be fewer issues if having conflicting requirements coming from the client and the designers will be able to point out the necessary points so the clients will have a proper picture regarding the considerations that the designers are having. Making them aware of what would happen if the requirement that makes conflict with the design happen would help the client to have a zoom out view of the product rather than looking into it in a narrow picture.</li>
<li><strong>Problem</strong> —Normally what we do is that we look into the pain that we are addressing in a certain scenario and try to find a solution to the problem. Most of the time multiple parties suggest different types of solutions from their perspective towards the problem being addressed. That would bring a lot of different conflicts in the actual requirement. To avoid this the designer can show the impact each of the suggestions that they make and to make them aware of the value of each of the solution suggestion as well as the designer’s idea as well.</li>
<li><strong>Test</strong> — Most of the time when the designer are not presented in the feedback sessions in testing the workflow the interviewing party tend to use management level employees to look into the system and tell them to give a feedback. This will lead to loose loads of information that is critical since the people who enrolled in the system have different viewpoints and the interviewing team is only covering the feedback from the top level needs. The clear understanding of whom should be involved in the interviews and which user groups should be allocated to do the testing. This will reduce the conflicting requirements that are coming from the testing session and the designer can have a clear idea of what need to be done and as well as the client.</li>
<li><strong>Results/Feedback</strong> — I would prefer if we can keep the results of the design test or the feedback session in a low fashion since too many spoons in the soup can spoil it out.</li>
<li><strong>Outcome</strong> — This is the most critical place where everyone get things wrong. Most of the time the management looks into outputs rather than outcomes. A product experience is the best way of finding what is right from wrong. Its extremely difficult to get a human experience but we have to make it work somehow. Most of the time it will help the question “Why?” from a client if the feature was introduced that prevent conflicting and confusing feedback just by seeing it. Making the users work on the visual designs to complete a product is the most productive way of being successful in product design.</li>
</ol>
<p>Its really difficult to collaborate with humans and work as a product designer and it make your life messy and time consuming. But communicating properly and directly would help you to get the obstacles away from you and make the product successful at the end.</p>
<p>This is my personal experience towards to product design I hope you enjoy it and I am always open to suggestions so I can improve my self. 🙂</p>
<p><iframe src="http://ift.tt/2kZ4o5P" width="800" height="400" frameborder="0"><a href="http://ift.tt/2lIYHWK">http://ift.tt/2lIYHWK</a></iframe><img src="http://ift.tt/2lHfk3u" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou"></p>
<hr>
<p><a href="http://ift.tt/2mD6zMH">What Do Conflicting Requirements Bring to Your Product</a> was originally published in <a href="http://ift.tt/2cAqCpx">Prototyping: From UX to Front End</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>


What Do Conflicting Requirements Bring to Your Product

How Not to Mess up as Product Designer

Top Stories