General Assembly – Product Management Day 02

@brentlarue on Nov 14, 2014


Alright folks, welcome back for week two of San Francisco’s General Assembly Product Management course. Last week we all came up with product ideas that we would develop throughout the course. We had ideas all over the map from a children’s toy discovery app to a panic attack prevention product. For my product, I will be re-visiting an idea that was put on the back-burner while working with my pals over at Mediately (formerly Modra Jagoda). The product, Jog of War, got its roots from Health 2.0′s Berlin Code-a-thon back in 2012, where it took first place and made it to the grand stage to be presented by our very own Jure Triglav. I’ll get into the details of the product on another write-up, but for now I want to focus our attention on the course. This week was all about Users and Customers (yes, there is a difference)!

“We are not smarter than the collective intelligence of our customers.”

Part 1: Customer Development

The objective of this class was to identify our target users, learn how to conduct successful user interviews, and understand the user’s needs, behaviors, and current ways of working. We kicked off class with a short clip from Steve Blank, a Silicon Valley serial-entrepreneur and academic recognized for developing the Customer Development methodology, which launched the Lean Startup movement.

What Steve is trying to teach us is that before pursuing any wild ideas, we need to test our hypothesis and assumptions with potential customers. The aspect of this which resonates in my mind is “get out of the building.” Part of our homework assignment was to do exactly this. First we had to identify our target customer. Once we felt we had a grasp on this, we had to identify where we could locate these individuals. And finally, we had to actually go out and talk to them. This is the part that can be the most uncomfortable, but also the most rewarding. It isn’t until you actually go and talk to potential customer’s do you begin to remove yourself from the picture and understand the actual problems people are having. After all, a solution to a problem which doesn’t exist, isn’t really a solution at all.

Stay tuned for another post where I share my findings. This was an awesome exercise which fundamentally changed they way I would approach my product moving forward.

During the class, we had a visitor and former GA student Chris Dyball Noble, Head of Product at Blinq, share his first-hand experiences with interviewing and walk us through a mock interview. Through the interview, Chris talked us through a few key lessons:

  • Make sure you are not introducing sample bias or a self-serving bias by selecting too narrow a customer profile.
  • Let the interviewee know that you are building the product in question so they take you seriously.
  • Let them know up front how long it will take and offer some incentive if possible (Amazon gift cards work great).
  • Some things you can’t solve, but being empathetic helps build trust and a conducive interview environment.
  • During early stage interviews, broad, open-ended questions can help you learn the fastest.

Part 2: Personas & Empathy Maps

The latter portion of class was focused on what happens after the interviews — translating your interviews into personas, creating empathy maps, and learning how and when to apply these tools.

A persona is an archetype of a group of users. It does not represent one person. It is created by identifying trends in user research. While these are fictitious people, they are still rooted in reality. Personas help UX designers, marketers, product teams, and executives think and make decisions like their potential users, not themselves. It is not always the case that you will be your own target user. Within a persona, you should capture goals, needs, behaviors, pain points, scenarios, biographical info (name, age, gender, location, income, etc.), and maybe even personality traits. Finding a picture to go along with the persona can help make it more memorable and real. We also learned how to create and use empathy maps, though truthfully, it does not sound like these are used as frequently in everyday life.

To wrap up class, guest speaker Cheryl Yeoh, CEO of Malaysian Global Innovation & Creativity Center and formerly Walmart Labs via Reclip.It, talked to us about her product experience. Cheryl walked us through some of her early mistakes including working too long on ideas without first validating them with customers. It was refreshing to hear her talk about her “stupid idea” and the struggles that she and most founders grapple with. Eventually, Cheryl and her team would turn around the company and later be acquired by Walmart Labs — well done! Identifying and collaborating with Mommy bloggers (after discovering some traction through analytics) was a big part of growing the product. Another really interesting event which took place was bringing in two users, one old and one new, every Friday to test the product. Overall, she really helped us understand that this was not academic bullshit, but this was the real deal.

Another great class under the belt! Until next time, over and out.

General Assembly – Product Management Day 01

@brentlarue on Nov 5, 2014


