Chapter 5: The 5 Ds of Successful  App Building

The role of design thinking in product development

Before diving into the 5Ds, it’s important to understand a foundational design-thinking concept on which they are fashioned: the Double Diamond model.
‍
This system provides a framework to help teams move through the creative process of solving problems.

Source: justinmind.com

As illustrated in the graphic above, design thinking involves tackling a challenge by coming up with as many ideas as possible to solve it—in other words, using divergent thinking to arrive at the best available solution. Once ideas are on the table, convergent thinking narrows all potential ideas to the best one. Employ the concepts of divergent and convergent thinking as you move through each phase in this chapter.

Successful app-building requires five Ds:

Discovery

explore the problem space

Definition

decide which problems to try solving first

Design

specify what we’re going to build and how it will work

Development

create the app

Deployment

give it to the users

Following the 5Ds is an iterative process. But, proceed through them in a sequential manner because the output of each serves as input for the next. Then once you’ve delivered the product, you can go through them again to keep making it better and better.

Discovery

If you don’t understand the problem, you can’t fix it. So, your goal is to figure out what you don’t know to develop a plan of attack.

Though it’s too often skipped or massively truncated, there’s no substitute for the discovery phase because people bring plenty of assumptions to the table that need to be dispelled. You may hear questions like “Should we spend money learning something we already know?” or “Is it really worth it to delay our product launch?”

The short answer is yes. As Erika Hall, author of Just Enough Research, puts it, “If you’ve ever worked with a leader who was resistant to doing qualitative research as part of a million-dollar project, ask yourself whether they would skip doing their own research before buying a $50,000 car.”

For more on the importance of qualitative research, check out Erika’s talk, Design Research Done Right.

Stay curious

Mindset is the most important part of discovery. Your job is to learn, not to know. The only way you can make the best possible product, one that addresses your users’ needs and wants, is by identifying and testing your preconceived assumptions about users.

Be willing to always dig deeper. You’re after the root causes of problems, not just the symptoms. That’s the only way to build a solution with a lasting impact.

To get to the reasons behind the reasons, we recommend using The 5 Whys. Sakichi Toyoda, founder of Toyota Industries, developed this research technique in the 1930s; it’s contributed heavily to the company’s success and others since.

This approach begins by identifying an issue and asking why it happened. The more you understand, the more likely you can build an elegant, feasible, and impactful solution.

Ultimately, staying curious is all about fostering a culture of humility. We’d do well to remember a piece of ancient wisdom, the principle of Socratic ignorance: all we truly know is that we know nothing. This is especially true for knowing what people want, a notoriously complicated subject that’s full of surprises and contradictions.

Quick tips for a successful discovery phase

Talk directly to users—at least three, preferably more!

Do not talk to proxy users.

Consider using a third party to conduct user research.

Use anonymized surveys to get unfiltered feedback.

Conduct user interviews in a one-on-one setting to relieve social pressure.

Definition

During discovery, you begin to narrow your focus, converging on a specific problem. Even if you found many issues, pick the first one to tackle with the first version of your app (you can iterate on the rest later). The definition phase is all about scoping the project in a way that sets you up for success.
‍
Keep this in concrete terms that are specific to the task at hand. In other words, “make users’ lives easier” won’t cut it. Instead, think “reduce the time it takes users to compile sales reports by making the data more easily accessible and simplifying the workflow.”

Quantify success

Taking this one step further, define the metrics that will accurately inform whether or not the app is successful.
‍
These metrics should be clear and objective. “Does my boss like it?” is the wrong way to look at it. Remove opinion from the equation and focus on key performance indicators (KPIs) that affect the bottom line. Some examples include:

Time spent on a task

Time spent learning how to complete a task

Lead response time

Lead-to-opportunity ratio

Average sales cycle length

Lead conversion rate

With metrics in hand, it’s time to start measuring because there’s no way to demonstrate ROI without a basis for comparison.

Create the product brief and user stories

The product brief serves as your guiding light and a single source of truth for the product. It should define virtually everything about it, ranging from what you’re building, who’s involved, and how you’ll test it.
Keep in mind that this isn’t a one-and-done effort. Continually refine the product brief as you go. Refer back to our discussion in Chapter 3 for guidance on creating this document.
‍
In that chapter, we also defined user stories—simply put, how people will use the app to accomplish their goals. User stories are an important component of the product brief and here’s some inspiration to help you get started:
‍
17 User story examples for when the ink runs dry
‍Aha! User story template and examples
‍
Throughout your product brief, include acceptance criteria so everyone is aligned around goals, which will help with adoption. As you exit the definition stage, have a clear, concise picture of where you’re at right now, what you want to accomplish, and how you’ll know if you did it.

Design

We talk about design a lot. It’s what we do. There's so much we want to say about it, but here, we'll focus on the big picture.

Design isn’t just about making apps look pretty. While aesthetic matters, it’s just one element of creating an app that people want to use.

As we discussed in Chapter 4, human-centered design (HCD) sits at the intersection of user desirability, business viability, and technical feasibility. While all three traits are indispensable to creating experiences users love, you must first understand what people desire.

You can have 100% overlap between feasibility and viability and still build apps that nobody uses.

Ken McElrath

Founder & Chief Strategy Officer, Skuid

HCD places the customer at the center of every process. It seeks to understand what the user wants and needs to do their best work. This means having conversations with users and incorporating their feedback into the product. It requires involving the user throughout the entire creative process, both in terms of understanding the problem as well as understanding how the solution will be received, along with any potential unintended consequences the proposed solution may cause.

