Aviators will tell you that being off course by just one degree, after flying 60 miles, you'll miss your target by a mile. The further your road goes, the more remarkable your mistake gets. And harder to fix.Designing a product doesn't happen overnight. Like with long-haul flights, going off course even a little will make a huge impact on the final result.Initial requirements gathering is a preliminary phase of the design process that is crucial to setting the whole project off in the right direction by focusing on the right problems to solve and, consequently, building the right thing.

How to Share UX Design Requirements

Design process<h1>Hiring a Design Agency? Learn How to Share UX Design Requirements</h1>The difference between successful product design and miserable fail often comes down to a tiny error made on a stage of requirement gathering<img src="https://global-uploads.webflow.com/5f16d69f1760cdba99c3ce6e/602a78e89588fc6813fd4df3_photo_2018-08-03_09-02-16.jpg" alt="" width="36" height="36">Dana Yatsenko<img src="https://global-uploads.webflow.com/5e8b3356a5a8f5321855bbe7/5fa9447da88b4b8bf5a57609_face.svg" alt="" width="10" height="22"><img src="https://global-uploads.webflow.com/5e8b3356a5a8f5321855bbe7/5fa9447fb4099a01ca52cbf4_tweet.svg" alt="" width="22" height="18"><img src="https://global-uploads.webflow.com/5e8b3356a5a8f5321855bbe7/5fa9447f0048e457f8f969e4_in.svg" alt="" width="20" height="18"><img src="https://global-uploads.webflow.com/5f16d69f1760cdba99c3ce6e/60bf2ac7584fdc18b9fa1d58_ux%20design%20requirements.png" alt="" srcset="https://global-uploads.webflow.com/5f16d69f1760cdba99c3ce6e/60bf2ac7584fdc18b9fa1d58_ux%20design%20requirements-p-500.png 500w, https://global-uploads.webflow.com/5f16d69f1760cdba99c3ce6e/60bf2ac7584fdc18b9fa1d58_ux%20design%20requirements-p-800.png 800w, https://global-uploads.webflow.com/5f16d69f1760cdba99c3ce6e/60bf2ac7584fdc18b9fa1d58_ux%20design%20requirements-p-1080.png 1080w, https://global-uploads.webflow.com/5f16d69f1760cdba99c3ce6e/60bf2ac7584fdc18b9fa1d58_ux%20design%20requirements-p-1600.png 1600w, https://global-uploads.webflow.com/5f16d69f1760cdba99c3ce6e/60bf2ac7584fdc18b9fa1d58_ux%20design%20requirements-p-2000.png 2000w, https://global-uploads.webflow.com/5f16d69f1760cdba99c3ce6e/60bf2ac7584fdc18b9fa1d58_ux%20design%20requirements.png 2088w" width="528" height="320">In July 1938, a small silver plane made a wide turn over a city and started down to the airport. The pilot landed his plane, stepped out, and exclaimed: “Where am I?”&nbsp;It was Corrigan Douglas. He took off from New York, with plans to land in California, but the compass had malfunctioned, he lost his direction in the clouds and accidentally flew over the ocean. Due to a navigation mistake, Douglas “Wrong Way” Corrigan made a transatlantic flight from New York to Dublin.<figure><img src="https://global-uploads.webflow.com/5f16d69f1760cdba99c3ce6e/60bf324c4c145cc6c515f8f5_2.jpg" alt="1 in 60 rule for designers" width="526" height="296"></figure>Aviators will tell you that being off course by just one degree, after flying 60 miles, you'll miss your target by a mile. The further your road goes, the more remarkable your mistake gets. And harder to fix.Designing a product doesn't happen overnight. Like with long-haul flights, going off course even a little will make a huge impact on the final result.Initial requirements gathering is a preliminary phase of the design process that is crucial to setting the whole project off in the right direction by focusing on the right problems to solve and, consequently, building the right thing.No other part of the conceptual work is harder than deciding on requirements. No other part of the work cripples the result so much if done wrong. No other part is as difficult to rectify later.That's not hyperbole — <a href="https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2017.pdf?sc_lang_temp=en" rel="nofollow" dir="ltr">39% of failed projects fail</a> due to inaccurate requirements gathering.Seemingly both designers and clients are interested in getting the requirements right. So how is requirement gathering done and why does this process often go painfully wrong?<figure><img src="https://global-uploads.webflow.com/5f16d69f1760cdba99c3ce6e/60bf325c00cb11665aaae68a_1.jpg" alt="UI/UX design document fatal error meme" width="526" height="296"><figcaption dir="auto">UI/UX design document fatal error</figcaption></figure><h2>What makes UX design documentation difficult (and how to fix it)&nbsp;</h2>So you have an app to build, and you’re looking for designers to help you with the <a href="https://www.eleken.co/ui-ux-design" dir="ltr">UI/UX part</a>. If you are lucky enough to have in-house design capabilities, you’ll explain to fellow colleagues what you want them to do and they'll be likely to understand. Those people have been sitting on hundreds of your weekly meetings, they’ve read miles and miles of your company’s Slack conversations. In other words, they understand the context.&nbsp;But since you’re reading this article, you haven’t got enough in-house design capabilities. You're going to cooperate with a stranger who is a design and user experience expert but doesn’t know much about your context, your market, and your audience.&nbsp;It’s like taking a taxi with a driver who has never been to your city and has no navigator on board. Before taking off, this guy will ask you about your destination and the best route. That's the same kind of thing any designer will ask you when getting to work.&nbsp;The input information from clients usually sounds something like this:“We need to design/redesign this MVP/app/website”That’s not enough to open Figma and start wireframing. The designer needs to gather more information:<UL><LI>To understand precisely what is required of the design. What is the idea of the product, its goals and objectives, its future functionality and competitors, its users and their needs;</LI><LI>To decide on some basic schedule and roadmap for the design milestones;&nbsp;</LI><LI>To agree on production control to ensure final prototypes satisfy the requirements.	</LI></UL>The problem is that we have some obstacles that get in the way of making all the UI/UX requirements clear. The three C’s formula — Communication, Comprehension, Control — captures all the components capable of throwing any design project into chaos.<h3>Communication: breaking barriers and building bridges</h3>When you tell your designer you’re making a breakthrough decentralized P2P ecosystem, it’s quite the same as switching into the language of birds. What sounds just fine for you with your industry expertise sounds like white noise for a designer.<figure><img src="https://global-uploads.webflow.com/5f16d69f1760cdba99c3ce6e/60bf32802d6c4a2b293ff1d6_4.jpg" alt="UX design documentation example (the bad one) meme" width="1" height="1"><figcaption dir="auto">UX design documentation example (the bad one)</figcaption></figure>Software is complex, abstract, difficult to visualize and explain. That creates communication barriers you and your designers have to eliminate on the road to fruitful communication.We at <a href="https://www.eleken.co/contact-us" dir="ltr">Eleken design agency</a> believe that the ability to understand each other is key to a successful project. That’s why we literally built our working process around communication with clients.<UL><LI>We don’t ask you to <a href="https://www.eleken.co/blog-posts/design-brief-example-how-it-should-look-like-and-what-it-should-contain" dir="ltr">fill a brief</a> — because no UX design specification document can explain customer needs better than a real conversation when you can ask what the heck “decentralized P2P ecosystem” is when you hear such kind of white noise.&nbsp;</LI><LI>We arrange calls with clients, a lot of calls. In some cases, they are even meetings and workshops — all to discuss the product and clarify our next steps.</LI><LI>We don’t have project managers in our agency — the person you talk to is the person who designs your app. Cutting out the middleman allows us to make sure the message always reaches the right person, and not in a Chinese whispers way.&nbsp;</LI></UL>What clients can do, for their part, is being responsive. If the designer has questions, try to answer them fast to optimize their time and your investments. A designer that doesn’t get timely feedback can either wait for your reply, thus being blocked, or continue working on assumptions that might lead the project down the wrong way (ending up somewhere in Dublin).<h3>Comprehension: how to define requirements for a project</h3>Maksym, a UI/UX designer at Eleken, provides a typology of projects based on the level of the customer’s comprehension:<UL><LI>Smooth projects, when clients know what they want and how they want it to be done. Designers, in such cases, are not involved in any conceptual decisions, but simply work according to specifications given. Not the most creative stuff, but smooth sailing from day one. The result is usually assured and the customer is satisfied.</LI><LI>Successful projects, when clients know what they want, and trust designers to define the best ways for things to be done. Clients’ knowledge and designers’ expertise unite for synergy and success.</LI><LI>Fun projects, when clients don’t know what they want but trust designers to help them figure things out. Eleken specializes in designing apps for SaaS startups, so we basically specialize in fun projects.</LI></UL><figure><img src="https://global-uploads.webflow.com/5f16d69f1760cdba99c3ce6e/60bf32fd47c631818edb345d_3.jpg" alt="typology of projects based on the level of the customer’s comprehension " width="1" height="1"></figure>For sure, it’s an ideal scenario when you come to a designer and clearly know how your app is going to work and look like — it just saves your time. However, our experience shows that clients rarely know what they want (until they see it). Not in the detail necessary for design specification, at least.&nbsp;And it’s okay. Bring a vision, then let the agency figure out the details. Experienced designers can help you define requirements for a project. It just means that you’ll go all the way carefully testing the waters, and you’ll participate in communicating on a daily basis for the feedback exchange.A designer will show you various types of products to understand your preferences. They’ll study all the existing written materials on the topic, and check their findings with you. They’ll do user experience research, and validate it with you. They’ll create <a href="https://www.eleken.co/blog-posts/saas-customer-journey" dir="ltr">user journeys</a>, and show them to you to obtain your feedback. They’ll make wireframes and prototypes, and show them to you many, many times until the result satisfies you.&nbsp;Deep comprehension can be replaced by the customer’s trust and active cooperation.&nbsp;<h3>Control: navigating through the fog of uncertainty</h3>The saying was that two things in life are certain: death and taxes. A design project plan is not on the list. Because the product design process is hard. It’s nuanced. It takes months (and sometimes years) to bear fruit.Yet precision is what designers often asked for. Clients want to know exactly when the project will be done, how much time each step will take, and what the schedule is.At the beginning of any project, we don’t know how long this is going to take. We can compare it to our previous experiences, but no two projects are the same. They never have the same requirements, the same people, the same priorities, the same UX design tasks. Each is unique.&nbsp;At first glance, we can say whether the UX scope of work is going to be large (6+ months), medium (2-5 months), or small (a couple of weeks).&nbsp;<figure><img src="https://global-uploads.webflow.com/5f16d69f1760cdba99c3ce6e/60bf332c9ae3583b1d58d55e_5.jpg" alt="UX scope of work estimation" width="1" height="1"></figure>As more research and development is done, more information is learned about the project, the uncertainty tends to decrease. After a couple of iterations, we can learn and create something, measure how long that takes, and then give you a much better sense of how big this thing is.&nbsp;To make gathering customer requirements in the fog of uncertainty easier, we at Eleken provide you a one-week trial free of charge. On the expiry of the trial week, you can make an informed decision on whether you want to go on working together, and we can make better estimations on the scope and schedule.<h2>Wrapping up our little guide to UX design process &amp; documentation</h2>Product design for SaaS startups is where outsourcing never works, but collaboration always does. Collaboration is especially important at the initial phase of UX requirements gathering. If you give agency money and then sit around waiting for them to impress you, you’re risking ending up in Dublin instead of California.But the effort is worth it. After all, we seek to create something that people love and have value from — this is the real magic of being either an entrepreneur or a product designer.<figure><img src="https://global-uploads.webflow.com/5f16d69f1760cdba99c3ce6e/60bf3356af7eab7526134319_6.jpg" alt="guide to UX design process &amp; documentation" width="1" height="1"></figure>We’ve been talking about business requirements. If you want to read about how we elicit user requirements, read our piece about the <a href="https://www.eleken.co/blog-posts/ux-research-process" dir="ltr">UX research process</a>.And if you’re ready to discuss your design requirements with us, <a href="https://www.eleken.co/contact-us" dir="ltr">drop us a line</a>.<img src="https://global-uploads.webflow.com/5e8b3356a5a8f5321855bbe7/5fa9447da88b4b8bf5a57609_face.svg" alt="" width="10" height="22"><img src="https://global-uploads.webflow.com/5e8b3356a5a8f5321855bbe7/5fa9447fb4099a01ca52cbf4_tweet.svg" alt="" width="22" height="18"><img src="https://global-uploads.webflow.com/5e8b3356a5a8f5321855bbe7/5fa9447f0048e457f8f969e4_in.svg" alt="" width="20" height="18">Read more about SaaS design<img src="https://global-uploads.webflow.com/5f16d69f1760cdba99c3ce6e/618010f922f2176498b6980e_Fintech%20UX%20design.png" alt="" width="344" height="230">

