Forward Deployed Engineering: Turn Customer Feedback into Better Software

The worker opens a new application and hesitates on the first screen. The designer assumes that the screen is clear. The engineer assumes that the code works. Still, the worker does not know which button to click. This small story teaches us something valuable. Working software needs to be designed according to the user and the task, not just the file of the designer.

Forward deployed engineering puts an engineer face-to-face with the customer. This kind of direct interaction can help the team to transform user feedback into meaningful improvements. Feedback consists of what users say and what you can observe from their behavior. The user’s wish for a larger button may show a more serious issue like a confusion about actions.

This guide describes a straightforward approach to listening, building a prototype, testing it, and refining it. Consider a repair shop that would like to have a more useful scheduling system. The examples here are planning examples and not the actual result with customers. New readers can follow the ideas without knowing how to code. The company will need clearly defined ownership, proper validation, and support strategy.

Watch a task from start to finish

Choose one normal process. In the repair shop, an employee schedules a visit for a customer. Get the employee to show the process. He/she might look at the schedule, make a note, and contact someone else. Observe the entire process. The list of screens for the app will not capture all the decisions and handoffs.

Look out for pauses and repetition. Is there any reason why the worker writes the same name twice? Is the worker waiting for a call before giving the date? Find out why. The seemingly slow step will help avoid double bookings of the same time slot. Understand the value of the step before making any changes. Questions will be more helpful than hastily designing a new screen.

Talk to different users

The problem perceived by the owner of the business, the person making the bookings, and the repair person can be different. The owner needs fewer missed appointments, the booking clerk needs clear time slots, and the repair person needs enough time for each job. Find a common ground. The screen designed with the needs of the person paying for the service in mind may not suit the user.

Simple questions help. What are you trying to finish? What makes you stop? Which kind of error frightens you most? Let users show an example, instead of asking them to develop the entire solution. Ensure confidential data of customers is kept confidential during this dialogue. Anonymized samples often can reveal the issue at stake, without having to give any personal customer data (names, phones etc).

Separate the request from the need

A user may ask for another button. It is one of potential solutions, and not the actual need. Probably, they need to reproduce the existing order without typing all the data again. Discover what result it helps them to achieve with such a button. Maybe, there is another way of achieving it, and a clear copy function with necessary inputs only is enough.

Define the need in one sentence. For instance, a worker is supposed to generate a follow-up visit but keep the customer's specified information. This is the foundation of your design, and it gives room for comparing possible solutions to the problem. When all the requests are converted into features at once, the application will grow, but the initial problem will still be unclear.

Choose one first improvement

Select an appropriate change that your team could build and test within a limited scope. The repair shop may begin with selecting a visit time slot. If you do not need the payment and stock functions for your first task, leave them out and consider building them in the next release. Inform the users about the limits.

Decide on who is allowed to create policies. If there are disputes about duration of bookings, engineer should not guess on what policy is right. This question must be answered by a business owner. A small reminder on what was decided along with the explanation would be useful. Proper policies allow to design the project according to the company, not personal likes.

Draw an early version

Prototype is a sample version, created for testing the concept. It could be either a drawing of screens or a clickable version of a number of screens. Prototype would show placement of information and buttons. Prototype would not assure that reservations are stored and cannot overlap. What features can and cannot be tested on this version?

Use realistic labels and content. Even though the screen looks good with all of the dummy text, it could have issues related to long labels and instructions. Don’t forget about the empty calendar and a slot that is not available. Users should be able to understand what they mean. The initial phase of design should consider typical problems, not the simplest scenario of use.

Give the user a task to try

Ask the employee to schedule a follow-up appointment for a hypothetical customer. Don’t specify which buttons to click; observe where they hesitate or even change their mind. By directing users at each step, you might prove that the user can do tasks by following instructions instead of proving that your design allows understanding of the task.

Wait until the user is done talking before you start explaining the screen. This will give you an idea of the problems related to unclear wording. Ask what the user expected the button to accomplish. Document the error using clear language. It is important for the team to know what aspect of the task did not work, rather than just knowing that the user hated a certain colour.

Include people with different needs

The user might depend on keyboard navigation. Others could use mobile devices or accessibility technologies like text-to-speech. You need to make sure that your design accommodates the needs of these users. Look at labels, focus, errors, and status messages. What is easy for one user to understand can be difficult for another to complete.