Last Saturday was the first class in General Assembly’s San Francisco Product Management 10-week business course. The course covers all areas of product management from user research to financial modeling. Over the course of 10 weeks, we the students will work to launch real products. By combining theoretical knowledge with practical, hands-on learning, this course will take us through the rigors of creating and managing products.

“General Assembly is a global community of individuals empowered to pursue the work they love.”

Our fearless instructor George Favvas, CEO of San Francisco’s PerkHub and his trusty side-kick Pat Pow-anpongkul, Product Manager at Trulia, will lead us on our journey. Our class is full of students from all walks of life — new grads, venture capitalists, entrepreneurs, project managers, and engineers. Each one of us has our own motive from formal product management training, changing career paths, taking on management responsibilities on current teams, to getting a startup off the ground. It’s going to be an exciting 10 weeks and I’m looking forward to learn how to create and manage great products together with an ambitious group of classmates!

Part 1: Introduction to Product Management

In this session we learned what are the multiple roles and responsibilities of a Product Manager. The highlight of the lesson was the paired exercise where we took a fictitious app and identified needs, features, and benefits for various user groups. This exercise started laying the ground work for future lessons and beginning to think like a Product Manager. With user groups such as grandparents, parents, and friends, we had to understand that in all decision making as future Product Managers, we lead with certain assumptions. By first understanding the assumptions we are making, only then can you begin to establish ways of validating those assumptions. Upon sharing our results, we began to see the benefit of creating a detailed set of personas to help drive features and value for the users. Off to a good start!

Part 2: Product Development Cycle

The second part of the course, we learned about the product life cycle and the development stages teams must work through. An exercise we used to further our understanding included sticking post-its of different companies on the product life cycle graph drawn on the whiteboard (development, introduction, growth, maturity, decline). For companies like MySpace, the task was pretty easy (sorry JT). For others we had to dig a little deeper into key metrics like cost of acquisition, revenue, rate of revenue growth, and AARRR metrics to peg them accurately. This is a great exercise for any product manager (new or old) while reading the newspaper to think about where companies/products fall along this life cycle. It can provide an interesting lense into the what other product managers are doing, when they are doing it, and then ultimately why they are doing it.

Another valuable framework for understanding products and the stages they go through was the technology adoption lifecyle from Geoffrey A Moore’s Crossing the Chasm.


As Product Managers, we must balance lots of different priorities. By understanding where you are along the life cycle, it will help identify what is of greater importance. It’s important to know where you are in terms of your customer’s adoption of the product as well. Innovator’s and early adopters will endure much more than your later users. In general, we learned that as you get more and more adoption, features, usability and affordability all improve.

We also took time to examine three technology development framworks: waterfall, agile, and lean. Each has their merits and appropriate applications. There is plenty of writing on this on the interwebs so I’ll just leave it at that.

Other take-aways from class:

Monthly Active Users is the main metric for any consumer app which is non-transactional. If transactional, use revenues.

To measure quality of engagement use DAU/MAU. This metric tells you what percentage of people using your app this month will also use it today. Facebook has a percentage in the range of 50-60%. Anything over 30% is good.

The Holy Grail of continuous integration: Commit, automated test, automated sample deployment, automated a/b testing, automated deployment when test group key metric is greater than control.

Facebook dropped their motto “move fast and break things.” This is a sign that they are out of their growth phase.

Stay tuned for weekly updates on General Assembly’s Product Management course. Thanks George for a great Day 01! Over and out.

What is a Performance Driven Life

@brentlarue on May 11, 2014

LONDONATLETIKA:400metrov z oviramiBRENT LARUE-SLOFOTO: Stanko Gruden/STA

In August I officially retired from the world of professional athletics. In fact the creation of this blog, while seemingly trivial to an outsider, marks a significant milestone in my life, the end of a chapter. When creating this blog I knew it needed to be something meaningful, not only to me, but others like me. When I tried to put my finger on a single theme I struggled at first, but after reflecting on my own life I found a single theme that drives my everyday — Performance. It was just as true when I was an Olympian as it is now in my professional life. It is how I tick, what gets me up in the morning, and what keeps me going. So what is it exaclty?

A performance driven life is:

Knowing perfection is a myth
and striving for perfection anyways,
while comprehending the true meaning of perfection — Progress.

