As 2014 was wrapping up and many of us began thinking personally about what would make good resolution fodder for 2015, our team made what will hopefully be one of the most intentional and impactful design decisions for the future of our product. We decided to adopt Material Design. Briefly, Material Design is a design “language” developed by Google as a part of an effort to coalesce fairly disparate designs across all their products into one functional and beautiful framework. So far Google’s Material Design has made its biggest splash on Android, but it has been making inroads in Google’s web apps as well such as with Docs and Inbox. What’s unique about Material Design is that Google has essentially open-sourced it, making the spec publicly available and inviting others to use it. Trello, for example, recently (and successfully) redesigned their Android app using Material Design.
As much as Google likes to refer to Material Design as a “language,” I’ve really taken to thinking about it as a framework. Over the past year and a half we’ve come to love using frameworks. Ember, COMPASS, Entity Framework, ASP.NET Web API, are all frameworks we’ve adopted as if they were our very own. While there are many benefits to using a framwork, for us it’s all about time. Material Design, like all good frameworks, solves the common problems so we don’t have to. Rather than spending precious design resources fretting over whether the app’s sub-nav should be vertical or horizontal, we can go with the Material answer (horizontal) and focus on coming up with elegant solutions for the heart of our app’s interface. Not only does Material Design provide answers to common problems; it provides good answers. Our journey towards Material Design started as a series of experiments--we took interfaces that had been vexing us for months and embarked on a series of experiments to reimagine them using Material Design as our touchstone. In each case, Material lead us to an answer that was better than what we had come up with before--and in considerably less time. At Second Street we’re always pressed for time. We’re working towards an expansive and ambitious vision and as a development team that means we’re always looking for ways to go faster. As software in general has become more usable and delightful, we’ve had to up our design game as well. Producing better results more quickly has been no easy task and while lean, kanban, etc. have shored up many parts of our process design was still one of our sticky wickets--until Material. And while we (Iike Google) only view Material as as guideline rather than sacred text, it has indeed saved us considerable time and allowed us to focus all of our creative brainpower on the parts of our app that are truly central to our users’ experience.
While Material has already paid off for us in terms of design time, we also have hope that it will ultimately lead to increased development time as well. Material is still relatively new to us, but as our designs converge on consistent patterns for lists and navigation and links, it stands to reason that our CSS, HTML, and JS will as well. In fact there have already been Material Design frameworks published for both React and (of course) Angular. I firmly believe it is only a matter of time before we see something similar for Ember as well, which we will be very eager to take advantage of.
Despite the ostensible benefits Material provides, there are serious concerns which are worthy of addressing. Many can be summed up as such: “If you’re just using Google’s UI aren’t you sacrificing your app’s uniqueness and outsource your creativity to a giant corporation?” As gratifying as it would be to respond with a resounding “NO!,” the the truth lies somewhere in the middle. In fact, there is little intrinsic value in a truly unique design. Don’t get me wrong; there is value in unique functionality, which is, of course, what we try to deliver every day. But wrapping that unique functionality in an unfamiliar facade can often detract from the overall user experience. Yes, Material is new, but Google has such an enormous user-base that soon conventions like the FAB will become familiar experiencers for our users and adopting them ourselves will only make our app more usable. What’s more, Material has intrinsic design merit. The convention of a single Floating Action Button forces your designs to be more focused and lists have a very good balance of whitespace and visual weight.
Honestly, we’re still very new to the Material game. We released a couple of projects towards the end of 2014 which were very inspired by Material. But as 2015 picks up steam, we anticipate nearly every project being influenced by it in some way. Its track record of saving design time as well as producing better results along with the possibility of faster coding time make it too tantalizing to ignore. So while it is not design gospel, Material Design certainly is good news for teams looking for new ways to go faster.