Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Sci-Fi, Frustrations, Flash And Forms: The Typeform Story

Take any new interface design or display technology, and chances are that someone somewhere has already compared it to Minority Report. The 2002 dystopian film, with its see-through screens and gesture-driven interfaces, is remembered more for its futuristic tech than for the insidiousness of the technology — pre-crime prediction — that was its actual focus. It continues to be the standard by which we judge new interfaces.

But inspiration doesn’t only come in the form of flashy, futuristic interfaces. At Typeform, we were inspired to simplify online forms by a movie that’s decidedly a blast from the past: the 1983 film WarGames, which centers around a student who remotely logs into a research computer and, through its terminal interface, nearly sparks a nuclear war. Its computers are hardly state of the art, yet the computers’ question-driven interface inspired us to reinvent forms. Instead of a list of questions, how much better would it be if forms presented one easy-to-answer question at a time?

Further Reading on SmashingMag:

Stripping forms down to their basics and building them back up into something better took four years of work, but that core idea guided us all along: questions are better than lists. Here’s the story of our crazy idea to reimagine how forms could work, and how we turned that idea into a product that’s helped companies of all sizes get a 55% completion rate on their forms.

Dismembering A Form Link

“Everything should be made as simple as possible, but no simpler.”

– attributed to Albert Einstein

You’ve filled out plenty of online forms, from the standard surveys that you get in emails to checkout forms and more. Forms have been with us since the earliest days of the Internet, and they largely look the same today as they did in the ’90s. They’re filled with lists of questions and tiny bullet points that are hard enough to fill out on a PC and are an exercise in extreme frustration on mobile.

Forms have turned into one of the most annoying things about the Internet, right along with popup ads and auto-playing audio. They’re a necessary evil — no one would say that they love filling out forms, but we all have to fill them out anyway.

Traditional online forms can be overwhelming.

Crowded with information, forms feel like the on-screen equivalent of questions being screamed at you — something you’d walk away from in real life. If your form makes people feel like they’re completing a tax return in a crowded room, chances are they’ll click away, too.

Questions themselves don’t have to be unpleasant, though. They are the foundation of small talk and are an important and even fun part of life when used in moderation. If that’s all they are, then surely we can make a better form by emulating conversation, with just one question at a time.

That’s the genius of the console in WarGames6. It asks a question, waits for an answer, then follows up with another question. Without any more logic than your average form, it feels more lifelike simply because asking one question at a time feels like a conversation. It’s not overwhelming, and yet it gets the same result as a form would.

That, we knew, had to be the future of a more human form. One question at a time, presented in a way that would make people want to respond.

To Build a More Conversational Form Link

Simplifying forms, though, took more than just inspiration. It took us on a four-year journey, starting with a showroom Flash application for a client in 2010. That application was built to run full-screen on large monitors at an exhibition, complete with video, animations and a way to collect information from visitors to the booth in a modern (for the time), interactive experience. A typical Web form would have been impossible to use on such a large screen and would have looked terrible alongside the other elements. We quickly saw that it was time to reinvent the form.

There’s ways to make traditional forms better7, by including more whitespace, separating forms into sections, and more. There’s standards behind the way forms look and feel, which have kept them far more similar to a paper form than something imagined just for screens. We wanted to experiment and see what a form could be like if it was removed from those linear constraints, redesigned around questions.

It wouldn’t be a traditional form, and it would even break conventions—much in the same way the iPhone’s software keyboard broke the standard real-button keyboard conventions—but the WarGames form had given us the idea that perhaps there was another way to gather info than the traditional form, and perhaps it could be better. We wanted to start out with a clean slate, and reimagine what a form could be with an entirely new product.

The design has come a long way since those early days. But the principles remain the same.

