Let’s say you need to have a donate page designed for your company’s website. You’ve been given a specific schedule for completion, as well as a budget. Sounds simple, right? Well, any experienced developer will tell you that even the simplest of projects can become a nightmare without proper and constant communication, clearly defined MVPs and prototypes, and through user acceptance testing. If you’re under the gun to get this project in on time and under budget, you’ll definitely want to keep these suggestions in mind.
#5 Define Your Milestones, Especially the MVP
Before you do anything else, make sure you have a good idea what your minimally viable product (MVP) is for this project. The sooner the MVP goes live, the sooner real-world users can get in there and give you feedback—be it features that need tweaking, or other things they like or don’t like as users. While you should develop a clear vision for what subsequent versions of your MVP should look like, be prepared to pivot based on user feedback.
Example: Let’s go back to that quick donate page. What basic elements would your MVP need in order to be successful? Maybe you start out with something as simple as a single page with a field to enter a donation amount, and a checkout button. Whatever it is, make sure you clearly define your starting point to the development team before you even think about future improvements like suggested donation amounts, or Apple Pay integration on mobile.
#4 Maintain a Running Dialogue Concerning Feature Requirements
Active communication throughout the project is vital to its success. Don’t be afraid to ask the development team for a mock-up on a feature to make sure everyone’s on the same page. And bring up any questions and concerns as early as you think of them. Spending a few minutes on clarifying feature requirements now will save you hours later. If other internal stakeholders change their minds on requirements, let the team know ASAP so everyone can agree on next steps for the feature.
Example: Let’s go back to the quick donate page. Imagine you need to identify a handful of suggested donation amounts on the form. Without a detailed conversation, one person might be imagining three donation amounts ($50, $100, $200) suggested in a paragraph of text above the form. Another person might be imagining five clickable buttons that fill in the donation amount for the user. And you may have something entirely different in mind. Without hammering out detailed requirements ahead of time, the feature is likely to require extra time and money to adjust later on.
#3 Create and Approve Clear Mockups (but also Be Open to Changes Later)
Mockups are the quickest way to get everyone on the same page visually; they tell you not only what the page will look like, but also how it will function. If you opt for a clickable prototype, you can see where each button on the page will take you. This may require more time, but can be useful as you refine the page. Plus, the sooner you make a change or catch an issue, the cheaper it is to fix. If your developers think of a way to do something similar for much cheaper, be open to having a discussion about it. Be mindful of your schedule, but remember mockups and prototypes are just that—not the final product.
Example: For the quick donate page, imagine you have a series of mockups in front of you. In your mind, you believe the checkout button should take you to an equally quick checkout page; however, the developers may envision the button taking users to the site’s default checkout page. During development, the developer hooks up the quick donate page to the default checkout path rather than a new quick-checkout page. This might seem like a minor detail, but a lack of communication could strike a major blow to your schedule and budget that could have been avoided with a clickable prototype.
#2 Identify Key Stakeholders before the Project Even Starts
Decision makers must be identified early and be held accountable or the project will inevitably see delays when a change is requested or an issue is encountered. Knowing who is responsible for saying yes or no to a change or approving alterations to the design will save the development team time when one of those changes comes up.
Example: Let’s say due to some technical restraints on the website, some of the designs won’t work without a much longer development time. If the design stakeholder isn’t known, the decision to make the design change could bounce around a dozen different people on the client’s end and result in a week of delays while waiting on feedback. By knowing who the design stakeholder is ahead of time, the team can have a quick call with the stakeholder to get a decision on whether they want to change the designs or stick with the original.
#1 Conduct User Acceptance Testing (UAT) Early and Often
This is easily the best way to save time and money on a project. The earlier a bug is caught, the cheaper it is to fix. If users are testing thoroughly throughout the project, they’ll likely find bugs long before the code reaches production—maybe even bugs that would have caused more bugs down the road. Also, having end-users test the features will provide invaluable feedback on what they click, how they expect the site to behave, and what features and changes should be prioritized for future work. Alternatively, having end-users test the app may reveal that they expect features to behave a different way than the client or developers expected. It may also help catch bugs that end-users would have encountered.
Example: Thorough acceptance testing by the client may reveal that certain constituencies, when logged in, aren’t allowed to check out in the quick donate form. Not only that, but the bug causing the issue would have also stopped those same logged in users from checking out altogether–yikes! Without some thorough UAT, the bug in this code would have likely gone to production; but luckily, the bug was caught early and resolved, so no users found the bug and no users were ever prevented from checking out in live. End-users are also notorious for using the back button in the browser, which is often overlooked by developers and clients performing UAT. Having end-users test may reveal that they wanted to go back to change their donation amount, but going back cleared all of their data. No one wants to enter a bunch of data twice.
Whether you’re creating a simple quick donate page or overseeing the redesign of your entire site, never underestimate the value of good communication skills with your development team. Trust your development team, and be open to suggestions when they have ideas. Clearly defining your MVP, and actively collaborating on clickable prototypes will cut down on the amount of work developers need to do, as well as identify bugs or issues before your product goes live. Frequent and thorough usability testing from end-users and stakeholders can also help you identify opportunities that will save you time and money long-term.
Nate Martin came to Adage as a developer after a few years working with Fortune 500 corporations. He has since suggested and implemented a variety of process improvements and cultural initiatives at Adage. He’s always looking for opportunities for him and his team to adapt and evolve. Nate loves to work with clients to find the best solutions and takes pride in delivering sleek new features for our client’s websites. Nate’s background in writing fiction means he is often seen with a pen and pad in hand, always ready for his next idea to strike.