Hiring a UI/UX agency is a big investment of both time and money. Approaching UX design requirements right is how you can get more for your dollar.

creativity

Creativity

computerscience

Computer Science

product

Product & Design

humanresources

Human Resources

artificialintelligence

Artificial Intelligence

Hiring a Design Agency? Learn How to Share UX Design Requirements

The difference between successful product design and miserable fail often comes down to a tiny error made on a stage of requirement gathering

In July 1938, a small silver plane made a wide turn over a city and started down to the airport. The pilot landed his plane, stepped out, and exclaimed: “Where am I?”

It was Corrigan Douglas. He took off from New York, with plans to land in California, but the compass had malfunctioned, he lost his direction in the clouds and accidentally flew over the ocean. Due to a navigation mistake, Douglas “Wrong Way” Corrigan made a transatlantic flight from New York to Dublin.

Aviators will tell you that being off course by just one degree, after flying 60 miles, you'll miss your target by a mile. The further your road goes, the more remarkable your mistake gets. And harder to fix.

Designing a product doesn't happen overnight. Like with long-haul flights, going off course even a little will make a huge impact on the final result.

Initial requirements gathering is a preliminary phase of the design process that is crucial to setting the whole project off in the right direction by focusing on the right problems to solve and, consequently, building the right thing.

