We stand with Ukraine and our team members from Ukraine.

The Community Of Over 640,000

Home ›› Business Value and ROI ›› 6 Key Questions to Guide International UX Research ›› small_16 ›› Forms are a Conversation

Forms are a Conversation

by Nathan Barry
4 min read
Share this post on


When designing forms, think about your queries in the form of a conversation.

The users of your software always visit with a goal in mind. Often in web applications, a form stands between them and that goal. Whether the user wants to join a community like Facebook to connect with their friends or use a project management tool to organize their business, forms are there to hurdle.

These forms aren’t necessarily bad, we just need to remember that they are a step in the process—a step that must be completed before the user can reach their goal. So we want to make that step as painless as possible.

A Conversation

Try thinking about the form as a conversation: “I’m going to ask you a few questions so that you can complete your task.” But like any conversation, context and order are really important. Let’s say you and I have just met and after a quick introduction I ask, “What’s your address?” Your likely response would be shock: “Why should I tell you?” After all, we’ve only just met, you don’t know anything about me, and I am asking for personal information. I haven’t given you any reason why I need it.

Online forms are the same. If you ask for too much information too early, your users will pull out. “Why does this shopping website need my address? I haven’t even decided if I am going to purchase from them yet?”

Let’s try another example. You and I meet, but this time we talk for a while, find a mutual interest, and I offer to give you a copy of my favorite book on the subject. Now if I ask for your address to send you the book, your reaction will probably be completely different.

So before asking for personal information in a web application you need two things: trust and a reason.

Building Trust

The best way to build trust is to share information about your software: what it does, who created it, and especially how it will help the potential user. After all, at this point they are just reading about it, and not yet using it. The more you share about how it will help them, the more they will want to trust your software. Then when it comes time to ask for information about them, such as their name and email address to create an account, there will already be some trust built up.

Having a Reason

Let’s say that to browse an exclusive e-commerce website you need to create an account (a silly requirement, but this is just an example). If the create-account form asked for your physical address you may feel your privacy violated, because they haven’t given you a reason yet. Sure, if you buy something your address is needed to ship it to you, but you haven’t made that purchase yet. If the website instead waits to ask for your address until you’ve decided to make a purchase, then there is a reason for asking. You will be much more likely to give it to them.

So, just like in a conversation, when and how a question is asked has a huge impact on whether or not it will be answered.

A Conversation not an Interrogation

If I ask you a few sensible questions, then we are having a conversation. If instead I bombard you with questions, our friendly conversation starts to feel more like an interrogation. So limiting the number of questions asked will go a long way toward maintaining a friendly relationship with your user.

In real life you may feel like you have a social obligation to stay active in the conversation, rather than flipping me off and walking away. But that social obligation is not there at all on the web. With a single click of the back button users can exit a conversation they don’t like and never come back.

Look carefully at every question you are asking. It’s likely that about half of them can be removed. If later on you need more information, you can always ask the question when you have a reason for asking.

If you approach the questions in your form like you would a conversation with a stranger, then your users will be more likely to answer them.



Portions of this article are excerpts from Nathan Barrys’s book, Designing Web Applications, an everyman’s guide to building apps with solid usability that launches today.



Image of chatty tea party courtesy Shutterstock.

post authorNathan Barry

Nathan Barry, Nathan Barry is an interface designer and app developer who is passionate about designing software that is a joy to use. After leading the software design team at a startup in Boise, Idaho, where he lives, Nathan began working independently, designing and developing his own apps. He is the author of Designing Web Applications and he loves to travel. Follow him @nathanbarry on Twitter.


Related Articles

Building effective partnerships with PMs requires stepping outside of any frustration, ego, or resentment at being ignored, and building empathy. How to do that? Here is what we’re going to find out.

How To Research So PMs Will Listen
  • PMs are the most critical audiences for research, they are also often the hardest to convince, and the source of many of researchers’ frustrations and heartaches.
  • Building effective partnerships with PMs requires stepping outside of any frustration, ego, or resentment at being ignored, and building empathy.
  • The author shares:
    • Some practices of working with PMs
    • Questions to ask PMs and stakeholders
  • The baseline expectation setting:
    • Level set
    • Set guardrails based on your role
    • Ask for candid feedback and engagement
    • No surprises
  • When researchers and PMs are in conflict or in separate silos, neither role gets the value of the other, but strong researcher-pm partnerships can be game-changing for extending the strategic impact and influence of both design and research.
Share:How To Research So PMs Will Listen
6 min read
How to research so PMs will listen
How To Empower An Organization Through Design?
  • The author believes that the following reasons are why design/branding/marketing agencies end up damaging the image of design as a tool for getting results:
    • Lots of jargon and little to no action at a fundamental level.
    • Large companies with “foolproof” processes.
    • Fake cases and invented touch points
    • Romanticized view of consumers
  • In order to centralize an organization, designers need to map its interdependence relationships and understand how a project can strengthen all sectors in an equal way.
Share:How To Empower An Organization Through Design?
4 min read
How to empower an organization through design?

And, Is OneReach Under The Radar By Design?

Is OneReach AI The Tesla Of Conversational AI?
  • The author gives his perspective on OneReach.ai as the top scorer in the Gartner 2022 report.
  • The author believes OneReach.ai to be one of the most granular no-code environments that support an exceptional degree of fine tuning.
  • The author refers to the platform as an orchestration canvas, where multiple processes can be orchestrated for multi-dimensional customer service, and gives some details on how the platform works as a single front-door for customers.
  • Cobus Greyling explores two cautions from Gartner about the OneReach.ai platform.
  • He concludes that voice is a strength of OneReach.ai and the company has extreme focus on customer experience, and orchestrating experiences
Share:Is OneReach AI The Tesla Of Conversational AI?
4 min read
Is OneReach AI The Tesla Of Conversational AI?

This website uses cookies to ensure you get the best experience on our website. Check our privacy policy and