Gathering user feedback is an essential activity in software development, enabling developers to understand end-user experiences and improve application functionality. In Kenya, where diverse user needs and technological literacy levels exist, effective feedback methods ensure software solutions remain relevant and user-friendly. This chapter focuses on practical approaches to collecting user feedback, emphasizing surveys and form builders as key tools for engaging users and capturing their insights. These methods help software developers deliver applications that meet real-world demands in sectors such as banking, healthcare, and education.

3.1 Method of gathering user feedback

Gathering user feedback means using planned activities to obtain detailed, usable information from the people who work with an application. A software developer chooses a method according to the project context, the type of users and the time and money available. Surveys and form builders are efficient and scalable, questionnaires give a consistent set of questions, and observation shows what users actually do. For example, a developer supporting a point-of-sale application used by shop attendants might send a short survey to all users, watch two attendants serve customers, and use a form to log every problem reported.

3.1.1 Surveys

A survey is a structured way of collecting opinions and experiences from a group of users so that the developer can measure satisfaction, usability and unmet needs. It produces both numbers (for example, 70 per cent of users rate the invoice screen as easy) and comments in the users' own words. Well-designed surveys can reach many users, including remote users with limited internet access, through mobile-friendly formats. Example: a developer who has released a stock-control application to forty shop owners can survey all of them within a week and learn which feature causes the most difficulty.

Designing Effective Surveys

Designing an effective survey requires careful planning so that it is clear, relevant and short enough for users to finish. The wording and layout of the individual questions are covered under Questionnaires; this section deals with the planning of the survey as a whole.

• Clear objectives: Define specific goals for the survey, such as assessing satisfaction with a new release or identifying feature requests, so that every question has a purpose.
• Target respondents: Decide who must answer (all users, or only users of a particular module) and how many responses are needed to represent them fairly.
• Survey length and timing: Keep the survey short, ideally completed in a few minutes, and send it when users have had time to use the software but before they forget their experience, for example one to two weeks after installation.
• Pilot testing: Conduct a pilot with a small group of users to identify ambiguous questions, broken links and time taken to complete before the full launch.
• Consent and privacy: Tell respondents why the data is collected, who will see it and how it will be stored, and ask only for personal details that are really needed.

Survey Distribution Channels

Choosing the right distribution channel is critical to maximise the response rate and to make sure the responses represent all user groups.

• Email campaigns: Effective for users who work with email daily, such as office administrators, and allow personalised invitations and reminders.
• Mobile SMS links: Useful for reaching users with limited internet access but regular mobile phone use, such as field agents or small traders.
• Web-based platforms: Deploy surveys on project websites, client portals or inside the application, where users access the software regularly.
• Social media: Use messaging groups, such as WhatsApp groups of shop owners or traders, to reach informal user communities quickly.
• In-person collection: For users with limited digital access, hand out printed surveys or collect answers verbally during training sessions.

3.1.2 Form builders

Form builders are software tools that let a developer create customised feedback forms without writing code. They are valuable in application support because a bug-report or feedback form can be built, published and changed within hours as requirements change. Example: after a payroll application update, a support officer can build a form in an afternoon where users report errors, attach a screenshot and rate the new screen, and share the link by email or messaging group.

Features of Form Builders

Modern form builders offer a range of features that simplify feedback collection and improve the experience of the person filling in the form.

• Drag-and-drop interface: Enables developers and non-technical staff to design forms by arranging elements visually.
• Customisable templates: Provide ready-made forms that can be adapted to needs such as bug reports, feature requests or training evaluations.
• Conditional logic: Shows or hides questions based on earlier answers, which keeps the form relevant and reduces fatigue. For example, only users who answer "Yes, I had an error" are asked to describe it.
• Multi-platform compatibility: Forms can be opened and submitted on desktops, tablets and smartphones, which suits users on varied devices.
• Integration capabilities: Connect with spreadsheets, databases, email systems or analytics tools to streamline collection and processing.

The common form elements and what each is used for are summarised below.

Selecting an Appropriate Form Builder

Choosing the right form builder means evaluating usability, cost and data security against the needs of the project.

• User-friendliness: Assess how intuitive the tool is for both form creators and respondents, so that little training is needed.
• Cost considerations: Balance features against the budget, comparing free plans with paid plans and noting limits on the number of forms or responses.
• Data privacy: Choose tools that offer secure storage and controlled access so that the collection of personal data is consistent with Kenya's Data Protection Act.
• Offline functionality: Consider builders that allow data entry without a connection and upload later, for users in areas with unstable internet.
• Support and updates: Prefer platforms with active support communities and regular updates to keep them reliable.

Creating Feedback Forms Using Form Builders

Creating an effective feedback form follows a sequence of steps that ensures complete and usable data.