No other part of the conceptual work is harder than deciding on requirements. No other part of the work cripples the result so much if done wrong. No other part is as difficult to rectify later.

That's not hyperbole — <a dir="ltr" href="https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2017.pdf?sc_lang_temp=en" rel="nofollow">39% of failed projects fail </a>due to inaccurate requirements gathering.

Seemingly both designers and clients are interested in getting the requirements right. So how is requirement gathering done and why does this process often go painfully wrong?

What makes UX design documentation difficult (and how to fix it)

So you have an app to build, and you’re looking for designers to help you with the <a dir="ltr" href="https://www.eleken.co/ui-ux-design">UI/UX part </a>. If you are lucky enough to have in-house design capabilities, you’ll explain to fellow colleagues what you want them to do and they'll be likely to understand. Those people have been sitting on hundreds of your weekly meetings, they’ve read miles and miles of your company’s Slack conversations. In other words, they understand the context.

But since you’re reading this article, you haven’t got enough in-house design capabilities. You're going to cooperate with a stranger who is a design and user experience expert but doesn’t know much about your context, your market, and your audience.

It’s like taking a taxi with a driver who has never been to your city and has no navigator on board. Before taking off, this guy will ask you about your destination and the best route. That's the same kind of thing any designer will ask you when getting to work.

