The Evolution of the Conversation

The conversation page is where everything comes together.  Co simplifies communication by bringing all your personal messages together in one place; and since that place is the conversation page, it really has to deliver on simplicity.  That said, there's also a fair amount of information (sent messages vs received messages, original manner in which the messages were sent aka platform, timestamp, etc) that needs to be communicated, so the challenge has been to find the balance between clarity and simplicity.

The first version of the conversation view was very simple and really did nothing more than get the raw messages on the page.

What worked:

• There are messages on the page

What didn't:

• The only thing that differentiates between sent and received messages is a tiny arrow
• There's no differentiation between platforms
• The messages are very small and the page is overwhelming

The next version of the conversation page started to add some clarity.  The first order of business was to
clarify the platform where the messages originated.

What worked:

• There are messages
• The platforms are clearly differentiated

What didn't:

• The difference between sent and received messages still isn't clear

The next version focuses on differentiating between sent and received messages. Previously the messages were all the same physical size on the page, and, while there was color differentiation between the platforms, there was no color differentiation between sent and received. This next pass physically moves the messages either left or right, limits them from taking up the entire width of the page, and differentiates the color.

What worked:

• The platforms are clearly differentiated
• It is now easy to determine if a message is sent or received

What didn't:

• The messages are still a little small and hard to read

The Evolution of the Message List

Originally when I started designing, the prevailing design aesthetic for iPhone was skeuomorphic design, or designing elements to reference their offline counterpart.  For example, a gaming app could have an element that resembles astroturf, a note-taking app might be made to look like a physical notepad, etc.  Since I started designing before the release of iOS7, my first design mock-ups adhered to this philosophy.

The first pass of the message list was pretty straightforward.  The messages are listed in chronological order with very little fanfare.  I attempted to incorporate a skeuomorphic element by grouping the messages into "folders" by date.

What worked:

• The names and message are differentiated, clear, and read-able
• There is an attempt to break the information into more digestible categories 

What didn't:

• There are too many messages shown on the page, resulting in a cluttered appearance
• While the categorization is clear, the categories themselves are unnecessary

My next pass took the skeuomorphism one step farther.  Each message now has the texture and color of paper, to represent a physical letter.

What worked:

• The main element of this page is now skeuomorphic

What didn't:

• There are still too many messages shown on the page
• The date folders are still unnecessary

The next design pass addressed the congestion on the page.  I made the name and the message more visually distinct, and increased the spacing so that fewer messages were visible on the screen.  I also removed the date "folders", making the page more streamlined.  The final step was to modernize the profile images by making them round instead of square.

What worked:

• The message list is a million times more readable
• There are no unnecessary breaks or "folders"

What didn't:

• The gray border that enhanced the design takes up valuable screen real estate.
• The messages are still a little too congested.

The Evolution of Design from a Non-designer: Getting Started

When I set out to build my own app, Co, I knew I had quite the task in front of me.  I decided I wanted to oversee every aspect of the app development, from the design to the code to the deployment.  I've spent most of my career building products with incredibly talented teams, and so the idea of taking over every aspect of product development was…daunting.  I'm a software engineer, so that part didn't make me nervous, but I am not, and have never been, a designer.

Let me back this up a little bit - it's not that I haven't tried my hand at design.  In college, I took a few art classes (photography and digital media).  Technically these classes had a drawing prerequisite, but I asked (and received) permission to waive it.  I know drawing isn't my forte, and I didn't want to waste everyone's time by spending a semester on it.  At some point in one of my other classes, we had to do a brief (mercifully ungraded) sketching exercise.  The professor came up behind me, looked at my page and said "wow, it's a good thing I let you off the hook for that drawing requirement, you really can't draw".

So maybe I can't draw, but when you're working with a team, you're able to rely on the talent of the people around you.  When you're running the show, however, "can't" is no longer a viable excuse.  When I need something done regarding the app, either I have to figure out how to do it, or it doesn't happen.  Since design is one of the things I needed done, I had to figure out how to do it.

So, where to begin?

Like much of the world, I'm pretty quick to point out design I don't like.  While that's a start, the "I'll know it when I see it" approach doesn't work when you're the one responsible for coming up with the design.  Instead of focusing just on what I don't like, I started to cultivate designs that I do like.  I went in search of apps, websites, art pieces, coffee tables, etc that I did like, and figure out what I liked about them.  Were they functional?  Fun?  Clean?  Unexpected?  Beautiful? Could I learn anything from this design?  Could I incorporate something I learned into my app?

Instead of focusing on my weaknesses, I set out to find my strengths.  Part of product design is making something beautiful, but another important part is to make a product that is easy to use.  This ease-of-use is where I have focused a lot of my energy - every detail of every screen is under a great deal of scrutiny.  What is the primary goal of this screen?  Does this button/color/piece of text aid in that goal?

The conclusion that I've come to is that that one of that most important parts of design and functionality isn't what you add, it's what you take away.  The evolution of Co has been a clear example of this - my early prototypes had a LOT going on, both in functionality and design.  As the product has evolved, each iteration has been an exercise what to remove, rather than what to add.  Forcing myself to keep every aspect of Co as simple as possible has kept the design, etc within my abilities, and ultimately it will result in a streamlined product that is easy to use and a pleasure to look at.