Design

Saving Money by Paying for Design

Allen Pike • Mar 21st, 2018

When we founded Steamclock, our primary focus was development. While we did do design work when needed, our clients’ teams typically led the design effort while we focused on the software engineering side of things. Since our clients often have in-house design talent, this seemed like a reasonable way to manage costs.

Over time though, we noticed a concerning trend. Projects where a client wanted to save money by doing app design in-house turned out to be more likely to go over budget. On the flip side, projects where we also took on app design were more often on or under budget. What was going on?

Perhaps unsurprisingly, we’d learned a lot in our years of designing and developing mobile apps. Just as designers with a deep background of building web apps get better at designing web apps, designers with a lot of experience in mobile excel at designing mobile apps. This experience makes mobile designers adept at avoiding common pitfalls or complexities on these platforms.

With these lessons learned, we can often eliminate problems at the design stage before they become costly. Usability issues, “scope bombs”, failure to make use of “free” platform features, unnecessarily expensive UI customizations, and insufficient user testing are just a few problems that can be remedied at the design stage by a team that knows mobile development well.

In the same way that a designer can create a week of developer work in an hour of design time, a designer can instead save a week of developer work in just a few minutes by asking the right question, proposing a more elegant solution, or making use of a hard-won lesson from a previous app we’ve shipped and iterated.

Having learned those lessons, I wanted to share some design elements that we’ve learned to recognize as signals – flags that a proposed app design could save a substantial amount of budget from a mobile-centric design and refinement pass.

1. Non-native UI conventions

Native iOS and Android component libraries provide a lot of navigation functionality for free, and adhere to the platform conventions users already understand. If a design uses dropdowns, radio buttons, “hamburger” menus, or other UI elements that are common on the web but not ideal for mobile apps, that’s often a sign the design needs a mobile-centric revision. Even sizing can be a big clue here: when we see designs that have drawn system controls to be slightly different than their standard sizing, there’s often an opportunity to save a lot of development time with a design pass focused on making better use of the platform.

2. Flowing text

Web and print designers are used to a text layout engine that makes it easy for text to flow around images, buttons, and other page elements. While this is possible in native apps, it’s often a lot more work than in web apps, and is a common signal that an app was designed with a web or print mentality.

3. Novel navigation

Some apps, such as Snapchat, distinguish themselves with a novel navigation scheme. Most often, however, it’s best to leverage users’ familiarity with native tab bars and drilldowns. Luckily, there are a lot of engaging ways for an app to distinguish itself visually from the competition without incurring great usability and discoverability costs.

4. Offline sync

Having built apps for eight years, we’ve seen almost every kind of requirement you can imagine. By a significant margin though, offline sync capability is the most frequent feature we see proposed for 1.0 that is best deferred to later. This is sometimes truly needed – for example, an app that is primarily used in the wilderness – but it comes at a substantial cost when you consider the additional development and design work to handle conflict resolution, error handling, sync status reporting, and all the other details that come out of a bullet point as simple as “offline mode”.

5. Welcome tours

A common issue we see in designs proposed by teams that are new to mobile is attempting to mitigate overly complex or unclear functionality by offering a “tour” on first launch. While it may seem like less work to throw up a tour before folks start using your app, text-filled screens are typically glossed over or not retained. Given that, tours don’t tend to fix most usability problems, and the work required to make sure every interaction is clear and understandable will still be necessary.

Shipping better apps

All that said, no matter how new your team is to designing mobile apps, you surely have a huge amount of insight and product knowledge to offer the process. Designing a new app is all about collaboration, especially for teams with a background in print or web work. If your app design work is hitting any of these issues, we’d be happy to help bring them to the next level!

Allen Pike • CEO