By Darren Beale

Developers tend to use technical jargon and clients tend to ask for a feature they want, but don’t often discuss how the feature should work. This leads to a disconnect between both parties and can lead to frustration. At Siftware we don’t use technical jargon with clients, and we try to educate clients on how to effectively get their idea into a task in our project management software so that we can build the feature correctly first time around.

Make a list of things you would like carrying out & prioritise them

The first thing to do when you start working with a development team on retainer is to create and maintain a backlog of tasks that need to be carried out on the application. This usually compromises feature requests, bug reports and styling changes. This backlog then needs to be ordered top to bottom, highest priority to lowest priority. We even have a separate task list every month to segment the tasks we will be working on in that particular month. We work with our clients to decide on what can be achieved in a month within their budget / time allocation and more often than not we have everything signed off and deployed because of how well this process can work when done correctly.

Write out well-formed feature requests

When you ask for a new feature in your application many people have the tendency to simply say “We need to integrate Google Drive” without explaining what the feature should actually do and how the feature should work. There is inevitably a disconnect between what you can vision inside your head and what the developers understand from your request. The best way to work around any potential faults in the process is to be explicit with your requests. You should include the following information:-

  1. How the feature should work
  2. How it will benefit stakeholders
  3. Any wireframes or diagrams you could create

If your feature request doesn’t answer the questions above then its likely that your developers won’t be able to discern exactly what you need first time around and will inevitably come back to you with questions. The more information you put into the original feature request the less chance you have of questions to come back from the development team.

Report bugs effectively

When reporting bugs in the application be sure to include all information that the developers will need to replicate the issue to properly understand it. When reporting bugs you should be covering:

  1. What page you were on
  2. If you filled out a form, the values you entered into each field
  3. What you expected to happen
  4. What actually happened
  5. Any screenshots of errors that may help

By covering all of the above you cover everything the developer needs to know to understand the issue, replicate it and more importantly, put it right. Without this information up front your developer is either likely to ask you for more information, taking more time or could go ahead and fix the issue the way they want to instead of the way you think the fix should be handled.

Allow the development team time to architect the best solution to problems / feature requests

The development team needs to be given ample time to come up with the best way to implement your desired feature. Developing a mew feature quickly without a plan in place can make the application harder to maintain for the long haul and end up costing your business more money if it has to be redeveloped in the future. Allowing a development team enough room to develop new things properly first time around is the difference between a feature that works, and a feature that will continue to work constantly.

Try to break any new functionality the same way your customers will

Inevitably your customers probably aren’t going to be IT wizards and so will fill out forms incorrectly. When testing new functionality you should try to break things on purpose, as it’s best to break things before you deploy it to a production environment. Your developers should also have done this and should be creating functionality that is setup to expect the wrong inputs and report errors efficiently. In this case it’s always best to be able to properly test your application once the developers have deployed it to a test environment so you can have piece of mind and a deeper understanding of the requirements of a feature.

Ensure you get regular status updates

You should be getting regular status updates from your developers. At Siftware we use Teamwork as our project management application and our clients are regularly updated on progress of tasks, we promptly inform them when new functionality has been pushed to test and we let clients know when we will be pushing items live once they have been signed off. This helps keeps our clients in the loop and makes them feel involved in the process as opposed to just shouting into a chamber and hoping to hear something nice back.