Models, Cats & Pirates – A Lesson on Product Management

@brentlarue on Dec 12, 2014

Bridge created by from the Noun Project

Welcome back to the inside scoop on General Assembly’s product management course. Today’s class was all about business models and metrics. Let’s skip the intro and jump right in.

Business Model Design

During the first part of class we learned about different types of business models, components of business models, how those components relate to each other, and how to develop a business model around a new product idea. Three common business models that dominate the digital world are e-commerce (Etsy, Amazon), subscription (Spotify), and ad-supported media (Gawker). And there are also companies with pre-revenue models (Snapchat, Instagram). More specifically, these business models describe the monetization of a larger business model canvas (or lean model canvas).

The Lean Model Canvas (a derivative Alexander Osterwalder’s original 2008 Business Model Canvas) looks something like this. (Download the Excel template)


The lean model canvas forces you to think about all aspects of your product, from what problem you are solving to how are you going to make money. Once you’ve taken the time to fill this out, you should work to identify your biggest assumption categories. As with everything in product management, do your best to test any and all assumptions. This will reduce your risk and increase your likelihood of success.

For practice, think of an existing company or product and work through the canvas. It is easier to evaluate an existing product than it is to create a new one. We ran into a case during our exercise where the user and the customer were different. This resulted in the majority of our solutions only solving the users’ problems while the customers were the ones paying for the product. This required us to take a step back and work through two canvases, one for the user and one for the customer, to ensure that no needs were ignored.

“If you’re going to put your product in beta – put your business model in beta with it.” – Joe Kraus, Google Ventures

Lean methodologies teach us the way to validate those early assumptions are by creating a Minimum Viable Product (MVP). An MVP is the least amount of work you can do to learn the most of something. As I said before, this reduces risk and maximizes success, but it also provides faster feedback, reduces overhead, and creates measurable progress. You do not need to code to test something.

The perfect example comes in the form of a cupcake. When couples go shopping for wedding cakes, the bakery doesn’t whip up a whole cake, but rather lots of cupcakes each representing the different options. Some types of MVPs that exist in the technology world are concierge (delivering a service manually rather than automatically), wizard of oz (delivering a product where behind the scenes everything is manual), landing pages (to measure interest), and video (to demo a complex concept) MVPs.

See also the Top 10 Business Model Pitfalls.


In the latter part of the class we learned about how to identify the right metrics/KPIs, tools to use, the conversion funnel, and how the funnel stage determines what should be tracked. First things first, what is a KPI? A KPI or key performance indicator is a type of performance measurement. It is used to evaluate the success of a product, organization, or activity. When defining metrics, keep in mind that a good metric is always understandable, comparative, a rate or ratio, and behavior changing.

As Product Managers, there are many frameworks at our disposal, but one that has been readily adopted and used today is called Pirate Metrics. This framework developed by Dave McClure uses the acronym AARRR to represent Acquisition, Activation, Retention, Referral, and Revenue. Activation is concerned with getting the customer. Downloads or signups is a good metric to measure this. Activation gives them a positive experience with the product. The metric here is often contingent upon the product, but can be something like sharing a photo or posting a status update. Retention is all about bringing them back. Daily active users (DAU) over monthly active users (MAU) is a good metric for retention. Revenue is all about money. Metrics here are all centered around making money. Referral is about virality. Metrics include number of invites per user, conversion rate of invites, and the viral coefficient.


Metrics are not only for measuring success, but also can be used in prioritization. When identifying your key metrics, also determine what an appropriate target is for that metric. Do some research to identify what is an appropriate target. The book Lean Analytics provides a lot of useful ways to go about doing this. If you haven’t noticed already, Pirate Metrics sets up a conversion funnel. By identifying the areas on your funnel where your metrics fall short of the targets, you can begin to prioritize your efforts. Always start higher up on the funnel when making change to your product. If you aren’t making any money, you don’t want to change you monetization strategy until after you have found a way to drive people to your product.

Useful tools and resources: Google Analytics, KISSmetrics, Compete, Flurry.

It turns out cats don’t have much to do with product management. But they are awesome! Thanks for reading. Share and Tweet below!

It’s Going Down at #StartupAsia

