The Why, How, and What of Onsite UX/UI User Surveys

Onsite user surveys are a cost-efficient way to gather not only quantitative but also qualitative information useful for business decisions.  There are two basic types of onsite surveys: website-related (UX/UI surveys) and offering-related (about the actual product or service promoted through your website). In this post, I will concentrate on the first type of questionnaires and give some guidance on how successfully set up, run and evaluate them.


As with other projects, we always start with a Why – question. Without formulating a clear purpose, you will not be able to derive much useful information from the survey. Do not start with a general question such as “Do users find the website easy to use?”- but concentrate on particular UI components (e.g. top navigation, product finder or product descriptions). You may also run a survey to gather more insight into the data from analytics, e.g. high bounce rate on a particular page or repeated shopping cart abandonment by users. Another possibility is to follow up on a particular user journey (registration, form submission).

When & Where

When and Where to place the user survey will depend on its purpose. Say, if you are testing a new color scheme of the site you could place a survey on most pages, but if you are interested why users do not manage to submit forms, you will display a questionnaire only on Submission Failed page.

Besides placing the survey on relevant pages, you may additionally target a random sample of users, i.e. 10% of visitors, or show the questionnaire after a certain time on site/to returning users. Sometimes it is also possible to display a survey on an event, such as a button click or multiple mouse-overs a page element. If the software you use allows gathering user data, consider targeting certain user groups (e.g. users coming from a particular device or from a certain country).

When displaying the survey, decide how long the delay should be. If a user first needs to read the contents of the page, the delay may be up to a minute. In any case, loading the questionnaire simultaneously with the page may confuse users, so several seconds delay will still be appropriate (it will also exclude users who are in the “explore mode”, i.e. just clicking through the pages).


Speaking about How the survey will be set up, it can be a pop-up, a slide-out panel or a Feedback button (during user journey or placed in the header of the page). In any case, you will need to include a recognizable Close button to avoid irritating users who do not wish to participate. You may, however, display the survey again at a later point/during the next visit or allow the visitor to choose, by implementing a Maybe Later button.


When deciding What to include in the survey, consider the number and the type of questions you want to ask.  Generally true: the shorter the survey – the higher the submission rate. If you want to ask questions on different areas of the website, break them into two or three smaller surveys and display upon user interaction.

As for the type of questions asked, open fields and ratings will probably give you the most insights into how users perceive your site. If possible, avoid asking many yes/no or very broad questions, such as: “What do you think of our new site?”

Users may also be reluctant to provide personal details, so reduce personal questions to a minimum. In other words, every question should fulfill the purpose of the survey or be removed.


Once the user survey is live, continue monitoring and adjusting it, whilst carefully recording all changes made in the process. Some adjustments can be: broaden the display rules if too few visitors view the forms, reformulate a question that seems to cause misunderstanding, exclude some user group from targeting.


Last but not least: results processing. You may report daily, weekly or monthly, depending on the traffic volume and stakeholder requirements. The reports you produce should have the same format in order to compare results over time. Questions with open fields are the most useful, but also the most time-consuming to evaluate. You can group responses into categories and later re-formulate the question as a multiple-choice, still leaving one variant as open field.

With UX/UI surveys, you are likely to get some irrelevant responses, such as comments about the product or customer service queries. Make sure to have a process to deal with such responses in place.

As a short conclusion, here are some do’s and don’t’s of onsite UX/UI surveys.

The Why, How, and What of Onsite UX/UI User Surveys

Share this post

The Best Way to Go Mobile: Consider Your Options

There are three ways of going mobile: responsive design, a Web app and a native app. You can also use a combination of these three types.

The importance of adaptingcomputer and smartphone your website to mobile is indisputable in 2020. Google adapted “mobile first principle” last year. However, if you have not made the transition yet or not sure if it has worked well, one important question arises: what is the best way of doing it?

Basically, there are three ways: programming your page to adapt to different screen sizes and devices (responsive design), designing a mobile website (including so-called web app) or creating your own app launched through app stores (a native app). You can have a combination of these types in one application (a hybrid app), however, this is less common.