The input information from clients usually sounds something like this:

“We need to design/redesign this MVP/app/website”

That’s not enough to open Figma and start wireframing. The designer needs to gather more information:

<ul><li>To understand precisely what is required of the design. What is the idea of the product, its goals and objectives, its future functionality and competitors, its users and their needs; </li><li>To decide on some basic schedule and roadmap for the design milestones;  </li><li>To agree on production control to ensure final prototypes satisfy the requirements. </li> </ul>

The problem is that we have some obstacles that get in the way of making all the UI/UX requirements clear. The three C’s formula — Communication, Comprehension, Control — captures all the components capable of throwing any design project into chaos.

Communication: breaking barriers and building bridges

When you tell your designer you’re making a breakthrough decentralized P2P ecosystem , it’s quite the same as switching into the language of birds. What sounds just fine for you with your industry expertise sounds like white noise for a designer.

Software is complex, abstract, difficult to visualize and explain. That creates communication barriers you and your designers have to eliminate on the road to fruitful communication.

We at <a dir="ltr" href="https://www.eleken.co/contact-us">Eleken design agency </a>believe that the ability to understand each other is key to a successful project. That’s why we literally built our working process around communication with clients.

<ul><li>We don’t ask you to <a dir="ltr" href="https://www.eleken.co/blog-posts/design-brief-example-how-it-should-look-like-and-what-it-should-contain">fill a brief </a>— because no UX design specification document can explain customer needs better than a real conversation when you can ask what the heck “decentralized P2P ecosystem” is when you hear such kind of white noise.  </li><li>We arrange calls with clients, a lot of calls. In some cases, they are even meetings and workshops — all to discuss the product and clarify our next steps. </li><li>We don’t have project managers in our agency — the person you talk to is the person who designs your app. Cutting out the middleman allows us to make sure the message always reaches the right person, and not in a Chinese whispers way.  </li> </ul>

