In our previous blog we wrote about the advantages if you start with a minimum viable product, then extend the functionality in a series of incremental releases. A so-called continuous development process offers many benefits. And lowers your risks. This second article focuses on further development tips. This time we focus on the development process.
Design and development tips
Front-end developers are not necessarily UX designers. So the first development tip. Let everyone do what they do best! Maybe this means using two separate companies. One for UX design, and another to build your site. We at BSL enjoy the challenge of delivering a pixel-perfect website based on a UX design produced by a third party.
And it’s perhaps stating the obvious, but getting a complete UX design approved by your stakeholders before starting to produce code will save you time. And it will therefore save you money. It removes the risk of ad-hoc decision-making during the development. It avoids time-consuming discussions on shifting requirements.
Working prototype
If you can, ask the UX designers to deliver the design as HTML, CSS and JavaScript that already runs. They should be able to create an online prototype that your users can check using their browsers. This offers many benefits over screenshots or PSD files. Better still, ask the designers to produce a style guide. Your developers will love you for it. It will save time (and your money). And your web application will be consistent and easy-to-use.
Communication is key
Developers do not always realize that communications are crucial. Keeping the client in the loop brings rewards, including client satisfaction and trust. Let them look into your “kitchen”, show them what you’re “doing”. Client involvement can be achieved without slowing you down.
- Share your issue tracker or scrum/kanban boards;
- Give them access to team communications (e.g. Slack) so they can follow conversations;
- Provide a wiki for user guides (yes, you can start that during development);
- Arrange access to a staging server along with credentials to log in.
Interference generally means delays. So, access doesn’t mean that the client should be able to directly interfere with or delay your work. But their involvement means they can see what’s happening. Radio silence makes clients (in general) nervous. They want to be able to follow your progress. Open and honest communication with our clients is one of the things that sets the Bright Side of Life apart.
Plan incremental reviews with the client
You of course need to schedule formal review and QA cycles. And ideally you’ll involve the whole development team. Any concerns should be aggregated, and communicated via an architect, scrum master, account manager or product owner (the person leading the daily standups). Ideally, get the development team involved. Let them develop a feeling of responsibility and ownership. As you can expect, active participation from both sides will bring rewards such as understanding and a shared commitment.
Representative content
Use of dummy images and Lorem Ipsum text during the development won’t help developers to understand the purpose of a site. It can also hide cosmetic issues that become only too obvious during demos and testing. So, ask the client to make at least some real content available for use during both design and development. Its more attractive, and delivers better insights into their goals for the website. And it makes clients think more carefully about what they want to include. They should be eager to show off their content, so encourage them to provide representative material as soon as possible.
Client content is key to a website’s success. So don’t hesitate to point clients to a professional photographer and/or copywriters. Try to get them involved even before the design is made. It helps clients to focus and will save time when deciding on the right design.
Summary
Next week we will post our final blog in this series. It will summarize our advice in part 1, as well as these development tips. Your feedback is very welcome, so feel free to mail the author Martin Postma, or Martyn Simpson. Or get in touch with BSL via our contact page. Join us for a coffee next time you pass by Breukelen on the A2 🙂
This development tips blog post was written by guest author Martin Postma [lolandese] with contributions from Martyn Simpson.
Martin usually writes technical documentation on Drupal.org.