@brentlarue on Nov 26, 2014


The Startup Asia conference is live and in full-swing in Jakarta. Day one wrapped with lots of interesting speakers covering a wide array of topics from petting tigers to how startups can be successful in the Indonesian market. The booths were buzzing and founders were sweating preparing their pitches for investor speed dating. Two of the most notable presentations coming out of the Kickstart room were Ana LaRue’s fireside chat speaking about Path’s success in Indonesia and Khailee Ng’s 5 moves to master the 3-minutes pitch.

Path’s Success in Indonesia

Ana LaRue is a Marketing Manager at Path, a San Francisco based startup focused on bringing happiness, connection and meaning to personal life through design and mobile technology. Ana works on growth, engagement and marketing related projects and is currently living in Indonesia, where she is helping Path set-up a local office. Ana has extensive experience in online marketing where she worked in publishing and impact investing sectors.

Path is making big strides in Indonesia. Their presence here is a sign that there is much more to come for Indonesian users. With the goal of hiring a country manager and setting up an office Indonesia, Ana says Path is dedicated to understanding and catering to the Indonesian market. Plans are in the works to collaborate with brands and form strategic partnerships with Indonesian companies to help foster growth in the nation. Already, Path has worked with local Indonesian artists to create stickers used in their messaging app, another way which Path has worked to delight their users. But the growth Path has seen has not come without it’s challenges and change doesn’t always come easy. Rest assured, Ana says Path is paying attention and committed to creating meaningful experiences for it’s users, especially those in Indonesia. Stay tuned on what lies ahead on the Path blog.

500 Startups’ 5 Moves to Master the 3-Minute Pitch

Khailee Ng is Managing Partner at 500 Startups. His focus areas include global expansion, managing the Southeast Asian fund, and building bridges between emerging markets and Silicon Valley. Born and raised in Malaysia, he started creating web products at age 15. By the age of 30, he built a news company (now listed in the Malaysian stock exchange as REV Asia) and ecommerce company GroupsMore (acquired by Groupon). He hopes to create tomorrow’s game changing companies by providing people from anywhere in the world with equal access to global resources and opportunities.

The charismatic Khailee took with stage brooding with excitement. For all the young founders in the room, Khailee shared an excellent framework for creating a consice and effective pitch. His approach approached the art of pitching from a different angle. Don’t think about what you want to say first. Instead, think of the reactions you want to get, and then form what you want to say around those.

His framework defines those 5 effects as:

“I want to know more”
“What a great idea”
“This is going to be huge”
“This is the team to do it”
“I want to be part of this”

Some key strategies to doing this are amplifying the problem. Once the problem has been clearly defined, take a small problem that a specific user had where you were able to effectively provide a solution. Once you do this, juxtapose this small problem to a larger audience. Next, get into some number, but don’t try to dazzle the audience with huge market size numbers with top-down thinking, but instead think from the bottom up. How many users will you foreseeably have? How money do you make form each user? And there you have a reliable and believable number. To further establish credibility in the figure, speak about how many users you already have and how you were able to acquire them (via Pinterest, Twitter, Launch page, etc.). Build onto this number by describing how much you expect to grow and what that means for the monetary value of your venture.

Next, describe you team. But don’t just list the names and positions of your team, calling them pirates, ninjas, or whatever. Instead, start by describing what competencies are needed to make this successful and demonstrate the unique quality of each individual and how they are the best team for the job. Lastly, let the audience (users, media, investors) know how they can be a part of it. There are many ways to achieve this effect, whether by emotional appeal or reiterating you vision, but you want to qualify who you want to be involved specifically. Throwing a huge net will make you appear desperate and without a plan. Become desirable by pre-qualifying the investor you are looking for and the type of user you hope to satisfy.

And there you have it, looking forward to an exciting day two. Be sure to tweet and share below!

Inside General Assembly’s PM Course Day 03

@brentlarue on Nov 25, 2014

Product Management

Alright, I’m back with the insider’s track on General Assembly’s Product Management Course with George Favvas. This week, we took a dive into features, user stories, wireframes, and storyboards. The class was chock-full of good learnings. We kicked off the session reviewing findings from our user interviews. A lot of my colleagues (including myself) learned their product idea was actually a solution in search of a problem. What a great time to learn this before having spent significant time and money building the wrong product!

