Software development is tricky. We love it, but we know it can be a challenge.

As we’ve progressed as a company, we’ve learned many lessons and developed tools to address the challenges of creating software for our clients.

Of all the things we’ve sought to address and improve over the years, we’ve found that addressing information loss and project communication leads to the most successful projects. Issues of information loss are nearly universal. Every project contains thousands of pieces of information. To prevent information loss and to improve project communication, we’ve developed a process—called Interface-Driven Development or IDD—that provides a better framework for scoping, capturing information, and project communication.

Why “Interface-Driven”?

We call our process Interface-Driven Development because all of the tools in our tool belt are organized around the idea of the interface. An interface refers to the front-end interfaces you see on your screen, as well as the back-end interfaces—APIs, Admin Tools, etc.—that are used to create an application.

Interface-Driven Development includes a system for cataloging all of the interfaces in an application. This system gives everything in the project a name, a key factor in determining a project’s success. When everything has a name, and only one name, the project team starts to communicate better because they have developed a shared language. When we have a shared language, we don’t run into issues like someone in IT saying “Nav” and someone in Marketing saying “Tabs” to refer to the same concept.

Creating names for every interface and developing a shared language is just part of IDD. There are really three key tools that make it a success: The Package Index, Information Architecture, and UXD.

Three Key Tools

Interface-Driven Development makes use of a number of different tools, but the three key tools for documentation are the package index, information architecture, and UXD.

The Package Index

The Package Index is a foundational tool used to organize the functional scope of a project. The package index breaks down an application into its meaningful functional components—called packages.

For example, if you have an ecommerce application, then you would likely have a package called “Browse.” The Browse package would include all of the components and interfaces needed to create the experience of browsing products. We create packages for all functional parts of an application. Sticking with our ecommerce example, you would also expect a package for “Cart,” one for “Account,” and so on.

Creating the Package Index is an extremely important step in our process. As we’ll see later, this is the core of how we scope and organize projects.

 

Information Architecture

The information architecture (IA) covers the non-functional scope of an application. Think pages of a website or screens of a mobile application. This document, combined with the Package Index, helps us capture the full scope of an application.

The combination of Package Index and Information Architecture gives the team a complete picture of the work that must be done to complete a project. It also provides a name for every part of an application, which creates the framework for a shared language.

The Package Index and IA also work well as a check against each other. If we have pages in the IA that aren’t accounted for by interfaces in the Package Index, then we need to address the discrepancy.

But we don’t stop there. The next tool—the UXD—adds an important layer on top of our framework to ensure clarity and meaningful collaboration.

UXD

The UXD (User Experience Design) is Dynamit’s tool for showing all of the interfaces of an application paired with functional annotations. We use high-fidelity wireframes so there’s no guess work around what an interface will look like in the real world. We pair our wireframes with detailed annotations covering functional and non-functional requirements.

 

This tool is key in allowing everyone to make meaningful project contributions. For those who want to get into detailed requirements, they are available. For team members who are more aligned to visuals, they can make meaningful contributions and have the assurance that the designs they are reacting to are the same designs that will be implemented.

Why this System works

Tools alone aren’t enough to make a great project. They help, but the tools must fit into a bigger set of philosophies that are designed to make projects successful. So what makes IDD successful? Here are three of the overarching themes that play into an IDD-led project:

Detailed from the Beginning

In a time when some companies are running projects with little documentation as a feigned attempt at speed-to-market, we go heavy on detailed documentation, starting from the time a potential project hits our inboxes in the form of an RFP. When detail is missing, assumptions get substituted for knowledge. This is where communication and understanding start to breakdown. We get in front of this by starting with detail. The Package Index is our tool for making sure we capture details from the start, but the key is that we have a system, and that we prioritize being detailed.

Better Methods of Project Organization

The Package Index is useful for more than communication. By organizing projects into major functional pieces, we can organize phases and teams around large parts of a project. We can also split our UXD documentation into multiple smaller-documents organized around packages to make them easier to digest. We’ve found that this works well whether the process we are working with is agile, waterfall, iterative or some combination.

The tools you use and what you call them may be different, the key is having a clear process for organizing projects that is meaningfully aligned to the scope of the project.

Clear Documentation for Meaningful Participation

The UXD works for our clients because we work with both IT and Marketing teams (among others). We encourage participation from different types of stakeholders with different types of needs and learning preferences. Not only is this great for cross-functional teams, it’s also great when dealing with stakeholders that are further removed from a project. By delivering clear documentation, anyone can pick up one of our documents and immediately see where we are and how the project is coming together. The UXD isn’t the only option for this type of clarity, but it is a great tool that allows everyone to join in and communicate in the same language.

Want to Learn More?

There’s much more to IDD and successful projects than we can cover in a quick blog post. We often conduct Interface-Driven Development workshops to help teams enhance their processes with our tools. If you are interested in learning more, send us an email.

A Beginner's Guide to Web Accessiblity

DYNAMIT
DYNAMIT