1. Define feedback objectives: Clarify what information is needed, such as user satisfaction, error reports or feature requests.
2. Choose form elements: Select suitable input types, including text fields, multiple-choice questions, rating scales and file uploads.
3. Apply conditional branching: Add logic so that follow-up questions appear only when they apply to the user's earlier answer.
4. Set validation rules: Protect data quality by making key fields mandatory and specifying acceptable formats, such as a valid email address or phone number.
5. Design the user interface: Add branding, clear instructions and a short introduction so that users trust the form and know how long it will take.
6. Test the form: Try the form with a representative group of users on different devices to find usability problems and fix errors before deployment.

Managing and Analysing Form Data

Managing the collected data well is crucial for turning feedback into action.

• Data export: Use export functions to move responses into formats such as CSV or Excel files for analysis in spreadsheet or statistical software.
• Real-time monitoring: Track submissions as they arrive to identify urgent problems, such as a login failure reported by many users.
• Automated notifications: Set alerts for specific responses, such as critical bugs or very low ratings, so that the support team reacts quickly.
• Data visualisation: Use built-in dashboards or external tools to create charts that help stakeholders understand the results.
• Data archiving: Store feedback data securely for future reference and in line with organisational policies.

3.1.3 Questionnaires

A questionnaire is the written set of questions, on paper or on screen, that users answer to give their views on an application. A survey is the whole process of planning, distributing and analysing, while the questionnaire is the instrument used inside it; a questionnaire can also be used alone, for example after a training session or when a support ticket is closed. Example: a developer hands a ten-question questionnaire to shop attendants after their first week with a new point-of-sale application to learn how easy it is to record a sale, apply a discount and print a receipt.

Structure of a questionnaire

A well-organised questionnaire guides the user from the introduction to the final question without confusion.

• Title and introduction: State the purpose, the application being evaluated and the time needed to answer, so that users know what is expected.
• Consent and privacy statement: Explain how answers will be used and whether they are anonymous, and give users the right to skip questions.
• Background questions: Ask a few simple questions about the user's role, experience level and device, which later allow answers to be compared across groups.
• Core questions: Cover the features, tasks and qualities being evaluated, grouped by topic such as speed, ease of use and reliability.
• Open comments: Finish with one or two open questions where users can add anything the earlier questions missed.
• Closing note: Thank the user and say how to contact the support team if they need help.

Question formats

The format of each question decides what kind of data is collected and how easily it can be analysed.

A mix of closed questions, which give quantifiable data, and open-ended questions, which capture detailed opinions, gives the fullest picture.

Writing clear questions

Clear wording makes sure every user understands the question in the same way, which makes the answers comparable.

• Language simplicity: Use simple, clear language suited to the target users, and avoid technical jargon such as "latency" or "UI" unless the users know it.
• Logical flow: Arrange questions in a logical sequence, starting with general questions and moving to specific issues.
• Neutral wording: Avoid leading questions. Instead of "Don't you agree the new invoice screen is fast and easy?", ask "How easy is the new invoice screen to use?"
• One idea per question: Avoid double-barrelled questions such as "Is the app fast and reliable?", because a user may feel differently about each part.
• Balanced answer options: Offer scales with an equal number of positive and negative choices and a neutral midpoint, and include "Not applicable" where a feature may not be used.
• Reasonable length: Keep the questionnaire short enough to finish in a few minutes, because long forms lead to skipped or careless answers.

Administering questionnaires

The way a questionnaire is delivered affects who responds and how honest and complete the answers are.

• Self-administered: Users fill in the questionnaire alone, on paper or on a device, which is cheap and gives privacy but allows misunderstandings to go uncorrected.
• Interviewer-administered: The support officer reads the questions and records the answers, which suits users with low digital or reading skills but takes more time and may make users give polite answers.
• During training or support visits: Handing the questionnaire out at the end of a session gives a high return rate while the experience is fresh.
• After ticket closure: A short automatic questionnaire sent when a support request is resolved measures satisfaction with the help received.
• Follow-up reminders: A polite reminder after a few days increases the number of completed questionnaires.

Recording and coding responses

Answers must be recorded in a consistent form before they can be analysed.

1. Give each questionnaire a number so that paper forms can be traced and checked.
2. Enter the answers into a spreadsheet with one row per respondent and one column per question.
3. Convert scale answers to numbers, for example strongly disagree = 1 to strongly agree = 5.
4. Mark unanswered questions as blank instead of entering zero.
5. Group open-ended answers into themes and give each theme a code.
6. Check a sample of entries against the original forms to catch typing errors.

The average rating for a question is calculated as shown below.

Formula: average rating = sum of ratings ÷ number of responses

Substitution: ratings 4, 5, 3, 4, 2, 5, 4, 3, 4, 5 from 10 users

Working: sum = 4 + 5 + 3 + 4 + 2 + 5 + 4 + 3 + 4 + 5 = 39

Working: average = 39 ÷ 10