Our original solution was Quickyform, a Flash-based contact form that ran on an iMac in the exhibition space. (You can still try it out today8 to get a feel of our first shot at re-imagining online forms.) It embodied the essence of the WarGames form even as a rough early prototype. Only one question was shown in focus at a time, and once a visitor filled it out and pressed “Enter,” the next question came into focus, ready for them to enter the next answer without having to click anywhere. This, we knew, was the first step in the right direction for the future of forms.

When we built Quickyform, Flash was still prevalent online, and there was lingering hope that Apple and others would adopt it for their mobile platforms. Flash has its uses, but it had quickly become obvious that it wasn’t the best tool for our needs. We quickly shifted to the modern languages of HTML, CSS and JavaScript, and got to work designing a better UI that would work everywhere — ultimately, realizing our dream and even recreating the part of WarGames that had initially inspired us.

Click here to try the game10

Starting With The Basics Link

Our basic idea was to find the perfect way to display one question at a time, to reflect natural human conversation. To do that, we had to entirely declutter the UI, removing everything that might take the user’s attention away from the one question at hand. At the same time, we still wanted to retain a global view of the entire form to make it easy to navigate and see the remaining questions.

The solution wasn’t apparent at first. For example, an early version opened and closed each question as you went through them. That took care of showing only one question at a time, but the animations were too jarring and made it difficult to navigate the entire form. We took many such detours into the land of strange animations and interactions that just don’t feel natural in our quest to discover what would work best. The final simple solution of putting the active question in the center of the screen while showing the preceding and following questions faded out above and below seems obvious in retrospect but took a lot of experimenting to perfect.

Putting the active question in the center helped out other parts of our UI. It helped our large typography to make sense, which in turn freed us to make use of Web fonts. We use 24-pixel fonts on the desktop, and between 16- and 20-pixel fonts on mobile, depending on the device. Very few Web fonts work well at sizes below 16 pixels, so focusing on one question at a time enabled us to drastically improve the UI’s design.

In turn, the UI influences the UX. Large typography in our form designer forces you to shorten questions because there is less space per line. You have to make every word count in the questions you put in your form, and that precision makes the resulting questions far more likely to be answered by respondents.

Design Is How It Works Link

After deciding on the basics of our UI, we tackled interaction design as the next challenge. Our focus was a computer without a touchscreen, accelerometer, webcam or even a mouse. All that is needed to interact is a keyboard. After all, if you’re just answering questions, what more should you need?

Traditionally, a typical form forces you to move back and forth between the mouse and keyboard. You’ll click in a text box to type something in, and then reach for your mouse or squint to tap on your smartphone’s screen to fill in a multiple-choice question. If the form doesn’t already look bad enough, then the rows of tiny bullet points should be enough to get respondents screaming for the hills.

As dated as it might sound in the age of smartphones and tablets, we decided that keyboard navigation would be central to our redesigned forms. Users have to use a keyboard for questions that need a typed answer anyway, so we added keyboard shortcuts for all other types of questions. For “Yes” or “No” questions, you would tap “y” for yes and “n” for no. For multiple-choice questions, each answer is assigned a letter. For ratings, respondents would tap the number corresponding to their rating, from 1 to 0 (ten).

Click here to test12

Navigation between questions raised a new issue: the “Enter” key or the “Tab” key? How would these two buttons work in the context of Typeforms? At first, we allowed “Tab” and “Enter” to be used interchangeably to move to the next question, but assigning two buttons to do exactly the same thing seemed weird. So, we asked ourselves, what could we learn from what’s been done before?

In every other app or website, the “Tab” key is most commonly used to move between elements. You use it to jump between fields in a traditional form and to move between parts of a Web page. It is a non-committal way to move around. The “Enter” key, on the other hand, is most commonly used to commit to a decision. It’s the button we press to take an action or to submit a traditional form.

So, in learning from those who came before us, we decided to assign “Tab” for jumping between questions without setting off any validation checks. This way, you can move around the form without having to use the mouse. Pressing “Tab” brings the next question into view, ready to be filled out; “Shift” + “Tab,” in the same way, take you back to the previous question; and the arrow keys let you move up and down in the form as you’d expect.