It’s about doing the right thing,
and doing the thing right,
because despite what agile methodologies say, both are important.

It’s about hustle,
the kind of hustle that makes a hungry man want to eat.

It’s about understanding what you do every day
is what you do with your life.

It’s about having a vision and dedication to follow through
while never losing sight.

It’s about working smarter, not harder
because working hard is a given.

It’s about making sacrifice
without feeling like it is sacrifice at all
because you have a purpose.

It’s about learning, experimenting, and playing

It’s about paying attention
because you never know where your next lesson will come from.
Like these from my Grandfather — a military aircraft repairman, redwood logger, and schoolbus driver.

If its worth doing, its worth doing right.
If it were easy, everyone would do it.
If you know you are right, who cares what anyone else thinks.

It’s about failing,
failing again,
and then failing some more.

It’s about objectivity
plain and simple.

It’s about filtering out all the noise
so you can focus on what’s important.

It’s about making the complex simple.

It’s about figuring it out for yourself.

10 Tips to Reach the Hacker News Front Page

@brentlarue on May 08, 2014


People share on Hacker News (HN) for all sorts of reasons. Whatever your motive, whether it is evangelizing for your favorite programming language, sharing your new app with the world, nerding out on upcoming tech, or gawking over the latest IPO, having your content consumed by tens of thousands of readers is a pretty awesome feeling (not to mention good for acquisition metrics).

As of the date of this post, I have been a member on HN for 447 days. While this does not make me the oldest member of the community, it does make me just old enough to see one of my posts make its way to the #2 slot on the HN front page. So what’s the secret sauce, you might be wondering? After many failed posts, careful study of HN content, persistent Googling, and most importantly – one proven success, I’ve created a list of the 10 tips to help your post rise to the top.


1. Understand the community

There are a number of ways to do this. You can simply be an active member and make observations or you can run over to Alexa and do a quick search. Here’s what I turned up – visitors are primarily males browsing at school from the United States (and English speaking nations). Common sense will also tell you they are involved in some capacity in IT, tech, development, or simply put, computer stuff.

2. Create a title that is short, memorable, and relevant

When you first land on the New page, you only have a few minutes to grab readers attention. Make sure your title is short, memorable, and relevant. By doing this you will maximize your chances of acquiring new readers. Remember, getting them to click is only half the battle. Then they have to like the content and up-vote. Not everyone up-votes the same, so even if someone likes the article, you may not get an up-vote.

3. Speak to or incorporate current events

When writing your article, be aware of other current events in the news and in your industry. It makes for a very interesting read when a writer can tie in a related tidbit that I’ve already read elsewhere. Readers enjoy bridging the gaps and making the connections. Perhaps, you can offer a new perspective or way of thinking about the topic.

4. Consider using numbered lists

An effective way to structure your content is to number or bullet the high level concepts. This makes it easy for readers to skim before they commit to reading your post. You only have people’s attention for seconds. If you aren’t able to capture it immediately, you will lose them forever. Next time you are in front of a magazine rack look at the front covers, you should notice they all include numbered lists.

5. Link to interesting & relevant content

There is lot of great content out there on the interwebs. You aren’t the only one writing good stuff. If it makes sense, try to link out to some content which would be interesting for further reading. This is a sharing community. Show a brother some love and link to his site.

6. Don’t spam with self-promotion

Self-promotion is extremely frowned upon on communities like HN and Reddit. If you have an agenda, or if you have what may appear to be an agenda, spell it out up front. Your readers will appreciate that they aren’t being tricked into something. It also helps put the reader at ease so they can enjoy your content without wondering what’s your angle.

7. Write good content

No one wants to read poorly written or uninteresting content. One of the best ways to get recognized is to write about something interesting and write it well. Be a storyteller. This is a critical bunch, so if your content is poor, expect lots of criticism (actually even if it is great content, expect lots of criticism).

8. Be real

This is not a community which takes well to posers and phonies. These kinds of people either never make it to the top or are easily and publicly exposed. You’ve got to be genuine here. If you have an agenda, spell it out right from the beginning. Even if you are being authentic, people may be turned off if they feel you have an ulterior motive or are trying to pull a fast one.

9. Don’t write a novel

