Iterating on an app isn’t so different.
Whether you’re planning a major release with a host of new features or a minor update to fix existing ones, approach each iteration with the same care and focus as the original rollout. This often means revisiting the five Ds.
The ability to iterate using Skuid is one of the product’s greatest strengths, so embracing this practice is the fastest way to obtain a return on your investment. By using Skuid to facilitate a process of continuous design, creation, and delivery, you’ll build powerful apps that users adopt today and in the future. This process will also help you keep pace with the business as needs inevitably evolve, and prevent you from needing to build a new solution every three to five years.
The philosophy of iteration
Thinking about iteration in the right way helps you avoid many of the common pitfalls encountered during this stage, and maximize value for your users.
As you did during the discovery phase, start by asking why. Just because you can build something doesn’t mean you should. As you learn to listen to users and stakeholders, don’t simply become a short-order cook serving every request by default. First, understand the why and the problem you’re being asked to solve. Group multiple requests that are related to the same underlying problem together and find the most elegant approach possible, no matter their place in “line.”
Since companies iterate fast with Skuid, builders often get excited and want to oblige every request serially. Instead, take a moment to ask yourself if the request(s) align(s) with the vision for the app and if it will help achieve the outcomes you defined in the discovery process. If not, you risk trying to please everyone, and cramming too much into an app makes for a poor and disjointed user experience.
Put another way, don’t let success be your downfall. Just because you can quickly add a new column to a table doesn’t mean you should. Even if it seems like a minor addition, remember, there are no small changes when delivering a quality app, and nothing comes for free.
Ultimately, iterating well comes down to making conscious and intentional decisions.
To add or not to add
As for some concrete guidelines, here are four questions you should ask before adding any new feature to any app:
Does this fit the vision?
Will it still matter in a year?
What group(s) will benefit from it?
Will it improve, complement, or innovate on the existing workflow?
The first question comes back to intentionality.
Question two asks about the staying-power of a feature because it’s an easy way to think about whether the effort will be worthwhile in the long run.
The third question is another useful way to sort by priority. Though the squeaky wheel often gets the grease, beware of developing for a single user’s needs. That’s why it’s so important to survey multiple representative users.
The final question reminds you of why you’re iterating in the first place. You’re not spinning up a brand new app. The iteration must enhance what’s already there and must be weighed against your objectives for the app. Too much change too quickly can disrupt users and lead to frustration and distrust. This is where having a product brief with clearly defined goals and outcomes will serve as your guide.
Iteration is a double-edged sword. Giving users what they ask for quickly can be delightful, but too much change too often and too fast can be disruptive to the efficiency gains and frustrating to users. Assess your organization for the cadence that strikes the right balance.
Curate user feedback
Following the tenets of human-centered design (HCD), get user input to drive your efforts. Conduct retrospective interviews. Survey people and curate their feedback.
Rather than yes-no questions, ask open-ended ones. For instance, Would you like to export this to a spreadsheet? or Would you like to attach notes to your meeting invites? aren’t the best ways to frame your inquiries. Instead, ask a question that allows users to express a need without being prompted. Otherwise, it’s too easy to say yes, and everybody always wants more (or thinks they do).
A better question would be, “If you were able to export this to a spreadsheet, what would it allow you to accomplish?” Based on the answer, you can assess whether it’s worth it to build that feature. Just as before, these questions should aim at understanding the why behind the why.
Once you have a list of questions to ask, review this checklist to ensure they fit these criteria.
While it makes sense to ask open-ended questions during this phase, it’s also appropriate to conduct some qualitative and quantitative research. A good way to get qualitative data is to ask users to rank their answers in a range from “strongly disagree” to “strongly agree.” Sample questions: “Is this product faster to use than the previous process?” or “Is this page easy to use?”
Quantitative measurements are more time-consuming to obtain (and, therefore, more expensive) than asking someone to complete a survey, but are equally, if not more important.
To start with, you might ask users to share their screens and time them while completing different tasks to see how long it takes. Following along like this also shows you where they get stuck or frustrated and highlights points of friction. This feedback will inform the design process so that each iteration delivers tangible results.
Here are some resources that might help inform your user research:
Technical considerations while iterating
As a Skuid builder, plan to stay on top of product releases and make those updates as they’re available.
You’ll want to first do that in a sandbox environment to ensure nothing goes wrong, as discussed in Chapter 5. Consider that, once you deploy to production, you’ll get some easy wins for each new piece of functionality. And since Skuid is declarative, you’ll get all new features automatically, provided you install each release.
Conversely, falling behind on updates introduces news risks to your products. For instance, if you aren’t using the latest version of a platform and Skuid makes a change in response to an update from that platform, you won’t get that fix. Staying current reduces bugs and vulnerabilities down the road.
Last but not least, keep in mind that Skuid is optimized for iteration. We built this product so our customers could make small changes fast. Where coding is expensive and time-consuming, the iterative development you can achieve with Skuid makes the risk of failing much smaller and less costly. It lets you learn from your mistakes, make improvements based on user feedback, and create better custom applications.