W3C accessibility introduction offers reasons why access is needed by different users. Start from here and test your real task. Some issues could be revealed by a checking tool, but it will not help to guarantee understanding of a change by each user. Try combining testing of a task with a checker and real testing of the task with real people in the real environment.

Make feedback easy to act on

Keep the brief issue list. Describe what task was checked, what expectations had been there, what result you have got. Show who is going to make the decision and how the team will check the resolution. It is easier to follow this brief record than read the long discussion with nothing to do after it.

Prioritize the problems based on their impact. For instance, the incorrect booking date would have a bigger impact than the space between icons. There are problems that prevent the first release; other problems can be postponed for further investigation. Explain the reasons for your choices. The users would lose faith if they gave feedback and didn't get any information back about it, even though there is a good reason for the postponement.

Connect the design with real rules

The calendar will show an open spot, but the spot is booked by another person. The software needs to check the current rule before booking the visit. Having a colored square on the screen isn't a guarantee that you can use this spot. The engineer needs to make sure that there is a reaction strategy if the spot gets changed.

It also works for access. The employee can see a booking but cannot cancel it. Explain the reason on the screen and look up the policy according to which the request will be processed. Design and code must match. Close work with customers helps the team find these details early.

Use Gen AI with clear feedback

Gen AI can produce a draft reminder or summarize notes. If the booking system has such a function, make sure that the text is a draft and let the employee modify or refuse it. Ask if the draft contained all the necessary information and was written fluently. Fluency is not a guarantee that all dates and services were mentioned correctly.

The AI assignment must remain simple initially. For instance, prepare a reminder from a confirmed booking. Do not let AI secretly change a booking or promise a service the shop does not offer. Check false and incomplete facts. Check the message and the real action around it. The customer experiences them as one journey.

Review changes after launch

Listening should continue even after deployment of the app. This would reveal certain problems that might not have been evident during limited testing. Record unclear reservations, common help requests, and incomplete assignments. Relate them to the initial goal. Increased daily users are helpful but do not in themselves show that bookings have become simpler.

Set a review process and the owner. Describe how the user reports a problem and what kind of information helps the team to locate the problem. Do not expose any sensitive information in general support chatrooms. Test changes on the affected task before releasing them further. A feedback loop is a regular activity in software development, not a rare thing that happens just before releasing a new version.

How Digitonix can help

UI/UX design and software development by Digitonix are useful topics to talk about this technique. Pick one user task, current screens, and examples of common problems. Ask for a prototype, user criteria, and decision owners. Check that the suggested team knows how to use user feedback.

The project can use either React for its web-based screens or Flutter for its mobile app. This is based on the type of work being done and the type of devices used. By contacting Digitonix, give the description of the desired result. Ask how this will be monitored and sustained rather than just judging the process by the tools used.

Frequently asked questions

What makes customer feedback useful?

Constructive feedback gives a description of the actual task and the actual problem. It tells what was expected and what was achieved. A request like making something better is hard to follow up on. Ask about an example of the request, learn the need behind it, and agree on a method to decide if the improvement was made.

Should every user request become a feature?

Not at all. Understand why the request is necessary and what impact it has on the task. Some requests may show poorly worded instructions or missing rules rather than an added feature. Check all potential solutions and decide priorities. An application that started out simple will become difficult to navigate if all proposals add yet another button while not addressing the primary problem.

Can a prototype prove the software is ready?

A prototype can test some ideas. It does not prove the whole system is ready. Its limits depend on how it was built. For example, a sketch can check labels and layout design while working code can do more. Neither one of these methods can be seen as evidence for all possible integrations, access rules, and failures. List all tests left to be done before release.

How does this relate to an FDE?

A forward deployed engineer works close to the customer and connects user needs with useful software. Each employer implements it in a unique way. Ask about how the engineer is going to participate in users' discussions, solve any questions that emerge, work with the design and business owners, etc. Both parties have to agree that the aim is completing a useful task.

What should a feedback handover include?

Make sure to include a list of user tasks, decisions that are made, open issues, the owners, and the way to check important changes. Provide an easy mechanism for notifying about new problems. The team should know how to use feedback after launch. Future changes should not depend on one person remembering every project conversation.