No one goes to HN to read a book. (See what I did there)

10. Cross your fingers and hope for the best

At the end of the day, you sometimes have to chalk it up to plain old luck. If you don’t get an up-vote in the first few minutes your post will get lost in the back alleys of the internet. Do yourself a favor and lose the preconception that quality will raise your article to the top. While quality does matter, it isn’t the single variable which determines your success. Lots of great content has never seen the front page and never will.

If you want to see the original article you can check it out here – 3 Ways to Speed Up Your Design Process. Full disclosure – the original blog post was on a site no longer active. It has found a new home here. Thanks for reading! Tweet, like, or share below. And get in touch on twitter.

Designer’s Guide to Happy Developers

@brentlarue on May 21, 2013

Let’s face it; an unhappy developer makes for an unhappy office. Or at least, that can be the case in our office where we have one designer (myself) and five developers. At any rate, we as designers should honor the coveted relationship between designer and developer. We are brothers in arms and together we can create awesome software, websites, apps, and whatever else. There are many ways we can nurture this relationship and establish the most productive working environment. At the end of the day, we all just want to make cool stuff. By limiting the friction between designers and developers we can really focus on making the best possible product for our users. In this post I will use a few examples from my work to show practically how these things can be done.

Clean up your PSDs, it’s the right thing to do

This one probably goes without saying, but somehow it still happens. Fast approaching deadlines, mismanaged projects, newly added features, etc. always seem to get in the way of doing this. It’s like cleaning your room when you were a kid, you don’t really want to do it, so everything else seems to get in the way. But come on guys, we’ve grown up. Right?

This is a quick and simple thing to do and it makes the life of your developer much easier. For your own reference too, it is important to clean up your PSDs. When you look back on your mockups after a few weeks, if you still have folders named “Rectangle 1 copy 5,” you will likely be confused and frustrated. I do a lot of my organizing and re-naming while I work, but no matter how much you do during, there is always a little more you can do after. Sometimes naming conventions aren’t so obvious until you’ve finished.


Slice up your own artwork

Some developers prefer to do this on their own, but you may find that if you do it well and understand what they need, this could be a hugely beneficial addition to your process. It was for us anyway. I started using the app Slicy with out last project and now I can’t imagine working without it. It saves loads of time, lessens your developers’ work, and ensures your designs will be executed more exactly.

How it works is you rename your layers or layer groups the same as the images you want to export, save your PSD, and drop the saved PSD into Slicy. Slicy extracts all the image files from your PSD and your done. You can see the naming conventions in the Photoshop layers image above (right). It works well with resizing images to or from @2x. And for those graphics which need special slicing, not the whole graphic itself, Slicy has provided a way to do this as well. Since I got Slicy, I haven’t once touched the slice tool in Photoshop. It does, unfortunately lack the ability to resize for the different Android DPIs, but there are other tools for that. I’ll save that discussion for another post.


Communicate design decisions

We as designers sometimes like to think our designs speak for themselves, but this isn’t really the case. For developers to execute your designs properly they need instructions and guidance. Depending on the nature of your workflow, this could be a well-documented PSD, ongoing conversations on HipChat, face-to-face Q&A, or a presentation of the overall design. For us, it is some combination of all of these. It is naive to think you can explain everything once and expect it to turn out exactly how you imagined. It is important to be accessible to your developers and it is encouraged to communicate with them not only after you’ve made decisions, but also during. This way, you will not be building something that is technologically impossible.

Design to the best of your abilities, not to the limitations of your developers

I am fortunate to have worked with this group of guys for a while now. We all started at different levels with different strengths and experiences. I made the mistake in the beginning of designing only what I thought was possible by the least-experienced member of our team. This ended up reflecting poorly on him as a developer, me as a designer, and more importantly, our app.

I’ve learned since to always design to the best of my abilities no matter what the developers are capable of. At first, you developers might actually be frustrated with you and chalk up your elaborate and risk-taking design as typical designer arrogance, but I’ve found after that initial irritation, they are actually quite happy with the result. People like to be challenged. Some people react to challenge differently, but everyone who has overcome a challenge feels a stronger person for it. It is this long-lasting satisfaction of a job well done that you as a designer want to see in your developers.

