This is part 2 of ?? in a series that goes behind the scenes of the PostcardApp.

In Part 1, I gave an overview of how the PostcardApp came into being, and discussed the goals and underpinnings for the project.

In this entry, I’ll discuss the site’s layout and design process from a design perspective. Along the way, you’ll gain understanding into the questions that I asked myself as I worked on the design. Let’s adjourn to the sketch board, shall we?

As you can see from the mockup, the early design of the site spells out core concepts that look different in the end product, but still capture the purpose of the original sketch. My initial idea had the site looking like a photo album or wire-frame postcard rack, and while they may come back at some point, it was my feeling that emphasizing design-heavy elements without a designer puts the cart a bit before the horse.

Still, it’s easy to tell even from this rough sketch that the postcard is the primary focus for the site. Everything else is really secondary, so keep that sucker front and center. Make it larger than other elements and try not to distract from it. Other interface elements need to get out of the way if at all possible, because remember – screen space is a scarce resource on smaller displays.

Now let’s look at the UI from a later build:

This is the initial view of the site, the very first thing that users see after the page finishes loading. This is important, people. First impressions make a difference – you want to hook your users in with an initial display of shock and awe, then continue the experience with the rest of the application. That’s pretty old hat and shouldn’t be a huge revelation – think of Flash intros or the first scene of a Shakespeare play, and you’ll get the picture. I’ll bold this next sentence to convey the importance of it:

Identify one thing that conveys the essence of your concept, and make it prominent

In the view below, authenticated users are able to select a blank image, fill out, and share the postcard, but notice how it’s an evolution of the previous screen, revealing something new about the application without covering what is already there. Hiding it by default, then making newly enabled or visible functionality additive keeps attention on the postcard while informing users that there are other activities they can engage in with the site.

If there’s one thing readers of this post should get from this experience, it’s the importance of flexibility in designs and in mind. You have to be willing to ditch something that’s just not working, even if you absolutely love it. To that end, keeping logic, data, and presentation separate are key factors in staying flexible. Dogfooding your own API as soon as possible can flush out flaws while it’s cheaper and easier to correct them as well as maintain development focus.

As soon as I finish compiling my notes and making them into a series of coherent thoughts, I’ll be posting the next article in this series – an illustrated comparison of the Postcard App against RESTful principles.