Result: average rating = 3.9 out of 5

3.1.4 Observation

Observation is a feedback method in which the developer or support officer watches users work with the application in their normal setting and records what they do, instead of relying on what they say. It is valuable because users often cannot describe difficulties they have learnt to work around. Example: while watching a shop attendant complete sales, a support officer notices that the attendant opens three screens to find the discount button and keeps a handwritten price list beside the till. Neither problem was mentioned in any survey.

Types of observation

Different kinds of observation suit different questions and levels of user comfort.

• Direct observation: The observer sits near the user and watches openly, noting how tasks are completed and where difficulties arise.
• Participant observation: The observer takes part in the work, for example by serving customers using the application, to understand the user's experience from the inside.
• Shadowing: The observer follows a user through a whole working day or shift to see how the application fits into the full workflow.
• Think-aloud sessions: The user performs set tasks and says out loud what they are thinking, which reveals confusion about labels, menus and messages.
• Remote session recording: With the user's consent, screen-recording or usage-analytics tools capture clicks and navigation, which suits users who are far from the support team.
• Structured and unstructured observation: In structured observation the observer follows a checklist of tasks; in unstructured observation the observer records anything interesting without a fixed list.

Observation tools and materials

The observer needs simple tools prepared before the session.

Planning and conducting an observation session

A planned session produces reliable evidence and causes the least disturbance to the user's work.

1. Set the objective: Decide what you want to learn, such as how easily new users complete a sale or how long month-end reporting takes.
2. Select users and tasks: Choose users from different roles and experience levels, and list the real tasks to be observed.
3. Obtain permission: Explain the purpose to the user and their supervisor, and obtain consent, especially if the session will be recorded.
4. Prepare materials: Prepare the checklist, timer and recording tools, and test them before the session.
5. Observe without interfering: Watch quietly, note what the user does, and avoid helping or correcting unless the user is completely stuck.
6. Record details: Note task times, errors, hesitations, workarounds, requests for help and any comments the user makes.
7. Hold a short debrief: Afterwards, ask the user why they took certain actions and what they found difficult, to confirm your interpretation.
8. Write up promptly: Complete your notes the same day while details are fresh, and file them with the session identifier.

What to record during observation

A consistent set of observations makes sessions comparable and helps decide which problems matter most.

• Task time: The time from the start to the end of each task, compared with the time expected for an experienced user.
• Errors and retries: Wrong entries, failed actions and repeated attempts, with the screen where they occurred.
• Hesitation and confusion: Pauses, searching through menus or looking confused, which point to unclear labels or layout.
• Workarounds: Paper notes, separate spreadsheets or unofficial shortcuts that users rely on because the application does not meet a need.
• Environment: Device type, screen size, lighting, interruptions and the quality of the internet connection.

Ethics and accuracy in observation

Observation is only useful if users behave naturally and their rights are respected.

• Informed consent: Tell users they are being observed, why, and how the notes or recordings will be used.
• Confidentiality: Remove names and any customer data seen on screen from notes and recordings, in line with Kenya's Data Protection Act.
• Observer effect: Users may work more carefully when watched, so allow a few minutes for them to settle and, where possible, observe more than one session.
• Respect for work: Schedule sessions so that they do not hold up customers or urgent work.
• Objective notes: Record what happened separately from your interpretation to avoid bias.

Strengths and limitations of observation

Knowing the strengths and weaknesses of the method helps in deciding when to use it.

• Shows real behaviour: It records what users do, which may differ from what they say in surveys.
• Reveals hidden problems: It uncovers workarounds and difficulties that users have stopped noticing.
• Time-consuming: Each session takes time to arrange, conduct and write up, so only a small number of users can be observed.
• Small samples: The findings come from few users and may not represent everyone, so they are best confirmed with a survey.
• Observer bias: The observer's expectations can influence what is noticed, which a checklist and a second observer help to reduce.

Comparing and combining feedback methods

No single method gives a complete picture, so a support team selects methods according to the question it needs answered. The table compares the four methods covered above.

Methods work best when combined. For example, a survey may show that many users rate the stock screen poorly, observation of three users then shows that the search box is hidden, and a form-builder feedback form after the fix confirms whether satisfaction has improved.

Chapter Summary

This chapter focused on effective methods for gathering user feedback to improve end-user support. It began by exploring various activities involved in collecting feedback, emphasizing the importance of structured approaches to understand user experiences and needs. Surveys were highlighted as a key tool, detailing how well-designed questionnaires can capture valuable insights from users about their satisfaction and challenges with IT services. The chapter then examined project work related to feedback gathering, illustrating how collaborative efforts can enhance the relevance and application of collected data. Lastly, form builders were introduced as practical tools that enable the creation of customized feedback forms, facilitating efficient and targeted data collection. Together, these methods provide a comprehensive framework for systematically obtaining user input to inform service improvements and support strategies.