@brentlarue on Aug 9, 2014
@brentlarue on Aug 9, 2014
@brentlarue on May 11, 2014
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?
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,
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.
@brentlarue on May 11, 2014
@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.
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.
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.
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.
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.
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.
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.
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).
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.
No one goes to HN to read a book. (See what I did there)
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.
@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.
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.
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.
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.
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.
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.
@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 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.
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.
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.
@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.
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.
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.
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 (http://styletil.es). 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.
You can download a stye tile template here (Style_Tile_Template.psd.zip).
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.
@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.