The New Design-Driven Development Landscape

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!

Categories:

Comments

Good post

Michael, thanks for the opportunity to speak with you today by phone, and this blog post was a good follow-up. As discussed, yes, we need visual tools for mobile and HTML5 development, but the question is how well such programs can match the quality and variety of code approaches taken by human developers. Adobe MUSE is a good current example; the code is produces is OK for prototyping but not for real production. There will always be a need to tweak the code, so the designers who can code as well as design, or at least be able to make minor edits to the code, will be the ones in demand. I'd like to see more discussion around that along with following the evolution of the tools themselves.

Nice Blog !!

Nice Blog !!