Tips for working with developers
Working with software developers can be a really fun experience, or incredibly frustrating. It’s important that you have a good relationship with your developer, and if they’re really good they’ll help you out and point you in the right direction if they think there is a better way to do it. After all, they do this every day – and chances are this is your first project.
Some developers will give you exactly what you asked for (or at least their understanding of it). To be absolutely sure you should:
- Spend your time defining your requirements.
- Do a small piece of work as a test exercise to check they are up to the job, and also to make sure you work well together – build it iteratively, not all in one go.
- If possible meet face-to-face, or share screens while you’re talking so you can point at things you want to do.
There are a number of ways in which you can improve your chances of getting exactly what you want. The same approach applies whether you are building a website or a mobile app.
- Overview – what is the idea supposed to achieve
- Point to similar examples
- Create a sitemap
- Flowchart
- Wireframes / Mockups
- User stories
- Meet face-to-face.
Creating a sitemap
If you only do one thing, create an overview of all the pages or screens that will form the basis of your website or app. This helps you visualise the structure, but also helps your developer understand the scale of the work, and how things relate together at a hierarchical level. For example, in the sitemap diagram below, you can see that the most important page is the Home Page, followed by four pages which are of the same importance (About us, Products, Blog and Contact us). Then the next level down are the indivdual products.
Creating a flowchart
Flowcharts are very useful to explain to the developer how users will flow logically through your website or app. Take this common example of Registration and Login. The blue boxes illustrate what most people think is involved. However the red boxes show that there is usually a more detailed level of complexity, and interdependence between seemingly unrelated functions. If you’re only building a website to display information, this is probably overkill. But if you’re building an app, or an eCommerce servce then flowcharts are vital.
Creating Wireframes
As the saying goes, ‘a picture paints a thousand words’. I’ve recently seen an email where an entrepreneur has explained everything they want to appear on the screen of their app in considerable detail, only for the developer to misunderstand what was required. The level of detail in the email was commedable, but it was the wrong approach.
By creating a wireframe (which may be as simple as a hand-drawing which you take a photo of) you are helping the developer visualise what you are aiming for. You will already have an idea in your mind of how you expect it to appear, but undertaking this exercise will also help you think of other things that you might want to do in the future, or blatent gaps in your original plans.
The following is an example of a wireframe.
User stories
We’re now getting into more detailed requirements here, and user stories are becoming an increasingly popular way to list every key function that you’d like your service to do. Think of it as a list of things that your user will do, but also things that you’ll need to do behind the scenes to support the customer.
- As a user I would like to add a photo to my profile
- As a user I would like to change my password
- As an administrator I would like to create a voucher
- As an administrator I would like to block a user
Staying on track
It is very easy to get carried away when designing or building a product. When you’re starting out, you should only try to do the absolute minimum required to test an idea or get your first users. The Lean Startup, a book by Eric Ries is a good read, and covers this concept known as creating the Minimum Viable Product (MVP). However tempted you are, try to build your product iteratively – one bit at a time, rather than everything all at once. After all, you want to leave yourself something interesting to tell people in your next blog post!
Checking the work as you go along is also vital. You should do this every day or two at a minimum (unless otherwise advised by your developer) because you can spot problems early on and save a lot of re-work.
When you do find issues, the way in which you report them is extremely important, and can save you time and frustration. Keeping a list in a spreadsheet helps you keep track of every issue, and make sure that they are all fixed. You need to be 100% clear what you are talking about when reporting an issue or a change you want to make. Here’s an example from my other business, MovieGlu, where I’m describing a problem and what I was actually expecting.
The link in the example above points to the screenshot below.
Examples of poor descriptions:
- “Doesn’t work”
- “Wrong colour”
Examples of good descriptions:
- “The button is unresponsive when clicked”
- “Text is red, but should be blue”.
Need more help and advice?
If you’d like to arrange some coaching on these subjects or even hand over the management of your development to someone with experience, contact me for an informal chat and we’ll see what we can do.