As a refresher, the four key traits of a well-designed app are utility, efficiency, clarity, and refinement. Accessibility is another important consideration. Some organizations, especially government agencies or those creating public-facing apps, require it.

Simply put, can people of varying abilities use your app easily? For instance, does the app work for people who use screen readers or anyone who can’t use a keyboard or mouse?

Once you’ve taken all these factors into account, the app is a continuation of your overall brand identity. Look at how your company’s style guide handles things like font, button style, and drop shadows. Bring those elements over into your design system to create a more cohesive application that will bring an added layer of familiarity for your users.

Deployment

Much like a chef assembles their ingredients before cooking a dish, product development is more effective and efficient following thorough preparation. Instead of having to go back to do more research, waiting for a design to finalize before moving forward, or, even worse, not having a clear definition of the problem and the path to solving it, preparation lets you focus solely on the development work and create a better product.

Agile vs. lean methodologies

Most people have heard of agile product development. The basic premise is that you should identify your riskiest assumptions and test them as quickly as you can in the cheapest way possible.

At Skuid, we prefer lean product development, an outcomes-based methodology. It’s an application of principles from the Toyota Production System to software development and aims to eliminate waste in the process, among other principles.

Lean development has faster development cycles and a more serial approach than agile. Whereas agile is broken into two-week sprints, our lean sprints tend to be anywhere from a few days to one week, given the speed at which you can build with Skuid.

We retain some aspects of agile development, like being flexible to change, using Kanban boards and other popular agile tools, and breaking our work into chunks while cycling through development phases.

Bear in mind that real agility is about finding out where you are right now, taking a small step forward, adjusting your understanding as you learn, and repeating that process.

It’s also key to get comfortable with experimentation and throwing away work. It’s not just okay to try different approaches to solving the same problem, it’s preferred. Remember, if you’ve explored a multitude of options, you’ll arrive at the best solution.

Building a testing discipline

Testing is an essential part of every development project. It ensures you’re building stable apps that users will adopt.

Automated and manual testing

While developers are used to testing requirements, business analysts and other non-technical admins may not be. So, let’s talk about how to set up a robust testing procedure.

Ideally, you want to build and run automated tests. Using an open-source project like Selenium, you can write automated test scripts that will run through actions in a browser, comparing results to the expected outcome. Whether you use these tests nightly, weekly, or less regularly, it’s important to make testing a priority.

If you don’t have the technical expertise to write automated tests scripts, manual testing is the next best thing and consistency is key. Build a regular testing regimen and review all your pages in a test environment. Make sure that you can complete (without incident) all the actions your stakeholders rely on to do their jobs.

Once you’ve run automated or manual tests and resolved any bugs, user acceptance testing (UAT) is next. This is the buffer between developing the app and releasing it into production.

With UAT, you put the app in front of actual users, ensuring it makes sense to them and that they can use it to get their jobs done. Though this is more about checking that you’ve built the right thing than discovering bugs, it’s perfectly normal to uncover issues here, too.

Accessibility testing

It’s critical that your apps are accessible for people of all abilities. So, be sure to include accessibility audits as part of your testing discipline.

Tools like the Social Security Administration’s Accessibility Testing Tool (ANDI) and Freedom Scientific’s Job Access with Speech (JAWS) are good places to start. Designing an app that’s usable with a screen reader, for instance, is particularly important for organizations that interact with the public sector.

Skuid makes building for accessibility easier by natively supporting aria labels (Accessible Rich Internet Applications). These labels are used by access technologies like screen readers, such as those that come with a computer’s operating system.

Building and testing for accessibility is a prime example of putting humans at the center of design. It ensures that everyone can use your product, and it limits your exposure to liability. We’ll talk about setting up sandboxes for testing in the next section.

Development

You found a problem. You figured out a solution. You designed and developed the application. Now it’s time to give it to the users.
‍
Just like in the previous stages, take your time and do it right. To ensure a smooth launch and get good adoption rates, you need a procedural way to test the app within different environments.

Setting up sandboxes for testing

A sandbox is an isolated computing environment with tightly controlled conditions. It should reflect the production environment to a degree, especially when it comes to the data that’s available and the software dependencies that are present, ranging from the operating system that it’s running on to the libraries that we can pull from.

At a minimum have at least one sandbox, but we recommend three. Each should get progressively closer to the production environment which will help you catch bugs, discover vulnerabilities, and patch what you missed during development. Here are the three types:

Development sandbox. Where developers can test their ideas and build them.
User acceptance testing (UAT) sandbox. Where you begin introducing users to the new app. Testing data should be as accurate as possible. Ask the following questions in UAT: can users navigate the app without experiencing any technical failures? How proficient and clear is the design? Does it help people do their jobs more efficiently? Does the app inspire confidence?
Quality assurance (QA) sandbox. A QA team will do everything it can to break the product so that you can fix it. The QA sandbox addresses purely technical issues and can save you from many headaches down the road.

Running the tests

With sandboxes in place, it’s time to start testing. To do this you’ll need to define the test case, including expected outcomes and edge-case scenarios. Capture what the app is supposed to do and build test cases to make sure it’s doing that.

There are many types of testing—from unit tests to smoke tests to user acceptance testing. Regardless of how in-depth you choose to go, you should use an automated testing solution.

Manual testing requires you to physically go through the app’s workflow, which is both time-consuming and prone to human error. By automating your testing with scripts, however, you can run them at regular intervals, in a fraction of the time, and with more reliable results.

Remember, simply delivering apps faster is not the goal. It’s about delivering better apps faster, and app agility is the way to achieve that. Follow the concepts shared here, and you’ll create apps that people not only love to use but ones that result in a significant business impact.