Here I would like to share some advice on these three possibilities.

You should choose responsive design if you:

  • Have a website that does not require a lot of interaction (e.g. a news website or a blog);
  • Want to save time and effort by maintaining one website only;
  • Think that your users would scroll from top to bottom if the page contains a lot of information and are fine with longer loading times.

A mobile website is the best choice if you:

  • Have a website that is not visited by the same users very frequently or where users do not spend a lot of time (e.g. a specialized online shop or an online information service);
  • Want to offer better user experience by optimizing content and simplifying navigation;
  • Need your page to be accessible with any mobile device through a browser;
  • Do not mind maintaining two websites: the desktop and the mobile versions.

And finally, you should consider developing a native app if you:

  • Have a website where users tend to spend a lot of time (a social network or an entertainment platform);
  • Want to use extra capabilities of mobile hardware: e.g. the camera or the GPS of a device;
  • Think that you can offer users enough extra value to motivate them to download your app;
  • Do not mind the dependence on app stores;
  • Can afford higher costs in developing applications for different device types.

Currently, developing a mobile website is slowly losing its popularity. The majority of CMS and website builders come with responsive layout option as a standard. However, you will still need to make adjustment to your website to optimize it for mobile users, especially if you think (or better: have data proving) that your website is mostly visited on mobile. As for the apps, although the app market is constantly growing, the competition is growing, too. Also, if a user thinks that an app does not offer extra value to them or if they are not a heavy user of this app, they will definitely prefer not to clutter their mobile storage with it.

Let us look at some examples. and Deutsche Bahn have developed a mobile page (for occasional users) and a native app (for heavy users).

The majority of websites on the internet (e.g. HubSpot) have implemented responsive design that enables readers to access the blog from any device.

McDonalds has both responsive design and a native app (used as a restaurant finder and for distributing coupons). Some fast fashion labels (e.g. Orsay) adapted the same strategy.

As you see, in most cases an app is combined with a responsive design or a mobile website. They may perform similar or different functions. The main thing to consider is how to offer the best experience for the users and how to meet their needs in interacting with your website.

Share this post

The Basics of Paper Prototyping

Paper prototyping allows early testing of a UI design for any kind of software. The simplest method is drawing a user interface or a series of “screens”.

This post is a recap of the Scrum User Group meeting on February 5, 2014, in Karlsruhe.Paper prototyping

During the workshop, the participants were shown some sample drawings and then could put the theory into practice, by developing a paper prototype for a restaurant app.

So, what is actually paper prototyping? This method allows for early testing of a user interface design for any kind of software. The simplest method of paper prototyping is drawing of a user interface or a series of “screens” the end-user will see. The clear advantage of this method is that it saves a lot of money and time in testing and trying out different designs before the actual development has taken place.

Some important things to remember whilst applying paper prototyping are:

  • It is better to have cross-departmental teams involving somebody from an IT, a designer, a usability specialist and possibly a marketing/sales specialist. Only in this way it is possible to evaluate the ideas from a 360-degree angle. As an example: often a small change in the design requires a lot of extra work for the IT that could be avoided if the prototype had been discussed by the whole of the development team from the very start.
  • The initial design should be kept simple, without much detail (e.g. the texts can be omitted first),  the main focus should be on the layout and functionality of the software.
  • Paper prototyping naturally has limitations in comparison to the testing on the devices, e.g. interactivity or performance on different screen sizes. These parameters should definitely be kept in mind as an adjustment in the design may be required later.
  • Remember that one picture often says more than a thousand words. Do not be reluctant to draw, even if you think you are not good at drawing. In essence, most  Graphic User Interface (GUS) elements can be depicted using simple geometric forms, e.g. “a trash bin” is nothing more than a cylinder with a parallel line with a dot on top of it.
  • Consider the user journey in developing your paper prototype. Does the user expect a “next” button at the top or bottom of the screen? Does he/she find a confirmation screen helpful? Though it is nice to be creative, the usability and clarity of your GUS  should be the primary goal.

All in all, paper prototyping is important in the initial stages of a software development process, and if done accurately, helps to save a lot of effort during the development stage.


Share this post