With our product, this surfaced with the implementation of something we called the Wellness Meter. It was a design with drops meant to reflect balance and harmony, but also visually display a statistic. The drop would sit in a track and relative to the percentage of activities performed in that category; the drop would fill up its track. The developers ended up rocking it, and now we have something we are very proud of.


Don’t forget the finer details, that’s your job too

I’m still guilty of this one, and it is something I always am striving to improve on. An example of this is to consider how many numerals will potentially fill a particular space. Your design may look good for double-digit numbers, but what happens if the number is in the tens of thousands? Another might be, consider how many lines of text will potentially fill a space. Does the composition fall apart with more or less text? Should you add ellipses or fade away the additional text?


And of course don’t neglect the interaction and animations. The job isn’t done when the UI is complete. Storyboards, like you see in comic strips, and good notation can help show what should happen to particular elements in the design. With mobile, there are a lot of commonly accepted and even pre-defined interactions, so you should be aware of those as a designer. Your developer can thank you for it later!

I hope you found this post helpful. If you have any questions don’t hesitate to ask and feel free to comment. If you want to learn more about the app used in the examples you can read more here.

A Quick Introduction to Design Thinking: 3 Basic Principles

@brentlarue on Apr 29, 2013

Brent is a designer for Ommyo, the app which connects you to the brands you know and love. Sign up here to get notified when we launch and to follow our progress.

In this post I’ll provide 3 helpful principles to familiarize yourself with design thinking. Here, we will explore what it really means to design something or be a designer. We are going to look at this topic through the lens of our upcoming application, OmmYo. This post should be helpful for not only designers, but also developers, project managers and any participant of the creative process whether directly or indirectly.

Design is more than the graphics you see

Design starts much earlier than putting pen to paper or more appropriately, pen tool to Photoshop canvas. Design starts by gathering all the information surrounding a particular project, then processing that information to gain a deeper understanding of the task at hand. Often times, this part of the process not only includes gathering information, but also consciously excluding it.

In the case of designing for mobile, most product owners and project managers will try to build too much. They will ask for feature this, feature that, do-dad here, thing-a-ma-jig there, but what they are really doing is distracting from the core purpose of the application. A good designer should be able to recognize when the core purpose or message is being diluted. This is a critical skill because the majority of your design decisions will be made with the intent to reinforce the core purpose or message.

In truth, design thinking is embedded into many team members’ roles. The product owner is involved in design thinking when coming up with the idea for the application and then also refining his idea later. The Project manager is involved in design thinking when creating user stories for the product backlog. And the developer, as you can see in the previous post The Aesthetics of Programming, is involved in design thinking when deciding and communicating which user stories are to be included into the release backlog (if you are a bit confused, see Scrum, that may help explain the process I am referring to).

As for OmmYo, once we had determined the definitive V1.0 to be released, I went to work conceptualizing the material. During this stage, I always think better when I’m standing in front of a big white board. Below you can see all that design thinking in action.


Design follows function

In most design schools, one of the rudimentary principles you will be taught is “form follows function.” I like to think of this not only as form, but design as a whole. Form is only one of the six elements of design. The others include: line, color, shape, texture, and space. These are all the tools in the designer’s utility belt. But without some higher calling, the designer is simply a mechanic with nothing to fix. That higher calling for all designers should be function, or maybe a more fitting term – purpose.

A lot of design decisions for OmmYo, and for mobile applications in general, include guiding the user along a specific path. That means the graphics associated with navigation should serve this one function, to aid the user in an effortless and intuitive journey through the application.

More specifically to OmmYo, our purpose was to have users communicate directly to consumer brands and vise versa. This meant creating a very simple and usable interface with the primary function of reading, writing, and sending messages. Sounds a lot like email, doesn’t it? In fact, people’s interaction with email was one of the primary guiding forces in the development of our application. We knew utilizing peoples’ understanding and usage of email services would be more important than chrome, glass, or wooden graphic styles, so we reached into our tool belt and built only what was necessary to strengthen that interaction. Anything extra would have been accessory.


Good designers are problem solvers, not artists; Great designers are both

