In case you’ve missed this monumental event, Apple designer Jonathan Ive was knighted last week by the Princess Royal at Buckingham Palace.
Indeed, Apple (with Jonathan Ive’s dominant participation) has revolutionized how consumer electronics products are designed. Starting with its color iMacs, which introduced color as an important buying criteria into the mainstream consumer electronics market, and later (as discussed ad nauseam) with its iPods, iPhone and iPad products, Apple has led the market with respect to how products are designed.
In the non-software world, product design has been acknowledged to be a vital part of product success. Industrial design has become a profession, driving product design in multiple industries. Furniture company IKEA has grown based on offering “highly designed” (and arguably, mediocre quality) furniture. Sodastream, a publicly traded $700m maker of home carbonation products, has started growing after putting focus on product design.
When it comes to software, however, there isn’t even a well-defined role, position, or step in the process that addresses the full spectrum of product design.
In the software development lifecycle, product functionality pretty much follows a standard path:
- A Product Manager (or Product Marketing Manager) interviews customers and prospects and comes up with a list of “requirements”.
- Engineering translates those requirements into tasks (a.k.a., Technical Design), and goes ahead and implements them.
- Quality Assurance verifies that the changes adhere to the requirements and once this is the case, the new functionality is released.
With Agile development, the terminology is radically different (e.g., gone are requirements, here come user stories), but the flow is very similar.
At what point in this flow, if at all, does one design the product? Who is responsible to determine how the functionality should be implemented? Who determines how to develop the software to be best received by customers, and (if an existing product) keep the same “spirit” as the rest of the product?
This responsibility is perhaps the most neglected one within the software community. It is oftentimes shared by Product Managers, Software Designers/Architects and User Experience Designers.
But, as things turn out:
- Product managers typically focus on the high level needs, and (one may argue, sadly) spend less time on the minutiae of how the product actually works.
- Software designers and architects are typically responsible for the actual implementation, with very little impact on product behavior.
- User experience designers are more user-centric, but in most cases have less to do with an application’s data model (i.e., which data is stored within the system, and how does it flow around outside the core human-machine interaction); that last part, however, impacts the design of a software product as much as (if not more than) the human-machine interaction.
An extreme example of the lack of product design is obviously open-source software. The open-source “community” excels at developing technologies, but it does a really poor job when it comes to developing products. (At WebCollage, we use a lot of open source software, none of which is accessed by business users, let alone customers: all of it is deployed as infrastructure.) What’s lacking is, of course, product design.
Until us, software professionals, take product design more seriously, and interweave it into our product development lifecycle, we will continue to see people like (well, Sir) Jonathan Ivy knighted, and next time we visit London will only be to see the Changing of the Guard.