For those who have a passion for creating beautiful, useful things, becoming an interactive designer or developer can feel like a career dream come true. Of course, no path is without its obstacles, and even the most dedicated mobile app geeks have to deal with petty annoyances and the occasional project meltdown.
We asked 11 interactive designers and developers what their biggest pet peeves on the job were. If you’ve ever overburdened your design software or let loose a few expletives while waiting forever for app store approval, you can probably relate to the following gripes:
1. Insufficient quality assurance.
Pushing certain aspects of the testing/ QA process can lead to one of two things: missed deadlines, or buggy app releases. Jenny Fan and David Antunes are Senior UI/UX designers at Applico (@Applico). For them, neither of these situations is favorable.
“There’s nothing worse than putting design bugs on the back burner to functionality until there’s no time left and they don’t get fixed before release.”
2. Unhelpful client feedback.
While it’s important for interactive designers and developers to incorporate client and user feedback into their apps, sometimes it’s easy to forget who the expert is, says Fan and Antunes.
“We’ve all dealt with clients who don’t understand the purpose of wireframes, and instead offer feedback in terms of color and size.”
Josh Gaume, Senior UX Designer at Raster, also knows the pain of less-than-useful client feedback.
“One of my biggest pet peeves is when the clients say ‘I’m not a designer, but…’ and then proceed to make design changes. Another peeve is when we’re on a design call and everything seems to goes perfectly, and the client is loving the design — and then the next day the client does a complete 180 and changes everything.”
3. Non-designers and non-developers making inaccurate design and development estimates.
One of the major management issues that can come up in the process of designing and developing an app comes up when people on the team make estimates for the interactive designers and developers, and get those numbers dead wrong. Fan and Antunes have seen their fair share of this scenario.
“Non-designers making design estimates that under or overestimate the cost and bandwidth incurred in the design and development process become a huge annoyance. It’s important to consult with your interactive designers and developers before making any estimates.”
4. Sometimes Adobe just can’t handle it.
The Adobe Suite may be an interactive designer’s friend, and there’s no doubt that it’s powerful in terms of features and functionality, but anyone who has had to use it professionally has had the experience of maxing its resource capacity. As Fan and Antunes know too well, all it takes is a single Photoshop crash to wipe out important progress and send you fuming to the break room.
“One of the most annoying aspects of an interactive designer’s day is dealing with programs crashing when the combined file becomes too large (for example, Sketch and Illustrator).”
Remember, interactive designers: save early and often.
5. When interactive designers focus too much on aesthetics, and not on usability.
Konstantin Sokhan is a UI Designer at MetaLab (@metalab), the visual design team behind the enormously successful corporate chat client, Slack (@SlackHQ). One thing interactive designers do that annoys Sokhan is forget that form really does follow function.
“It’s a broad stroke, but I hate it when designers focus too much on the aesthetics, and not enough on the person who actually uses their design. Good design is a very conscious, deliberate act, which should have something clear to say to everyone. Often you see decorative designs or fancy animations that are pleasing to those ‘in the know,’ but frustrating or just confusing to everyone else. To see designs with such an obviously narrow purpose shows a huge lack of care.”
6. Clients sometimes don’t understand the need for maintenance.
Trevor Ewen is a Computer Scientist & Software Engineer at Neosavvy (@neosavvy), as well as the brains behind Pear of the Week (@pearoftheweek). Ewen has encountered quite a few clients who seem surprised that an app requires updates, maintenance and fixes.
“My biggest pet peeve is having to explain the reality of maintenance and the fact that it costs money. Many customers don’t understand that production quality software requires maintenance, and the dependencies will go through changes. Doing this work will inevitably cost money. People don’t expect their homes to magically fix themselves, but apps are somehow supposed to do that.”
7. Apple’s byzantine app review process.
Nick Bonatsakis is a founder and developer for Atlantia Software (@atlantiasoft), a firm whose developers and interactive designers create web and iOS apps like SimpleMic (@SimpleMicApp). A full-time software developer for 10 years, seven of which have been focused on developing apps for mobile devices, namely iOS, Bonatsakis knows his way around Apple’s app review process — and has a few bones to pick.
“By far one of the most frustrating aspects of developing for the Apple platform and surprisingly, not even a technical sticking point. Every app submitted to Apple must adhere to its strict guidelines over what an app should or should not do. Often times these guidelines are ambiguous at best, and downright made up on the spot at worst.
A developer or interactive designer might spend months creating an innovative app only to find that it violates some as yet heard of Apple restriction. Having submitted hundreds of apps and app updates, I’ve seemingly hit every rejection in the book, but it still stings a bit to get that dreaded ‘App Rejected’ e-mail.”
Steve P. Young, Founder of AppMasters.co (@AppMastersCo), can relate. For Young, Apple’s review process often presents a serious time bottleneck.
“Apple is taking longer and longer to review apps and get them live in the App Store. This makes it very difficult as developers to update changes and test different workflows. Using a tool like Proto.io allows you to test your assumptions with real users before finally deciding to submit to the App Store.”
8. Constantly changing development environments.
Even before they get to Apple’s app review process, however, interactive designers run into a mess of frustration. Why? Apple’s development environment, Xcode, is constantly updating — and sometimes those updates feel like they do more harm than good, says Bonatsakis.
“Apple’s development environment for iOS and OS X, Xcode is a constant source of pain for developers. With a continually evolving UI that often berries important functions with every update (seemingly at random), to its lack of features that are considered mainstay on other development platforms (quality code refactoring, automatic code formatting, sane file management), to the fact that it just plain crashes an awful lot, Xcode is in many ways a poor excuse for a flagship code and UI editor.”
9. iOS app provisioning can be a nightmare.
Bonatsakis’ final gripe with iOS development is with the nitty gritty details involved in app provisioning. For interactive designers and developers, this is one of the biggest migraine inducers in the entire UI design process.
“Ask any iOS developer about the most annoying parts of creating software for iOS, and I guarantee you will hear something about app provisioning. This includes securely signing an app bundle, defining identification and capabilities (such as which services the app has access to: iCloud, Health Kit, Push Notifications, etc) and determining which devices are allowed to run development builds.
This complex process gets more burdensome with every iOS release, as more and more features arrive. The recent introduction of App Extensions and WatchKit (Apple Watch) have added more salt to this already raw wound, as each distinct ‘extension’ requires its own provisioning identity in addition to that of the containing app.”
10. Bad documentation.
Interactive designers and developers rely heavily on documentation every time they make a change to an app, or when they encounter an issue in their dev environment. For John Holtkamp, Founder/CEO of Aperture Interactive LLC, developer of FaithLink (@FaithLinkApps), poor documentation is one of the biggest thorns in his side.
“I’ve developed apps for iOS and Android since 2010, and the worst thing in the world is when I run into terrible documentation. Nothing is worse than banging your head against a wall for three hours because someone didn’t document their SDK or API well.”
11. Dealing with closed systems.
Brian Crane is the Founder of CallerSmart (@CallerSmart), an iPhone app that helps you identify mystery callers and block those you don’t want to hear from ever again. One of the most annoying aspects of his job is his inability to access the iPhone’s native phone functionality.
“With Facebook’s recent launch for Hello on Android, Apple needs to consider allowing developers to access the iPhone’s native phone feature. Hello’s live caller ID and call blocking are features that users want, but very difficult to implement in iOS. With Facebook’s Hello launch, I believe it’s time for Apple to give interactive designers and developers access.”
12. Configuring apps for multiple screen sizes.
No matter how much work an interactive designer or developer puts into responsive design and quality assurance on multiple devices, dealing with disparate screen sizes can still be a huge pain. Derek Clark is the Founder of 30 South, developer of Vima, and dealing with screen discrepancies is one of his biggest development peeves.
“My biggest issue right now is designing and developing for iPhone 4s and iPhone 6+. The size difference is huge, and with the different aspect ratio it’s just a pain to try and support both well at the same time.”
13. Users demanding obligatory cross-platform work.
Brett Neely is the Founder and Hacker at Bits Evolving (@BitsEvolving), developer of iOS apps like Colo, as well as a former engineer at Apple. For Neely, whose passion and focus is on iOS development, the idea that everything must be cross-platform is a big pet peeve.
“My first smartphone was an original iPhone, which I obtained on the second day of availability in 2007. I tell people that I develop software for iOS. If someone asks when my app will be available for Android, I tell them that it won’t. This is the direction I’ve chosen for my career. I care deeply about iOS — I still have plenty to learn and accomplish, and want to devote all of my efforts to it.
Other developers may develop for multiple mobile platforms, and that’s fine, but that’s not what I’m doing. It’s the same as if I bought a house in California and someone asked when I was going to buy a house in Brazil: I’d tell them that I live in the United States. (I’d be thrilled to visit Brazil one day, though!)”
14. Interactive designers and developers using inaccurate terminology.
Another of Neely’s peeves is confusing, incorrect terminology being thrown around by interactive designers, developers and users. Using old conventions like “clicking” for touchscreens is a particular sticking point.
“There’s a terrible convention in desktop and web environments where users are asked to click on buttons or links. I have never agreed with this wording. A click is not a user action, it is the response that a mouse or trackpad makes when one of its buttons is pressed. The user action is that an on-screen control is being pressed. Users should be instructed to press buttons, not click them. When you use an elevator, you press the up, down, or floor number button. You don’t click them. Now, mobile apps are asking users to click on buttons. There isn’t a mouse in a touch screen interface! Developers and user interface designers should know better.”
Smooth Out Your Design and Development Pet Peeves with Proto.io
With so many things that can go wrong in the mobile app design process, there’s no reason that prototyping should give you any extra headaches. With Proto.io, interactive designers can easily create lifelike prototypes of their most innovative mobile UI designs using a simple drag-and-drop interface. Your clients and potential users can enjoy a near-identical replica of the app experience without dropping any developer bandwidth on coding a beta.
