on: identifying design needs and trends

skeleton design process
skeleton design process

It’s that time of the quarter…

In addition to UI/UX design and the building of designs, I like to analyze our production processes and streamline wherever possible, whenever possible.  It’s my favorite part of the job, honestly, and why shouldn’t it be?  It’s a great feeling to be able to save someone valuable time — especially when that time can be spent learning more about Actionscript, Maya, AE, AI, Photoshop or pushing the envelope of what these babies can do.

One of the main ways I’ve been able to help the Studio Design Team here at Smilebox is the creation of design skeletons which provide a rapid prototype of what a design (in this case, a square scrapbook/photobook) will look like after I have worked my “magic.”  The skeletons contain all of the Smilebox internals (code/XML/components), and none of the technical headaches for the team members who are responsible for prepping and importing the design’s graphic assets (backgrounds, overlays, embellishments and the like) into the Flash .fla file before shipping it off to me for its technical build.

This month, I’ve decided to revisit my square book skeleton and update much of its code after too many occurrences of hearing myself say “I am so tired of updating those three lines of code –” in this case, without which, the square books would not conveniently autoplay for recipient viewers.

First things first – as a part of my normal day-to-day production, I keep a running tally of things that are not working within the skeleton, or things I must continually update to bring the design “up to standard.”  As a start up, things at Smilebox are eternally evolving and growing.  The designs have to keep up with the growth, as well as reflect emerging trends/and a certain level of the technological “wow” factor.  It’s pretty great, in a lot of ways, and gives me the kind of challenge I find I need to keep me pushing my comfort levels in terms of both my coding and design skills.

After I felt I had a pretty substantial list, I knew it was time to make the time.  There is always a sense of “oh, I’ll get to that later, I have too many other things to do right now” when you are in the ebb and flow of constant production work.   You have to learn to get, or be very good at, managing your time and focusing your energy.  When you get to a point that the thing that’s supposed to be saving you time, is taking you time…it’s time to make the time to fix it.  Most of the work was done in my own hours, because it is just that important.

There was a period of just analyzing the skeleton and taking stock of what was no longer necessary, of what needed to be tweaked, what needed to be updated, and what could be further streamlined.  Because the books now offer user’s the option to use any layout on any page (a feature I designed and implemented this spring in the course of a two week design/code crunch in response to consumer requests), the skeleton is robust and often offers many extra features for the producer building the design.  Some of those features are not being used on a regular basis and while nice to have, no longer serve a solid purpose.  Other features needed to be added, such as code to make user customization of text easier – not only for the user, but for the design’s producer as well.

After a peer-review process with one of Smilebox’s best-selling external designers, ajellebean (who brought us “Photomatic” / “Photo Mosaic” / and this season’s delightful “Autumn Postcard Collection”), I felt all of the new pieces were in place.  I can’t speak more highly of a peer code review process – sharing is a good way to brainstorm and ferret out potential snag points before releasing products/widgets/designs like this for general use.

Next steps?  Scheduled skeleton vetting.  It’s fairly informal, and only a requirement because I make it one, and involves a very limited release of the skeleton for use in the creation of one design.  The skeleton is vetted through a successful production and QA cycle.  I will gather data and analyze what worked, what didn’t, and make adjustments before starting the process again.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s