Our next choice in keys was much harder to make: how to use the “Enter” key. It’s widely used in many apps to complete an action, but is also used to add a line break to text. In a form, we feel it’s far more common to need to quickly complete an action than it is to need to write multiple paragraphs of text, so we chose to use the “Enter” key to validate and submit responses. If an answer does not validate, then the user is asked to correct their answer; otherwise, they’ll move onto the next question. Then, we used the common “Shift” + “Enter” shortcut for line breaks when writing multiple paragraphs of text, the same shortcut commonly used in chat apps like Facebook Messenger.

Ideally, though, users shouldn’t have to use “Tab” or manually scroll to navigate forms at all, even though the forms show only one question at a time. That’s why we designed the forms to auto-scroll to the next question as soon as the current question is answered. Most forms require you to scroll through to see all of the questions, or even click to other pages to continue the survey. Our approach keeps respondents focused on the conversation and makes it far quicker to fill in the form.

Iterate, Iterate, Iterate Link

Even though Typeform’s UX and controls were in place, a lot of wiggle room was left in our UI. When we drafted the style guide for our UI, the world was shifting from skeuomorphic to flat design. We didn’t want to trap our design in a particular trend, so we embraced the best of both worlds.

Multiple-choice questions proved to be the hardest. Our original designs for them still felt like traditional forms, listing possible answers with radio buttons to their left. We wanted to keep the standard parts of forms intact, but that didn’t feel quite right — we hadn’t come this far to leave the most annoying part of forms alone.

So, we decided to turn multiple-choice answers into glass-like elements. Our first try put the standard round radio buttons on the left, albeit with translucency that made them better fit the form’s background. It looked nicer, but the original usability problem was still there because radio buttons are still relatively hard to select, especially on a touchscreen. To solve this, we expanded the size of the button, turning it into a glass panel that overlays the answer. This gives a far larger target to click or tap, perfect for mobile and desktop. We removed the radio buttons entirely because their presence automatically makes you think you’ll need to tap that smaller areas to select the option—we wanted people instead to feel free to tap anywhere on the button.

From fiddly radio buttons, to nice big touch targets.

This “glassification” brought with it another challenge: making sure that the buttons look great on a wide range of background colors. After extended experimentation, we finally landed on the solution of categorizing background colors into five levels of luminosity. We then add different CSS that adjusts the color of the button, shadows, border, highlights and a range of other factors based on the background. LESS14 turned out to be the perfect solution for getting the right balance of color every time.

Buttons react to the background they’re on.

