How did we get from single-channel desktop apps…

In the not-too-distant past web-centric software development had a standard workflow between designers and developers.  This was possible because there was a single delivery channel (the web browser) and well-established development constructs. Design patterns like Model-View-Controller had well known coding counterparts such as Java Server Pages, the JSP Standard Template Library or Struts.  But now, the introduction of mobile computing has significantly altered this design-development workflow.  The key disruptor is the need to target multiple mobile devices with a common set(s) of source code. Regardless of whether devs use a single HTML5/CSS3/JS implementation or native implementations on iOS and Android, there’s a greater burden on designer than in the web-centric past.  What’s worse, the success or failure of mobile apps is more dependent on the complete user experience than ever before.  This new reality requires a major shift within development organizations.

…to multi-channel mobile apps?

In response to this new reality, we’ve seen some enterprise development shops quickly react by hiring top-tier designers to work directly with their existing developers.  These shops employ new patterns around Responsive Web Designand they’ve shifted to progressive enhancementinstead of feature-degradation. New products have emerged for solution-based software for delivering apps to the various channels (see here, for one). These developments have advanced the state of the art in mobile development, but there’s a key piece that is still missing: new/updated design tools that allow designers to move in sync with mobile developers.

An untapped market: Design-driven development tools!

The tools that are now standard issue in the Swiss army knife of mobile developers include Eclipse and the Android SDK, Xcode and the iOS SDK, and Firebugand assorted Firebug plugins for web development.  Professional designers, on the other hand, still use tools like Adobe Photoshop, Adobe Fireworks and Firebug.  You’ll notice that the overlap between these lists is minimal (and common use of Firebug doesn’t address more challenging lifecycle management issues).  With this in mind, the typical workflow between designer and developer isn’t much different than it was in the single-channel days: designers create mockups of the UI, experience flows from screen to screen that reference the mockups, and design creates binary assets used by developers to render screens.  The output of these steps are thrown over the wall to development along with a tin can attached to a string with the hopes that the developers on the other end can put it all together into the vision the designer had for the app.  This workflow model does not scale with the rapid development timelines and high quality expectations for today’s mobile apps.  The door is wide open for vendors to step up and provide tools that enable designers to collaborate with developers around these mockups/wireframes/assets. Developers should be able to refine these assets with real business logic and rapidly create a mobile application.  Existing vendors that already have buy-in from the design community (e.g. Adobe and Balsamiq) have a leg up here, but that doesn’t preclude an unknown from entering the market to address this problem.  I’ll be keeping a keen eye on this space in the coming months to see who can provide a solution to a problem that is already a sore spot and getting worse!  Does your enterprise already have a manageable solution to this design-development workflow issue?  If so, or if you have thoughts on a potential winner here, drop me a line!