Features & User Stories

Product features are not something that are arbitrarily decided. They are not creative ideas that a design or marketing team invokes, they are not cool technology implementations the development team comes up with, and they are not new and exciting add-ons the product manager dreams up. Product features are derived to address a specific want or need of a user. Each of the roles above fall into the trap of doing what they do best — designing, developing and managing, but this more often than not is the wrong way to approach feature inception.

We went through an exercise of evaluating a familiar product, Gmail, to describe what needs are already being addressed through current features and what needs still exist with the current product. As we listed out the basic needs, one of which was sending emails, it became clear which features were created to solve those specific needs. For example, as a user, I need a way to create a new email message. The feature derived from this need was the “compose” button. This exercise brought about a lot of discussion on current frustrations with the product including both real wants and needs of users. These wants and needs were later translated into very practical features (Google, we should talk!).

The Gmail exercise naturally led into the definition of a user story. For those new to Product Management or Agile Development, a user story is a short, simple description of a feature told from the perspective of the person desiring the new functionality.

As a <type of user>, I want <some goal> so that <some reason>.

I like to think of user stories as the building blocks of your product to be used by all parties of the team so they may begin to understand and work on the product. User stories (along with personas) continue to drive home the user-centric thinking on your product, one of the key tenants of a successful product. To make that point clear, George provided an intriguing example using Raid bug spray.

When Raid was first launching its product, it had a formula which was 99.9% effective in terminating bugs. However, despite the effectiveness of the product to terminate bugs, sales were plummeting. It wasn’t until user research was conducted that it was discovered users had the expectation of actually seeing the bug die in front of them. Whether this expectation was created by advertising or not is a moot point because the product was suffering as a result. Upon learning this, Raid adjusted their formula so the bug would die instantly and the product sales surged.

Wireframes & Storyboards

In this session, we learned about the different levels of fidelity in wireframes, the importance of and how to create wireframes, and storyboarding.


Wireframes comes in many forms from napkin sketches to hi-fidelity, fully annotated wireframes. Each level of fidelity serves a specific purpose. Sketches generally serve as an exploration where the designer or PM plays with different ideas and stimulates thought. Lo-fidelity wireframes establish the conceptual design where features are realized, layout and composition defined, flow is established, and hierarchy of information/functionality are displayed. Hi-fidelity wireframes are polished versions of the wireframes which include all the information/functionality in the correct place and size. These wireframes should include annotations describing any interactions, transitions, functionality, etc.

All wireframes are intentionally void of visual design so that feedback is entirely focused on flow, layout, hierarchy, information architecture, composition, usability, etc. It may be tempting to splash some visual design elements in at this stage, especially if the UI designer has got a jump-start, but this will only distract at this stage. It is also worth mentioning there is no wrong time to solicit feedback from users. While soliciting feedback, it is important not to lead the user. Learn to be comfortable with the long pauses so that you don’t guide the user. While conducting the session ask questions like: what do you think is the purpose of this screen, what do you want to do here, what do you expect to happen when you perform that action? Be careful to observe what the user wants to click on even if it wasn’t designed to be a clickable area and remember no to be defensive of your product. This process takes practice and skill that takes lots or repetition to improve so ultimately you will solicit the best and most meaningful feedback.

“Understanding and usability over pretty.”

There are some limitations to wireframes however. It can be difficult for the user to envision the end product. Also without any form of visual design, some elements which can be made obvious via visual treatment may get lost in the wires and alter the way the user would actually interact with the product. Despite these limitations, wireframing is a key step along the process and one in which can provide a lot of valuable information to PMs and their teams.

Finally, storyboarding is the process where sketches or wireframes are outlined in the sequence that a customer will experience while using your product during a specific activity. This provides context and allows the users and your team to explore the complex interactions. It helps identify not only the happy path, but also the unhappy path where error messages, additional screens, or more creative solutions may be required. The unhappy path, if left unattended, can be the root of lots of frustration from your future users.

If you enjoyed the post, share the love! tweet and share below. Thanks for reading.

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.