I’m not going to debate about the difference between art and design, but I like to think of the relationship something like this. All design first begins with a problem. A lot of your work as a designer is more clearly defining that problem. Once you have a clear grasp of what it is you are trying to solve, you are ready to get going.

For instance, one problem we solved with OmmYo was how to reinforce the brand in which the user is writing about. The solution came in the form of recognizing the company in the user’s input, then visually displaying the company logo in the bar at the top of the screen. This was a unique problem which required a unique solution. We came up with something we haven’t seen done anywhere else and one that immediately solved our specific problem.


Unfortunately problem solving isn’t everything. Great designers are also very artistic. They have a knack for visual appeal and a deep understanding of visual languages. As with anything, it takes practice. The more you do something, the better you become at it.

I hope you found this post helpful. If you have any questions comment don’t hesitate to get in touch. Don’t forget to check back in for more insights into the design and development of OmmYo. And of course, follow us on Twitter, like us on Facebook, and sign-up so we can keep you updated.

3 Ways to Speed Up Your Design Process

@brentlarue on Mar 08, 2013

Brent is a designer for Jog of War, a strategic running game. Sign up here for updates.

In this post, I’ll provide three ways you can speed up your design process. These are tried and tested methods, as you will see in the examples below. We put all of these into practice in the creation of Jog of War and the turn around on design iterations was the best we had experienced to date. We implemented many new processes when we began this project, but from a designer’s perspective, these were the three things that added the most in terms of speed efficiencies.

Set limitations for your work

If you’re a designer working amongst lots of developers you might have noticed a few things. This one in particular stands out in my mind. The nature of design work is very different from that of development work. The key difference being, developers have a defined end point in which they must solve many problems along the way to reach that point. Designers have one problem with no defined end point. That sounds great, you might say; you have the freedom to explore ideas, a multitude of different solutions, and only one problem to solve. Easy, right? Well, that depends.

If you are like most young-buck designers then you will jump right in, head-first without first taking a step back and doing your due diligence. This, however, is not always a successful or timesaving approach. It is a bit counter-intuitive, but if you put in the time to plan, restrict, and limit, you will actually save time in the long run. Your path becomes a little clearer, and the end result draws a little nearer.

This is how we limited ourselves with Jog of War. Determine what you want to accomplish. For us we wanted a functional app and we wanted it in the hands of beta-testers fast! This would validate for us whether we had a good idea or not. We did this by coming up with a Minimum Viable Product (MVP). We started by limiting the features, and then limiting them a bit more. Once we had a clearly defined MVP with a set feature list, we scoured the Internet for benchmarks.

Find benchmarks for design and style. By finding examples of similar visual communication styles, you can begin establishing the direction for your app, product, or do-dad. Designers be wary though. If your style too closely reflects another’s you may get caught up in a crossfire (see LayerVault vs. DesignModo). This process is more like establishing a mood board and setting the wheels in motion, not copying other’s solution.

Our benchmarks were: Google Drive, LayerVaut and Letterpress.

Next, set a deadline. Don’t make a mountain out of a molehill. If people have too much time to do a project, the tendency is to make the project much larger then it really is. Stick to the essentials, do them well, and get them done in a timely manner. For Jog of War, the designs had to be shipped within two weeks so the developers could get moving.

Use style tiles