What clients can do, for their part, is being responsive. If the designer has questions, try to answer them fast to optimize their time and your investments. A designer that doesn’t get timely feedback can either wait for your reply, thus being blocked, or continue working on assumptions that might lead the project down the wrong way (ending up somewhere in Dublin).

Comprehension: how to define requirements for a project

Maksym, a UI/UX designer at Eleken, provides a typology of projects based on the level of the customer’s comprehension:

<ul><li>Smooth projects , when clients know what they want and how they want it to be done. Designers, in such cases, are not involved in any conceptual decisions, but simply work according to specifications given. Not the most creative stuff, but smooth sailing from day one. The result is usually assured and the customer is satisfied. </li><li>Successful projects , when clients know what they want, and trust designers to define the best ways for things to be done. Clients’ knowledge and designers’ expertise unite for synergy and success. </li><li>Fun projects , when clients don’t know what they want but trust designers to help them figure things out. Eleken specializes in designing apps for SaaS startups, so we basically specialize in fun projects. </li> </ul>

For sure, it’s an ideal scenario when you come to a designer and clearly know how your app is going to work and look like — it just saves your time. However, our experience shows that clients rarely know what they want (until they see it). Not in the detail necessary for design specification, at least.

And it’s okay. Bring a vision, then let the agency figure out the details. Experienced designers can help you define requirements for a project. It just means that you’ll go all the way carefully testing the waters, and you’ll participate in communicating on a daily basis for the feedback exchange.

A designer will show you various types of products to understand your preferences. They’ll study all the existing written materials on the topic, and check their findings with you. They’ll do user experience research, and validate it with you. They’ll create <a dir="ltr" href="https://www.eleken.co/blog-posts/saas-customer-journey">user journeys </a>, and show them to you to obtain your feedback. They’ll make wireframes and prototypes, and show them to you many, many times until the result satisfies you.

Deep comprehension can be replaced by the customer’s trust and active cooperation.

Control: navigating through the fog of uncertainty

The saying was that two things in life are certain: death and taxes. A design project plan is not on the list. Because the product design process is hard. It’s nuanced. It takes months (and sometimes years) to bear fruit.

Yet precision is what designers often asked for. Clients want to know exactly when the project will be done, how much time each step will take, and what the schedule is.

At the beginning of any project, we don’t know how long this is going to take. We can compare it to our previous experiences, but no two projects are the same. They never have the same requirements, the same people, the same priorities, the same UX design tasks. Each is unique.

At first glance, we can say whether the UX scope of work is going to be large (6+ months), medium (2-5 months), or small (a couple of weeks).

As more research and development is done, more information is learned about the project, the uncertainty tends to decrease. After a couple of iterations, we can learn and create something, measure how long that takes, and then give you a much better sense of how big this thing is.

To make gathering customer requirements in the fog of uncertainty easier, we at Eleken provide you a one-week trial free of charge. On the expiry of the trial week, you can make an informed decision on whether you want to go on working together, and we can make better estimations on the scope and schedule.

Wrapping up our little guide to UX design process & documentation

Product design for SaaS startups is where outsourcing never works, but collaboration always does. Collaboration is especially important at the initial phase of UX requirements gathering. If you give agency money and then sit around waiting for them to impress you, you’re risking ending up in Dublin instead of California.

But the effort is worth it. After all, we seek to create something that people love and have value from — this is the real magic of being either an entrepreneur or a product designer.

We’ve been talking about business requirements. If you want to read about how we elicit user requirements, read our piece about the <a dir="ltr" href="https://www.eleken.co/blog-posts/ux-research-process">UX research process </a>.

And if you’re ready to discuss your design requirements with us, <a dir="ltr" href="https://www.eleken.co/contact-us">drop us a line </a>.

Read more about SaaS design

Hiring a Design Agency? Think Twice of Your UX Design Requirements

How to Share UX Design Requirements

Marie Liechman's ideas are part of this journey:

Related collections

Similar ideas