You can see the change most obviously with the border. On a black background (#000000), the borders are a light color to offset the button. As the background gets lighter, the borders change to a darker color to give more contrast and better offset the button. We spent a lot of time getting the formula just right, and it paid off with a UI design that looks great no matter how our users want their forms to look.

See full preview17

That left us with one final UX problem: the “Next” button after a multiple-choice question. We needed a way for people to select choices — again, using the keyboard or mouse — and then easily jump to the next question with our auto-scroll. If we auto-scrolled as soon as someone had made a selection, then they’d have no chance to change their mind, but we didn’t want multiple-choice questions to have the friction they do in normal forms.

Our solution was to add an “OK” button that’s activated by pressing “Enter.” We assigned standard alphabet keys to each multiple-choice item, and we check mark an item once the user has selected it. A bit of extra text is added to questions that list multiple options, to help people understand. Once the user has made their selection, they just have to tap “Enter” to proceed to the next question.

Leave the mouse at home. Just tap or use your keyboard!

Working Everywhere Link

We designed Typeform’s UX to work great with just a keyboard, but then tweaked its UI to be perfect on touch screens, too. Designing it as a responsive app from the start would seem obvious, then, using media queries and breakpoints to render the same code on any screen size.

This isn’t how Typeform works, though. We experimented with delivering the same UI to a mobile device and a PC. That would work, but it created two problems:

  1. The whole form has to be rendered at the same time. This impairs performance on devices with limited RAM, especially if the form includes much multimedia content.
  2. It’s a poor use of limited screen space, with valuable room taken up by unnecessary elements.

The goal of responsive design is to deliver the same content and experience everywhere, and we still wanted that, even if using the same code wouldn’t achieve that goal for us. Our solution was to move to page- and slide-based navigation. On mobile, each question is rendered on its own, giving the form a small resource footprint and using the smaller screen more efficiently.

To do this, Typeform delivers different code to the browser depending on what device is being used. You’ll notice this if you open the same form on a PC and a smartphone. On a PC, we use the larger display to faintly show the previous and next questions. On a smartphone, we show only the current question in order not to waste any space. Respondents can easily swipe up and down on their phone to navigate questions, just as PC users would press the up and down arrows, but no space is wasted with the previews of previous and next questions. That’s one of the many tweaks we had to make in order to make our forms work perfectly on both desktop and mobile.

We then have a even simpler fallback mode19 on every form, that’s even faster to load on any device. These options were the ways we balanced between a rich web app on desktops and laptops, an equally polished mobile experience, and a faster option for lower internet speeds.

Test Everything Link

Typeform is a direct result of our own testing and tweaking of the idea that blossomed from WarGames’ inspiration and our client project in 2010, but we had very little user feedback in the beginning. It was just a side project, worked on in spare moments here and there. Decisions were based on intuition and hunches, and we had no idea what the lean methodology even was.

What we did know is that we had stumbled upon an entirely new way of interacting with online forms, not just an evolution of the interfaces that we’re all used to. If we had asked people what they wanted, we would have designed a normal form builder. Like Henry Ford, we needed to show people what they want. We had to invent the future—to discover the story hidden on the blank page, or uncover Michelangelo’s David in a block of marble as Ed Catmull describes the creative process of inventing the new in “Creativity, Inc.”

So, rather than rapidly release features in the wild and iterate based on feedback from our users, as lean methodology would dictate, we worked with our own controlled test group to find what was and wasn’t working before releasing it. If we had launched a public beta earlier, perhaps we would have thrown out the closing and opening animation between questions earlier on. But then we would have missed the subsequent iterations that guided us to our current solution of fading out the preceding and following questions. By iterating and working on intuition and experience, we were able to greatly improve an experience that might have been thrown out if we had asked users.

This isn’t to say that the lean methodology is bad or that it wouldn’t work for us now, but it couldn’t have worked for testing our initial concepts and finding our ground. Only when we had almost finished building the app and opened our beta program did we start getting a lot of feedback from our user base. The app was finished enough that people understood our vision and were able to help us find the rough edges that needed fixing. Feedback is important, but make sure that your vision is defined and apparent in your app before inviting the opinions of others; otherwise, you might miss the stages in the development of an app when you learn the most.

Never Stand Still Link

We turned our vision of a new type of form into a product, but we’re not done working. Breaking down forms into their basics opens up a lot of opportunities, because you can do so much with a format that asks one question at a time. We’ve finally realized our dream of recreating WarGames’ terminal in a form that captures the simplicity of the original, and we have found a ton of uses20 for Typeforms that go far beyond the traditional form. What other format would let you make anything from a Stripe-powered purchase form to an interactive storybook21?

Typeform’s simplicity gives us a platform on which to build and do more with the basic elements of a form. Designers can focus on things that make each question better and perhaps more visual and interactive, while still ensuring that all of the questions work together as a form. It’s already ready for large high-resolution screens and can just as easily be scaled down to a watch screen or whatever new displays the future will bring us.

Our core technology platform isn’t standing still, either. Typeform’s current technology stack consists of Symfony 222 and PHP that loads data from Redis23 and MySQL databases on the back end, and CoffeeScript24 and Backbone.js25 on the front end, all running on Amazon’s AWS platform. If that’s not enough, we’re currently refactoring parts of the application, using Node.js26 and NoSQL databases to improve performance and make it easier to implement new features.

More Human Forms Work Link

What will stay the same are modern, question-driven forms. We’re not the only ones on this journey of exploring how a redesigned form could work. Stripe has redesigned its checkout forms27 to be as simple as possible, asking just for the user’s email address, credit-card number, expiration date and CSV number, in a sleek form that would hardly intimidate anyone. PageLanes28 uses a question-driven form to collect contact information, and CoDrops29 was inspired by that to make a basic CSS- and Javascript-powered question-driven toolkit that you can use to design your own forms.

A typeform in its native habitat, ready to be filled in.

Question-driven forms get results. Quartz’s team recently got 940 C-level executives to respond to its executive study30. Its careful wording got Quartz a 34% open rate, and over 55% of those who opened its interactive survey (powered by Typeform, incidentally) actually finished it. That number is consistent with the average response rate we see from all of the more than 9 million unique Typeform form visits we’ve seen so far. Those results and the new unique ways you can use forms with Typeform—along with the results those forms bring—have been enough to get industry leaders from Adobe, Uber, MailChimp and more to use our forms to get results. That’s an exciting confirmation of what we’ve believed all along: People will want to fill out forms if the forms are driven by questions and simple enough to answer.

We’ve destroyed the traditional form — literally, in a joke game31 that we made recently — but much more can be done with forms. That’s what keeps us working on Typeform and what makes us excited to see new developments from others. But forms aren’t the only part of the web that could use some new design ideas. All it takes is breaking things down to their basics, figuring out what’s really important, and then building back up around that. If that approach can change forms this much, imagine how much it could change the things you’re working on.

You may have to break some conventions, and your final product might be fully new instead of just an updated version of the old—the app version of the motor vehicle versus the old horse-and-carriage. It might not even work. But you’ll be sure to discover something new and exciting along the way, something that just might let you make a better product.

(al, il)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31

↑ Back to top Tweet itShare on Facebook

David is a UI/UX designer turned entrepreneur. Born in Belgium, raised in England and currently living in Barcelona, where he founded Typeform.

  1. 1

    Thank you for the interesting article! I appreciate that you’re attempting to improve the usability of forms online.

    For me however I don’t really care for this approach, for the same reason I generally dislike online surveys: They hide the scope of the form. Many times I’ve started doing a survey (complete with a “Step 1 of 7” counter or the equivalent) only to reach step 3 and be presented with a question I’m not willing to answer or a form element that will take too long to complete. My time has been wasted, whereas if the form was on one page I could quickly scan its entirety to know whether I actually want to complete it or not. So IMHO this approach could work for some forms, but not all.

    • 2

      Hey Someguy,

      Point taken however that’s not actually how typeforms work, you can actually scroll or swipe to see the questions e.g

      • 3

        I see your point. And, while users can scroll or swipe to see the entire form, it requires some action on their part to do so. In reality, the ‘action’ we want users to take is filling out the form.

        There’s a possibility that by allowing users to scroll or swipe, they are in some way engaging in the process. There are studies that confirm this idea. There’s also the gamification aspect. Like you mentioned in your post, test everything. So we did.

        We created a lead-gen form in this manner and tested it. Our ‘traditional’ form won, hands down. We were hoping to get better numbers with the new form but the numbers were terrible.

        For us, this approach didn’t work. But who’s to say it won’t in other cases.

        • 4

          Hi Emma,

          I’m assuming your a/b test did not involve a typeform, but simply a form that showed one question at a time…

          I’d like to make it clear that the method of showing one question at a time, is not the magic bullet for getting better completion rates, as your results demonstrate.

          Ui and UX also plays a key part in conversions (probably larger). It’s really about creating a beautiful experience for the respondent in order to increase engagement, by good use of typography, copy & interface.

          Check out my reply to “David” below for more insights on completion rates…

          • 5

            Like others have mentioned in this articles comment section, I too have tested a traditional form vs a multi-step form approach, albeit not a Typeform implementation. However, many of the UX choices Typeform has baked into their form building system were implemented in ours.

            After a lot of testing (tweaking context / copy, interface adjustments, removing requirements for fields, reducing the amount of steps etc.) the traditional static form still reigned supreme.

      • 6

        I went to the link on my note 10.1 and when I scroll though my keyboard is constantly opening and closing shifting the screen up and down.

  2. 7

    I believe there should be a button to return you to the current question in case you scroll to a different position of the form (e.g. to see one of your previous answers), otherwise the focus is lost.

    • 8

      This is the case already. There are 2 arrow buttons in the right hand corner to move between questions if you don’t want to scroll or swipe…

  3. 9

    This is a model I’ve toyed with in the past, but have struggled with how this will scale to larger more complex forms. Most discussions of online forms are limited to simple forms like contact forms with relatively few inputs. How could this model be applied to something like case management software or electronic health records? Where there are 100s of form elements that are generally packed in as tight as possible as default form elements. The irony is that data entry speed and accuracy are even more important in these contexts, but the UIs have not progressed beyond a digital version of a file folder with tabs and all.

    • 10

      Victor Bjelkholm

      September 26, 2014 9:21 pm

      Disclaimer, I’m a engineer working at Typeform.

      That’s exactly the problem that Typeform is trying to solve. By realising that a form is seldom complex, Typeform makes the entry as simple as possible to convey the right message, at the right time, with features like “Logic jumps” where you can decide which question gets showed when.

      However, Typeform is not alone with having features like logic jumps, other form applications online have this as well. What Typeform is alone with, is the user experience focus, where everything should be as easy to fill out as possible, no matter which device the user is using. Is not only about showing/hiding questions at the right time. It’s also about making the right questions being as easy to fill as possible. The goal is to reach the maximum percentage of “fill-out-rate” as possible.

      I’m sure, that if you try out Typeform, you’ll see that the experience filling out a Typeform is completely different compared to anything else on the market.

  4. 11

    You mean you invented a wizard? I believe that’s already been done…

    Good read, albeit a little conceded.

  5. 12

    A lot of designs & plugins, these days, come with many spectacular features but sometimes designers fail to understand that other designers may get how to move around an application but the end-user might be the one with the problem. Using traditional approaches to things generally seems to win in terms of conversion (for quite a few industries) – I figure it’s because users aren’t use to the rapid changes that have happened on the Internet.


    • 13

      Hi David,

      I’d like to try and put things into perspective here…

      There are two types of scenarios in play here:

      1) User wants/must complete the form or risk some degree of loss.
      2) Form creator wants as many users to complete, respondent has nothing to lose.

      Using a typeform in scenario 1 won’t have much positive impact on the completion rate of the form, since the respondent was probably already intent on completing before even glancing at the form.

      In scenario 2, the respondent casually arrives at the form. He/she does not have any pre-disposed intention to complete and the reward for doing so is low or non-existant .
      The common denominator for increasing completion rates here (conversion), is the level of engagement. This is where I believe typeform does it’s job really well. In fact, our data shows that on average 55% of unique visitors to typeforms actually complete (based on a data sample of over 14Million unique visitors to our forms since we launched). Time and time again users (typeform creators), report that their completion rates went through the roof in low completion scenarios e.g

      I’d encourage you to pick a scenario where your traditional form is struggling to get good conversions (unique visits vs completes) and see if you can up the rate by using a typeform.

  6. 14

    Awesome work! The UX focus is refreshing, witty and elegant. You’re an inspiration!

    Ivar Johnson.

  7. 16

    Great article. I think the type form works well. I love the conversational tone you employed here as it makes the form less lifeless. Though I’d love to see the progress indicator be more prominent. I think that would address the issues raised about completion fatigue from not being able to see the entire form.

  8. 17

    As articulate as you are, you screwed up the grammar on two sentences where it should have been obvious:

    There’s ways to make traditional forms better, by including more whitespace, separating forms into sections, and more. There’s standards behind the way forms look and feel, which have kept them far more similar to a paper form than something imagined just for screens.

    What that says is “There is ways” and “There is standards” when it should be “There are ways…” and “There are standard..” . Just upholding the standards of a language I respect.

  9. 18

    It’s nice to see someone think outside the box and attempt something new. I’ve built similar forms in the past and they worked well for niche applications. They weren’t nearly as polished as Typeform. I know plenty of use cases where Typeform doesn’t work, but there are several where this interface might really excel. Kudos!

  10. 19

    Great idea and great work David. I’ve deep admiration for people that can work 4 years on a product (on a design idea) to make it outstanding. I love many things about this new form interaction. You can try to mimic a conversation also with the standard way (my personal reference in this field is Caroline Jarrett’s “Forms that work”), but this way seems more effective, like a real conversation.
    Just a few observations about my personal experience on using typeform that maybe you’ll find useful David (I’ll refer to your link above

    1) When in area text (question 2) the classic “press [ENTER] becomes “press [SHIFT] + [ENTER]”. Here I see 2 problems: first you change the usual command to submit the single question and continue (on why this is bad you can check “Perception biased by experience” chapter 1 in “Designing with the mind in mind” by Johnson). second I don’t understand the reason of this choice: [SHIT] + [ENTER] is already the classic combination for \n (line break) in certain special conditions when [ENTER] is the primary action: for example when you don’t want to jump to another bullet point in a list, or when you don’t want to send a message in whatsapp (but you want to write on a new line)

    2) But my deeper point is: do you really need [ENTER]? I read carefully what you wrote about [TAB] and [ENTER] and that [ENTER] rational: it’s the “complete an action” button. I’m pretty sure you tested many prototypes. And probably I should do the same before talking too much ;) But I am not sure you need people to click/tap [ENTER] each time, also because you want them to feel free to change their answers. [ENTER] feels like I somehow commit to my choice. [CONTINUE] would feel less binding. that make me think that you already have [CONTINUE], it’s the arrow icon…

    3) Arrow icons are on the bottom right corner of the viewport, and on my wide monitor are too far away from the questions. The problem here is the risk that there is no mapping (Norman’s “The design of everyday things”) between the two objects. Why not putting the arrows in the context? and maybe one above the question and one below? This way you could – maybe – get rid of [ENTER] making things simple (and not simpler as you and Albert would say ;-))

    4) Selecting a multi-choice (“checkbox”) and a one-choice (“radio button”) has the same grahics. It feels not right, but here probably I am still bond to the “old” conceptual model of forms. And when someone changes the model we suffer, even when the changes are for the better. I would explore the possibility to have different graphics for different kind of questions (also you use the “V”, which is the sign for “checkbox”, for “radio” instead of a completely new sign for both), to help people understand the difference in the type of answer without having to carefully read the question

    5) Talking about one-choice questions (“radio buttons”), I don’t like the different behaviour of these kind questions: I don’t need [ENTER] to go on. As far as I saw it’s the only exception in the way the typeform “continue” function works

    6) I would probably like a fixed title (the form title) to always stay on top to give me context (maybe a phone call, or an email check, back and forth between browser tabs and I forget what kind of form I was filling in). To infer that form the question is more mental effort

    7) I would probably like the progress bar to also be on top

    8) the [SUBMIT] button is on a different background and a bit far away from the last question. I would like more visual connection, and after many question the copy could help more in this direction, e.g. [SUBMIT FORM] or something like that.

    As I said before, I hope these quick notes can be useful to you. Just my small contribution to an original idea and a great product.

    • 20

      Many typos in my post, I’m sorry…especially with Robert.

    • 21

      Thanks Luca for taking the time to write such a extensive post. I’ll reply fully asap. Today we are launching a new public website….so I’ll answer you tomorrow.

    • 22

      David Okuniev

      October 2, 2014 3:52 pm

      Hey Luca sorry for the late reply, I was hoping to come back earlier…

      Here are my responses to your comments:

      1) The decision to use [Shift]+[Enter] to move onto the next question was not taken lightly. Our principle reason for doing this, was to avoid the users accidentally moving onto the next question. We use [Enter] in the other fields in order to move onto the next question (once the answer is given); had we done this in the Multiline field, many users would have inadvertently jumped to the next question, when all they wanted to do was just create a simple line break.
      I think that in the context of a typeform, once the user is writing away in a Multiline text field it feels more natural to simply use [Enter] to create a line break. Admittedly [Shift] + [Enter] is already the classic combination for a line break in certain conditions, but I think you need to be at least a little tech savvy to know this. I still think, given the context we made the right choice at the time. That said, the jury is split even in our own team, and we should not rule out eventually changing it.

      2) It’s important to distiguish the difference between what [Tab] and [ENTER] imply.

      [TAB] implies navigation
      [ENTER] implies confirmation

      One of the cool features of a typeform, is the inline validation you see as you progress through the questions, this avoids having a bunch of validation messages at the end of the form which is always very annoying. It’s therefore crucial to have the [TAB] and [ENTER] distinction in place. If you tab through all the questions, validation is overridden (except in the submit). [Enter] confirms your entry and validates it in the moment.

      Another reason why confirming is so important within the flow of a typeform is to do with our Logic Jump feature (conditional questions). In order to do branching we must have a clear intention on confirmation from the respondent.

      3) The arrow keys are intended as secondary navigation method. The primary navigation method is still the scroll, tab or arrow keys (on desktop). In my opinion bringing them right into the action would be distracting for the respondent and would unnecessarily complicate the UI .

      4) I think your suggestion could work well. Having a subtle difference will help the user know what action to take. Thanks.

      5) That’s because in a single selection (open ended question) there is a clear moment when the field is completed. In an open ended question, the respondent can write on.

      6) You can do this on Typeform, using our ‘question groups’ feature. It allows you to create a sticky header that accompanies a group of questions as they flow past.

      7) not much to comment here…

      8) We have plans to push this further up the page. But it’s good you brought it to my attention anyway!

      Thanks again for opening up the conversation.


      • 23

        Hi David,

        thanks for you reply :)

        1) I understand your reasons, but I still think that the cost of “same action two keys” is more then its benefit (avoid the users accidentally moving onto the next question)

        2) Why can’t you validate on [Tab]? When I do something (type an answer) and [Tab] I state my intention

        3) On second thought I guess you’re right: icons in the middle of the screen wouldn’t be neat (at least not as much as in the Star Wars UI ;-)

        5) Yes the questions are of a different kind, but still I would always like to control the flow. You are assuming that when I select an option I’m done (when I can select only one). Maybe not, maybe I want to think a little bit more. And again, when I do the same thing (select a choice), I expect the same UI behavior.

        Maybe now, to be fair, I should make a list of the things I like about Typeform ;-) They are many.

  11. 24

    George Birbilis

    October 4, 2014 11:09 am

    So, are we rediscovering wizard-type step-by-step input UIs?

  12. 25

    I’m a university student, an aspiring entrepreneur and a staunch advocate that if design and usability were as focused on as “functionality” the world would be a better place.
    At the risk of sounding sycophantic:
    You’re awesome.
    How can I be like you?
    Where did you learn/study UI and UX ?

  13. 26

    These guys are quite smart enough to steal you money as there payment terms are quite fluffy “The contract shall be automatically renewed for monthly or annual periods, depending on the period contracted, unless the user, at any time, decides to cancel the contract through the “My account” section.”. They do force sales with no prior notification that we are going to charge you or your subscription going to renew in these many days like other authentic websites do. Think 10 times before taking services from them.


↑ Back to top