Now that you pulled back on the reins, you should be sitting pretty in the driver’s seat. For our project, we decided to try out style tiles ( I had noticed in previous projects, I was spending a lot of time on designs which would ultimately be abandoned. (For discouraged designers, please note that this is not time completely wasted, as it is still time dedicated to improving your craft). More importantly, new screens, UX adaptations, and navigation alterations meant completely new mockups with new graphical assets. I felt we were asking too many important questions downstream, questions that could have been answered much earlier. The solution came in the form of style tiles.

Style tiles help establish a common visual language before getting started on the mockups. “Can we see what this would look like in purple” will no longer be such a painful question. Style tiles consist of fonts, colors, patterns and other interface elements. Now, when your team needs to add a new screen with various elements, it will be easy to borrow the asset from the style tile that you previously agree upon. I can’t stress the usefulness of this enough when working with a new mobile app. As you spend time making your app, even with the best planning, things change, and alterations need to be made on the fly.

Version 1 Style Tile

Version 2 Style Tile Version 2.2 Style Tiles

You can download a stye tile template here (

Communicate with the client or project leader regularly

The third point is regular, clear, and open communication between the designer and the client or project lead. I’m sure every designer has shared the experience of waiting days or even weeks for approval on designs. This can all be alleviated if you set the precedence at the beginning to have regular communication. By doing this the client can monitor and also control the progress of the project. For you as a designer, this means you won’t waste time pursuing dead-ends or waiting for the go-ahead.

Since Jog of War was an internal project. The communication happened between the project leader and the designer. In our processes we used GitHub Issues as one of the primary ways to communicate. This allowed the project lead to view each new change and comment on specific aspects of the design. By versioning each revision, we could track the progress of the designs and easily refer to previous designs if need be. In addition to GitHub we also met regularly in the office and spoke on HipChat when one of us was out. At any rate, it does not matter what tool you use, but the important thing is to communicate regularly. This could look like a 15 minute phone call, Skype call, or classic face-to-face collaboration everyday. It really depends on the dynamics of your specific project.

I hope this you found this post helpful. If you have any questions don’t hesitate to ask. Don’t forget to check back in for more insights into the design and development of Jog of War. And of course, follow us on Twitter and sign-up so we can keep you updated.

When Flat Design Makes Sense

@brentlarue on Feb 21, 2013

All over blogs, forums, and social media, the debate rages on between flat and skeuomorphic design. It is a seriously hot issue in the design community. While I must say, I think this debate is largely a bunch of malarkey, it does raise some interesting points about the decision making process for designers.

I’d like two give my two pennies worth with a real-life example. What I’m not going to do is talk about the pros and cons, or why one is better than the other (that’s horse has already been beaten). What I am going to do is give an example of one case when flat design just made sense, Jog of War.

The primary focus of Jog of War was to get a minimum viable product (MVP) out within a month (For design that meant 2 weeks so development could stay on schedule). The lean process, where the term MVP is borrowed, is often associated with development, but not so much with design. Forcing design into such a small window meant changing the way we approached design.

No longer was there time for sketching out numerous ideas, scouring the Internet for inspiration, making round upon round of mockups, or lengthy discussions on alterations or new directions. The process had to be clean, tight, simple, and to the point. The best way to do this was to also have your end result embody those same values.

This brings us to the first reason why we avoided the skeuomorphic trend: it takes too long. Lot’s of time is spent copying layer styles, pasting layer styles, casting shadows, adding bevels, adjusting gradients… and the list goes on. All this design detail is frivolous. I must admit, skeumorphism does have its merits, but when it is poorly executed it has the tendency to come off as tacky and unappealing. Without the time to execute skeumorphism properly, we would have certainly ended up with a mess on our hands. Given our time constraints, we needed a process that focused on the design with its most bare and essential qualities. Basically, we needed our app to be naked.


This brings us to the second reason: we needed the design to be invisible. The point of this MVP, or the whole app for that matter, was not to impress with a swanky interface, complex interactions, or over-worked graphics. The point of the MVP was to put game itself front and center. We didn’t want to distract users with superfluous details. What we needed was to determine whether the game was fun. A more commonly accepted approach to game design is to use the graphics to help emerge the user into the whole experience. With our approach, we rejected the notion that graphics were what made a game fun. This was a bit of a gamble, but in our case it was necessary to discover if we had a game people had fun with. The solution to this challenge came in the form a one-hue color palette, simple geometric shapes, and a clean, readable typeface (Futura).


Lastly, we are believers of Dieter Rams philosophy: “Good design is as little design as possible.” Following this principle, all time and energy could be directed to the actual design itself and not those superfluous details. When there was nothing left to take away, we knew the design was ready. I must admit, it was sometimes scary to strip things away, and was not always easy, but when nothing was left but the bare essentials, you could really determine the quality of the work. With this approach, hiding poor design behind caked on styles was not an option. As the saying goes, you can polish a turd all you want, but it’s still a piece of shit. And we didn’t want one of those!


That about wraps it up. Thanks for reading. Check back later for more on the development front and a future post with an in-depth look into the design process. And don’t forget to follow us on Twitter or sign-up so we can keep you updated.