BSA Brand Identity

Telling the Scouting Story


Interface Design

Think of your standard pocketknife.It’s got its primary tool – a blade – and a whole lot of accessories (leather awl, saw, can opener, etc.). But at the end of the day, it’s a tool. Its functions aren’t improved with a lot of embellishments or decorations.

So too with a mobile app. Good apps are but one tool out of many on a user’s device. Intuitive design and simple, singular functionality are best, especially when the app’s use is occasional or infrequent.
Keep your interface design as close as possible to design conventions the user will already be familiar with by nature of using other apps that follow the same conventions (which are typically established by the device’s manufacturer).
Use BSA-approved typefaces and imagery, and the appropriate color palette, to visually differentiate your project.


Using Icons in Apps

As stated earlier in this document, you should generally avoid creating original icons in mobile apps, since there is a high degree of likelihood that your “original” icon may conflict with one of the hundreds of official BSA icons in use in merit badges, rank badges, etc.

Instead, try to leverage icons already created for app developers by software manufacturers, rather than sourcing your own. Both Google’s Android and Apple’s iOS Developer toolkits include common icons in their developer resources. Here are the icons provided by Apple for use in iOS apps:


Mobile Best Practices


Survey your prospective users about their device ownership before deciding on the development framework you will choose.

Follow BSA standards for color, imagery, and typography to differentiate the design of your app.

Leverage design work that’s already been done by the device manufacturer – follow the design guidelines closely.

Leverage development work that’s already been done by the device manufacturer – use existing toolkits for mapping, interface, and other common tasks, rather than developing your own versions.

Check in with app users after launch to examine new feature requests or ideas for improvement.


Develop apps on a whim. A good app can take months of effort to build, and years to support.

Forget to plan your adoption strategy in the excitement of design and development. How will you promote your new app and train users to install and use it?

Recreate the wheel in development. Many off-the-shelf components and controls come pre-built with existing frameworks, and there’s no need to recreate them.

Forget to test your app on many devices in different operating conditions. Not every user will have the latest hardware or fastest Internet connection.

Leave abandoned apps in public app stores. If development and support have ceased, make it very clear that it’s provided as-is. If the app is no longer functional, take it down.

Real-World Example

This prototype Camp Registration app is built with native iOS UI elements, using color and type to brand it as a BSA app. Users of the app will have a head start in using it, since much of the interface will already be familiar to them.


The major providers of mobile operating systems provide app developers with detailed guidance on how to meet their human-machine-interaction (HMI) and experience standards. Before beginning work on your app.

In the case of Apple, failing to follow iOS design guidelines could cause your app to be rejected during the App Store submission process.

What about Hybrid Apps?

Some applications are developed using cross-platform development frameworks that allow the same code to be deployed to many kinds of devices. These are often referred to as “Hybrid” or “HTML5” apps. If you choose this development route, you should rely more heavily on the web design guidelines presented earlier in this document, and avoid leveraging the look and feel of any one particular operating system.