How To Transform Your Next Conference Takeaways Into Real-Life Results

October 22nd, 2016 No comments

Editor’s note: So you’ve attended a conference, listened to some truly inspiring talks, made quite a few valuable connections, maybe even attended a hands-on workshop and learned a thing or two. What now? How do you bring back the new knowledge and ideas and connections to your team and to your work? This article highlights a practical strategy of getting there without much effort. With SmashingConf Barcelona taking place next week, we thought this article would come in handy.

Have you ever been to a conference with top speakers, awesome people to network with and such a great energy that you got fired up and couldn’t wait to get home to start applying everything you’ve learned? How do things look two weeks later? Did you implement all of that learning into action? How about two months later? Were you still taking action on that knowledge?

The post How To Transform Your Next Conference Takeaways Into Real-Life Results appeared first on Smashing Magazine.

Categories: Others Tags:

Comics of the week #362

October 22nd, 2016 No comments

Every week we feature a set of comics created exclusively for WDD.

The content revolves around web design, blogging and funny situations that we encounter in our daily lives as designers.

These great cartoons are created by Jerry King, an award-winning cartoonist who’s one of the most published, prolific and versatile cartoonists in the world today.

So for a few moments, take a break from your daily routine, have a laugh and enjoy these funny cartoons.

Feel free to leave your comments and suggestions below as well as any related stories of your own…

Poor computer

Save a buck


Can you relate to these situations? Please share your funny stories and comments below…

14 Unique Fonts in TT Cottons from TYPETYPE – only $9!


Categories: Designing, Others Tags:

On Style Maintenance

October 21st, 2016 No comments

I was talking to a brilliant engineer friend the other day who mentioned they never get to build anything from the ground up. Their entire career has consisted of maintaining other people’s (often quite poor) code.

In a perfect world, we’d all get to write code from scratch, it would work perfectly, and we would put it into a bin in the sky, never to be looked at by anyone again.

We all know that’s not how it works. Code need to be maintained.

Kyle Simpson often begins his talks explaining that we spend only 30% of our time writing code, and 70% of our time maintaining it. Being a good coworker and programmer is not just about being a skillful problem solver, but being legible. Great developers produce code with maintenance in mind.

I often joke that I don’t want to hire a code ninja. Ninjas come in the middle of the night and leave a bloody mess.

I want a code janitor. Someone who walks the hallways of code, cleaning up pieces, dusting up neglected parts, shinning up others, tossing unnecessary bits. I prefer this gentler, more accurate analogy. This is the person you want on your team. This is a person you want in your code reviews.

Shoutout to JD Cantrell, who is an awesome code janitor and code reviewer.

Let’s think about code maintenance through the lens of two different programming paradigms

In programming there are many tools and procedures available to meet the same end. There is no right answer. Here is a succinct definition by Michael Feather of two very popular programming paradigms:

Object-Oriented Programming makes code understandable by encapsulating moving parts…

Functional Programming makes code understandable by minimizing moving parts.

Let’s consider both in terms of not just understandability but also maintenance.

Functional Programming

I have seen for myself the value of using a functional approach in front-end JavaScript. When we write code, sometimes we want to assume that it will be used forever the way we intended, but most of us have been doing this long enough now to acknowledge that that isn’t always the case.

Functional programming includes, but is not limited to:

  • It is declarative – we’re writing in a way that can be reused and not telling the computer exactly what you need it to do at every step. This shares some similarities with abstraction.
  • It is pure – we’re not modifying or changing things outside of the function’s scope, and for this reason…
  • It is Immutable – you won’t get into a situation where you feed it the same value and retrieve different results on multiple executions.

I believe functional programming can be extremely useful in terms of maintenance because of the lack of side effects. This is huge. This keeps our code from becoming brittle. People sometimes think the biggest problem is errors in our code. I’d argue that the worst code isn’t code that errors out and fails. We can track down with methodical isolation. The worst code is code that behaves a way that you can’t predict, quietly, all over the place. You run around the code base playing whack-a-mole and sometimes it’s difficult to find the culprit. A functional programming style takes on this problem preemptively, because it’s built from the ground up to keep this from happening (as much).

Here are some resources if you’d like to dig deeper into functional programming:

As much as I’m in love with functional programming, please be aware that there can still be issues with maintenance. If a few things use the same pure function, and over time you adjust that function for one of its applications, you can get into a problem where you’re also altering other things that are hidden dependencies. Good documentation is really helpful here.

Object-Oriented Programming

In contrast, Object-Oriented Programming is a little more like following the steps to a recipe. It uses objects, which may or may not contain data, and methods, which tends to be procedural. Typically objects have an idea of self (e.g. “this” in JavaScript). Object-Orientation doesn’t focus on purity, but rather, tends to use encapsulation to make sure nothing leaks into outer scope.

At it’s best, Object-Oriented approaches tend to think of the highest order of something, then pares down to each type of instance you can have, breaking out what to do in each case. If you’re thinking about it like the Linnean System of Classification for animals and how we’d make Morphology Trees (who wouldn’t? :)) You’d start by asking is it warm-blooded? Then, does it have fur? Then does it have a snout? etc. I’m really butchering biology here, but it’s an example.

At it’s worst, Object-Oriented programming gets a lot of pretty necessary criticism because sometimes you’re not clearly describing what you think you’re describing. You can think of this like: you think something’s a banana but really it’s a peach because the only thing that’s described to you is that you have a fruit. We talked a little bit before about how that kind of code can be a nightmare to maintain, so while that’s not always the case, it can certainly come up.

An applicable example in CSS

With both functional and object-oriented approaches in our minds, let’s consider how that applies to CSS and the concept of authoring versus maintenance. CSS is written declaratively and purely. You can’t mutate one CSS block using another CSS block.

I think a lot of people would anticipate that a purely functional approach would be best for CSS. They might associate that with keeping CSS as pure as possible, which is where ideas like CSS Modules come from. The concept is that if you encapsulate the styles for the thing you’re modifying them right where you need them. You’re only ever dealing with that instance. No side effects. I don’t disagree. You avoid a few things this way.

  • You avoid collisions. This is where object-oriented programming gets a bad rap for sometimes.
  • You avoid naming. Naming is hard. You can avoid naming with this approach.
  • You avoid dealing with the cascade. I’ll address this in a minute.

For other kinds of (non-CSS) programming, we keep things pure and avoid global scope and we’re golden! So it must apply everywhere, right?

Here’s where we need to get into the right tool for the job. If we’re considering maintenance over writing, here is where other approaches shine:

  • Companies big and small tend to have redesigns at least every 1-2 years. If your code base is large, with many people, and you need to change the line-height everywhere from 1.1rem to 1.2rem, are you having to go back into every module and change that value? A global or an object that’s extended becomes extraordinarily useful here.
  • The cascade can help, if you understand and organize it. This is the same as any sophisticated software design. You can look at what you’re building and make responsible decisions on your build and design. You decide what can be at a top-level and needs to be inherited by other, smaller, pieces. This avoids spaghetti code in CSS and keeps your code DRY.
  • CSS is about design. Good design, is by it’s nature, successful when it’s cohesive. A CSS codebase that aligns itself with the design infrastructure it’s built from allows for cleaner code, with the added benefit of better collaboration. CSS can be self-checking for designers as well: “Wait we have another tertiary button? Why?” Leaks in cohesive UI/UX announce themselves well in this model.
  • Naming can help with documentation. This point is a little more prickly, and I’m not sure totally necessary, but worth mentioning. Whether you like BEM, or SMACSS/OOCSS, or Atomic, naming when done well can actually give you good information on where a class is used and why.

The paradigms share traits

As you might suspect, though I see value in other paradigms, my preference is a functional style. With that in mind, you might wonder why I would find value in an Object-Oriented approach to CSS.

Despite it’s name, OOCSS shares traits with Functional Programming. To correctly work with OOCSS the way it was intended, you’re mostly creating mixins that are expressed similarly to functions with parameters (often with defaults) across your system. They are pure, and can be applied to multiple uses.

It still uses Object-Oriented approaches as well. With a very intelligent architecture built with anticipation of how things might be affected by each other, and carefully considering what should be inherited. Considering that CSS is fundamentally a group of objects, this tends to make more sense in a CSS context than in other languages.

Last year I lead a team to completely refactor a giant Front-End component system. It used an OOCSS architecture, I and saw for myself the benefit of this type of model. Designers could ask me to modify something, and we could quickly see it update across the site. They could even change their minds without too much of a hassle. A last minute request from above did not stall our release. I’m definitely not saying it wasn’t without it’s pain points- but it was surprisingly smooth for it’s scale. This has made me look at the way I write CSS for other applications in a whole new light.


People tend to pit these things against each other:

  • CSS
  • Styling via JavaScript

I would argue that you can be maintenance friendly or create a maintenance nightmare either way.

You can absolutely deal with things like line-heights, fonts, and behaviors responsibly in Aphrodite, or React-CXS, or CSS Modules. I quite like some of these approaches. They can handle inheritance, and be written to extend for a DRY-er and more maintainable approach.

But even though you can, I personally haven’t seen enough examples of projects that do. (I’d love to see some examples!)

Mostly I see people pull out a variable or two for the brand color and nothing else. A few variables does not a responsible system architecture make. I think we can do better here, if we think about our code not in terms of what is easier to write, but what’s easier to change. Or better yet, in terms of what’s easier for others to change.

Please also take care to create good documentation! With either programming paradigm, you have to know about all of your dependencies before you adjust it. Great documentation also means you are more purposeful in your decision-making as well. There are less “oh well”s when you have to explain what a thing is and where it’s used to other people.

The issues I’m tackling in this article are issues of collaboration and scale. Not every company or site or even web app is tackling these things. This is an opinion article that comes from experience. Different things work for different projects.

My hope for this article is to encourage developers to think ahead. We’re all in this together, and the best we can do is learn from one another. If you completely disagree with me, that’s totally fine. My hope is that even in taking a stance, you might solidify a direction you head towards with maintenance as the core concept.

On Style Maintenance is a post from CSS-Tricks

Categories: Designing, Others Tags:

Draw Chrome Logo in Illustrator

October 21st, 2016 No comments

In this tutorial, we’re going to learn how to draw the Chrome logo in Adobe Illustrator.

Download Adobe Illustrator.

Read More at Draw Chrome Logo in Illustrator

Categories: Designing, Others Tags:

Poll: should coders learn to design?

October 21st, 2016 No comments

Okay developers, it’s your turn. People have ranted on and on for years about whether or not designers should learn to code. Heck, I’ve ranted about it. I still contend that… no. No no… This is about you devs, now.

Should people who primarily code the back end of web products learn to design the front end? Here’s my opinion:

[I] had to resort to the same sort of explanations that I give to clients.

Unless they actually want to be a designer/developer, learning a whole new field — a whole new industry, even — just isn’t worth the pain. It’s part of the reason I don’t do any programming. The other reason is that I’m bad at it. And HTML and CSS don’t count.

But they should at least learn the basics. They should learn the fundamental principles behind usability and UX design. They should learn the terminology. There have been times when I’ve struggled to explain my design decisions to developers, and had to resort to the same sort of explanations that I give to clients. It’s frustrating to have to do that with someone who’s on your team, but is not on the same page.

What’s more, I’ve worked with developers who could program like nobody’s business, but got lost in the HTML and CSS. I’m serious. These guys couldn’t nest elements properly, kept asking me how to do stuff in CSS, and more. They didn’t know about browser limitations and quirks (and this was back when IE was still a big problem), and even the box model was new territory.

That’s not criticism. Everyone has to start somewhere, sometime. But did things get a lot easier when they mastered the basics? Yes, yes they did.

Well, dear reader, now it’s your turn:

The Fantastic Snow Text Generator – only $7!


Categories: Designing, Others Tags:

Web Development Reading List #155: On JSPerf, Client Hints, And Keeping The Balance

October 21st, 2016 No comments

As people working in front of a screen all day, we often struggle to find the right balance. I’m not talking about work-life balance alone here, but of how our life that is completely virtual during the day often causes us to not take real life into account.

We tend to forget that our bodies need something else than coding all day. And we need to take care of our fellow human beings in real life as well. Just think about this number: The average US person will spend over 9 hours in front of a screen today. Time to become more aware of how we can keep the balance between the virtual and the real world.

The post Web Development Reading List #155: On JSPerf, Client Hints, And Keeping The Balance appeared first on Smashing Magazine.

Categories: Others Tags:

3 Ways to Present Your Client’s Website Before it Goes Live

October 21st, 2016 No comments

You’ve used WordPress to create a fantastic website that exactly meets your client’s needs, and paid attention to all desires and requests. However, there is a hazard: your customer does not want the website to go live before he has seen it. Other customers ought to see the progress on the site on a regular basis. Either way, a proper method of presentation is needed.

In Advance: Check All Important Factors

There are multiple factors to consider when it comes to keeping your customers up to date the best way possible. For example:

  • How much time will it take the client to check the website?
  • Will the customer conduct a purely visual or in-depth test?
  • For how long should the preview be available? The longer you allow the client to test, the more comments, wishes, and requests you will receive.
  • How long will your method of presentation take?
  • Can you match the schedule with your client and set up an extended live demonstration?

There are many ways to approach and solve this issue. The final choice depends on the customer, your preferences, the workflow, and the purpose of the presentation. In this article, we focus on three methods that you could choose for the display.

Method 1: Keep the Website Local and Present it Live


The Direct Presentation of Your Work During a Visit of Your Client.

The easiest and best method when your client doesn’t have a lot of time, and only wants to gain a quick overview. Just keep your website on your computer and start a presentation using a tool like Teamviewer or Google Hangouts, for example. Now, your client can see how you present the website on their computer.

Of course, you can also meet up with your client. This lets you show him the website directly on your notebook, allowing him to test it first hand.

A personal meet up should be a good choice when it comes to approving the website.

Method 2: Put the Website Online and Protect it Via Password


A live presentation is not always the optimal way for every client. Another obvious option would be the migration of the website to a web server. The website can then be protected from unauthorized access via password. The site can only be viewed after entering the access information.

However, to do so, a hosting method needs to be found first. Of course, it is possible to host the website on your server for a short time to assure a presentation. That wouldn’t be clever, though. The smarter solution will be hosting it directly on the client’s server if he happens to own a website already.

If the client does not have a website yet, he also needs to own a server or web hosting package to be able to host the website you created. Thus, the preview site should be hosted using that. You could directly set up the site with a sub-domain of the future live website.

Afterward, add a password protection to make your client happy. However, you should prevent the search engine from indexing the preview website. To do that, move into “Settings > Reading” in the WordPress admin panel and place the according checkmark.

The majority of customers will love this type of presentation. That’s because it allows them to look at the website when they have the time to do so. They don’t have to agree on an appointment at a time that could’ve possibly been used more effectively. On top of that, it also has the advantage that the client can test the website on different devices.

The Bad News:

The client could easily put all of his free time into checking your website and might end up pelting you with suggestions and requests. Additionally, change requests could occur even after a previously defined testing period.

The Solution:

If you end up choosing this method, agree on a very precise period of time in which the website is available to the customer. Afterwards, the website will either be removed, or the password will be changed.

Adding Password Protection to Websites:

There are many WordPress plugins that are capable of blocking a website, and equipping it with an access protection. Two examples of them are Maintenance and Maintenance Mode. Both plugins are in active development.

Method 3: Install the Website on a USB Stick


When your client wants to take his time for an in-depth site test, but an online demo is out of the question, this option might be the one for you. All you need to do is install a local server on a USB stick, and subsequently, migrate the website.

After that, all that’s left to do is hand the stick to your client, alongside a guide on how to start the server, and how the website is accessed. Sounds complicated? It’s not. By now, there are good solutions to this problem, and you could use Xampp or Instant WordPress, for example.

If you were to use Xampp, make sure to not use the installer during installation, but instead, only copy the unzipped packages onto the stick.

You are not sure whether it is a good idea to give the customer the preview option via USB stick?

Here Are the Pros:

  • The website is completely offline, and there is no way to accidently make it accessible to the public.
  • The security: you client can’t change anything about the website. If he were to play with the stick, no real damage could be dealt.
  • Customer friendly: you customer can take a look at the website at any time. He is not bound to appointments, and able to take all the time necessary to review the website.

Of Course, There Are Cons as Well:

  • Out of all three methods, this is the most complicated one. It takes time to realize, as not only does the website have to be migrated, but it is also necessary to install a local web server on the stick.
  • There is no solution for Apple. Thus, both you and your client require access to a Windows computer.
  • The solution is not suitable for every customer. Customers with a little bit of technological knowledge would be needed.
  • You give away every bit of control over an appropriate testing period.


Choosing the right method of giving the client a control option is complicated. There are too many things to consider, and every customer is different. However, it is generally advantageous when the choosen method contains a very clear testing period, and guarantees you qualified feedback afterward.


Categories: Others Tags:

eBay experiments with a visual search engine

October 20th, 2016 No comments

eBay, the giant auction site, has just launched a new site specifically for people looking for furniture and other complementary products and items for the home. eBay Collective, to be sure, is a site that’s aimed more at the high-end crowd, as it features items like antiques, fine art, contemporary design, and other unique items. However, what makes it stand out is its visual search engine that puts a new twist on searching on the web.

The visual search engine is Corrigon, which eBay purchased earlier this year for just under $30 million. Though Corrigon has been around for almost a decade — since 2006, to be exact — it’s only now on eBay Collective that this visual search engine is really being allowed to showcase what it can do. Corrigon works in a unique fashion to help shoppers get a good user experience when they’re looking for the right items with which to decorate their homes.

Corrigon is used in a “Shop the Room” feature on eBay’s new site. This feature allows you to hover over an image of a fully designed area of a home. Then, the search engine will search throughout eBay’s inventory to find items that are similar to the section of the image shoppers indicate.

Corrigon’s search technology was developed to help users both find and then identify an object within a bigger image. Then, users are able to match that discovery with additional images or links to items. Within a larger image, users on eBay Collective can now hover over a particular section of the image while Corrigon can see the item in that section. It then matches it with other items.

Overall, the design of the new site is very image-rich, which makes sense since products need to be showcased to shoppers trying to make buying decisions online. This new site is eBay’s newest try at better serving its user base of active shoppers, which totals 164 million. Curating the site in this unique way with the new visual search engine is aimed at providing a much better UX to all shoppers.

LAST DAY: MOTOPRESS – Drag and Drop Editor for WP (unlimited license) – $29!


Categories: Designing, Others Tags:

The Challenge of Constructive Criticism and How to Get It

October 20th, 2016 No comments

Something that has been on my mind lately is how we talk about the deliverables we work on as designers and developers. There are plenty of times when we want feedback on our projects and turn to our friends, co-workers, colleagues, Twitter, and all kinds of other people for their honest opinions about the quality of our work.

But this can be problematic. The feedback we get is often not what we hoped for. In some cases, it can feel personal, which is almost never what we hope for.

Managing the way we seek, request, and respond to feedback can have major implications on the end result of our work. This post will cover some tips and tricks for having those dialogues.

Let’s Set the Scene

Here’s a common work scenario:

  1. A project is assigned to you
  2. You work on said project
  3. You turn project in to the person who requested it

Pretty standard, right? Sometimes we’re tasked with an über-large project that takes weeks to complete. Other times, it’s something simple that we can churn out in a few hours. The thing all projects share in common is that they’re ultimately going to be turned into someone who will either be happy or not-so-happy with what we did.

Getting a positive reaction to our work is ideal. That’s what we’re aiming for at the end of the day. Getting a negative reaction can strike nerves in the best of us, especially with work we’ve invested personal time and energy into.

Not all feedback is equal

The truth is that not all feedback is the same and should not be treated as such. I recently read the book Discussing Design as part of a team exercise and really loved the way that authors Adam Connor and Aaron Irizarry distinguish between different types of feedback. Here’s a comparison of the three types that were mentioned:

  • Reactive feedback: “Ugh, that’s gross!”
  • Direction-based Feedback: “I would have made all the text two pixels larger across the board.”
  • Critique: “If the objective is to make the content of an article easy to read in a leisurely setting, then perhaps we ought to consider a larger font size that allows readers to sit further from the screen because they will otherwise have to lean in to read the words.”

Reactive feedback has been the most toxic type of feedback in my personal experience. Even positive reactions leave me with a sorta empty feeling that I dodged a bullet and turned my work in on a day the person looking at it just so happens to be in a good mood. It’s nice to hear it, but may not help me know or understand what I did well, or if I even did well at all.

It’s worth noting that reactive feedback is sometimes exactly what we want. I know I’ve worked on projects where I truly want someone’s primitive, guttural reaction to my work, particularly where moods and emotions are part of the project objectives.

Direction-based feedback reminds me of this old Tumblr collection of hovering art directors. Go ahead and look at the photos because I’m sure you’ll have a laugh having been in the exact same situation where your boss or team is huddled right over your shoulder and calling out edits to your work as if you were a real-life Siri capable of making those changes in real time.

I will say there is a time and place for direction-based feedback and I have certainly benefited from having wise and experienced folks mentoring me on projects. That’s not really the point of this post though, rather simply to point out that it is a type of feedback.

Critique is somewhat the Holy Grail of feedback. Where the other two types might be tinged with emotions or personal preferences, critique recognizes the objectives our work is supposed to solve and tries to align our work to them.

Critique takes work and that’s sometimes a luxury, especially for projects with tight deadlines. Critique is also a skill unto itself that requires the effort of both the person seeking it and the person providing it. Discussing Design really does a nice job of diving into the practice and art of critique and is a worthwhile read for anyone interested in digging further in.

For the purposes of this post, let’s go over some tips — and yes, tricks — for getting the right type of feedback when we need it.

Knowing who to ask for feedback

This is pretty straightforward for a project that only has one stakeholder (i.e. the client) but the reality is that projects often have multiple stakeholders who have a shared and vested interest in the work being done.

The key is to pair the type of feedback you need with the right people during the project life cycle. For example, I have a rule of thumb to not show work to anyone signing off on the project before I am completely comfortable receiving a reaction. I have found that showing work to stakeholders while I’m still making decisions on my execution leads to premature assessments of the work as a whole and does the work I’ve put into the project so far a huge injustice.

That means friends and colleagues can be a better sounding board for early opinions. This might be font pairings in a design, class names in CSS, deciding between frameworks, or just about any early decision you might be making, regardless of the project.

The times I feel most compelled to reach out to a stakeholder ahead of formal feedback are when I need more clarification on the project’s objectives. An example of this might be a performance consideration that was never mentioned in the project requirements and you need the stakeholder’s opinion on whether or not solving for it is within the scope of work.

Knowing what to ask

I would be lying if I said I have never sent an email to a client to the effect of:

Hey, I’m all done with Project XYZ – let me know what you think!

This is where the poop usually hits the fan.

For one, how fair is that to the client? Not only have I provided no context for what’s being turned in, but I haven’t even formed the request for feedback into a valid question. Seriously, I’ve done this before and it’s rarely (if ever) yielded a helpful response. Instead, it provides my client with a blank check to say and respond in any way they want. You know the old adage of garbage in, garbage out? Well, getting garbage feedback should be expected from a garbage request like that.

Constructive feedback is more likely to occur if you take the initiative to frame the conversation when seeking it. Here is a handful of questions I’ve seen before when I’m asked for feedback with examples of how they can be framed for more effective dialogue.

Common Question Better Question
What do you think about the colors I used for the buttons? The project objective is to ensure users have a clear call to action to purchase an item but only if they have not already purchased the item being viewed. Are the active and inactive color states of the button clear enough? Do they conflict with each other for any reason?
Does the background image of the header look alright to you? The project wants to evoke a feeling of excitement and trust. Does this image convey those qualities when you see it? The project also requires a responsive layout, so does the image still convey those qualities even when it gets cropped on smaller screens?
Did you notice the animation when the form submits? Awesome, right? The project requires that we use CSS animations so the site feels modern. I decided to animate the submission button of the contact form so that it becomes a confirmation on submission. Does this animation feel modern while still informing the user whether the information has been received?
Does this CSS look clean? This is a really big project with over a dozen unique templates and hundreds of different components and the code needs to be organized for team collaboration. I split the CSS up into Sass partials and used an BEM naming convention to keep things organized. Is the rest of the team familiar with those standards and, if so, ready to inherit them?

Notice what all good questions have in common? It boils down to four traits: (1) isolating the question to a particular aspect of the project, (2) aligning the question to the project’s objectives, (3) providing context for the decision that was made and, lastly, asking the question itself.

This is the grand trick to getting solid and constructive feedback for any project. It allows the person receiving the question to recall what’s being solved, get in your head space and make a comment from there. If you provide a well-though, well-constructed request for feedback and still get a garbage reactive reply, then that’s where you can point back to the question and redirect the stakeholder to provide a reply that’s on topic.

Knowing how to set expectations

Now that we know who to ask for opinions on our work and how to ask questions that lead to constructive dialogue, the next trick in our pocket is setting good expectations. What I mean by this is making sure that everyone — including ourselves — is on the same page as far as what’s being worked on, what is going to be discussed, and what actions will be taken once the feedback has been received so that the conversation can continue and (hopefully) lead to approved work that everyone is confident releasing.

Many of you reading this are likely well familiar with the concept of delivering rounds on a project. If rounds are a new concept to you, the basic idea is turning in a first “draft” of your work for feedback, making changes in a second “round” of work, and repeating the process until a final iteration is approved.

I really like this process whether I’m working in design or code (or both!) but it can easily get out of hand if we’ve neglected to set expectations for what is going to be worked on in each round, combined with the tricks we’ve learned up to this point in knowing who to ask for feedback and how to ask questions that lead to good feedback.

My trick is that I tend to break my work up in rounds with each one focused on a specific aspect of the project. For example, a typical website project might look like this:

  • Round 1: Wireframe and layout
  • Round 2: Design patterns and interface components
  • Round 3: Colors and styles

I like to break projects up into rounds like this because it not only allows me to focus on a specific task of the project at a time, but it also acts as a meeting agenda with stakeholders. Everyone knows what is being worked on and what will be discussed when work is delivered.

Going back to the example of an email I have admittedly written to clients before when delivering my work:

Hey, I’m all done with Project XYZ — let me know what you think!

Applying our new trick of setting expectations would allow me to say something more helpful:

Hey, I’m all done with the first round of Project XYZ. You might remember that this round is specifically focused on the wireframe and layout of the page templates. I believe this meets all of the objectives we discussed, but here are a few questions I have for you to keep in mind and answer for specifically as you review the work.

Hopefully that sets the stage for an awesome round of feedback. If the client has changes, you’ll know that they were at least aligned to the objectives of the project. If the client has no changes, you can continue to push for more feedback if there are other considerations you think ought to addressed before moving to the next round. Regardless, my rule of thumb is to stay on a round until all of the feedback and action points for it have been fully addressed.

Another trick: use a subject line that clearly identifies which round is being discussed, whether it’s over email, your project management system, an internal memo, or what have you. Continue using that subject line until the round has been fully discussed and approved, then move to a new subject line for the next round in a fresh chain of responses. This keeps all the feedback you receive together and continues to set good expectations for what’s being discussed.


  • Discussing Design by Adam Connor and Aaron Irazarry is the book that got me thinking about these concepts and is highly recommended for anyone who works with clients or a team environment.
  • Project timeline template by Brad Frost. This is super helpful if you’re interested in the concept of breaking a project up into rounds because it can serve as a way to visualize those rounds and serve them in a central location that everyone can refer to at any time.
  • The 20-Second Gut Check is an excellent way to request and control reactive feedback.
  • Five Second Test is another excellent tool for reactive feedback.
  • The CSS-Tricks forums are available around the clock and are chock-full of folks willing to provide reactive, direction-based and critical feedback.

Wrapping up

The work we do is hard.

What’s harder is following through on our work. Doing the work is only one aspect of what we need to do to be effective in our jobs. There’s a reason that good communication skills are listed in nearly every job description I have ever seen and that’s because our work requires it to follow through to completion. Failing to follow through with good communication is no different than a baseball player failing to swing the bat through a pitch just because contact has already been made in the middle. Without follow-through, our work is more of a bunt than a clean hit.

What we covered in this post are tricks specific to the follow-through of our work. Keep doing the awesome work you do and supplement it with these ideas to take things to the next level. That’s what good feedback does: it takes what we’re doing right and elevates it to even higher places. Hopefully these “tricks” will kickstart great conversations that improve your work, lead to new tricks, bring clarity to the project management process, and allow you to build awesome and collaborative relationships with others along the way.

The Challenge of Constructive Criticism and How to Get It is a post from CSS-Tricks

Categories: Designing, Others Tags:

17 Great Letterpress Business Cards That Define Past and Present Craftsmanship

October 20th, 2016 No comments

With the advancement of technology, sometimes it is good to move forward quickly, but sometimes it is good to connect with the past and use trusted precedents for print. With Letterpress Business Cards you get an old style printing method that has evolved from functionality into an art form. At Jukebox Print we understand that human creativity, just like the human body is constantly surpassing itself and raising the bar to new heights. By surpassing ourselves in Letterpress, we tested our skills and perfected the art and the result is the ability create unique things never seen before.

While we understand that looking at a picture of a Letterpress Business Card might not warm your soul quite like looking at a painting by Matisse does. Even still, we hope our work inspires you. Maybe after this, you will think Letterpress Business Cards are as cool as we do.

Circular Business Card


These 2? Circular Business Cards were produced in fine detail with 15 colors of Letterpress. The final touch is exquisite pastel pink Painted Edges.

Jean Jullien Business Card


These unique die cut cards were produced for the Parisian designer Jean Jullien. Finished off with painted edges.

Lion Business Card

We took the challenge from designer Ksyu Deniska to create this intricate card with eleven colors of Letterpress and strokes as thin as .02 mm!

Don’t Try Studio Business Card


3ply Layered Business Cards with 5 colors of Letterpress made for Parisian designer Monge Quentin.

ABSOLUT Business Card


Letterpress is the perfect complement to other specialty print processes such as foil, as shown here with the beautiful black ABSOLUT card.

Ribbon Business Card


This cute ribbon-shaped card is the perfect design for an event planner.

Pillow Texture Business Card


This luxurious business card features a 3D embossed pillow texture with letterpress, making this one of the most expensive business cards around.

Deer Embossed Business Card


Wonderful 3D embossed card with a subtle touch of letterpress.

Bloom Creative Business Card


Combining creativity with functionality these cards feature 9 colors of letterpress with a deep impression, white foil stamping, and 3-ply layering. Each card has a unique color backing.

Vintage Business Card


This vintage Letterpress project was produced on paper from the late 1800’s! These cards were produced for Setback and Jukebox will soon provide the ability for people to order cards on real, vintage 100-year-old paper. These will truly be the most unique and original cards. The old style of printing combined with the antique paper makes this piece uniquely special. You can feel and smell the history of these cards and they are the perfect cards for any vintage selling company.

Ice Cream Business Card


This cute ice cream business card was generated with seven colors of letterpress. The color in the design is the result of immense details and pulls of a great retro look.

Pineapple Business Card


The cutest business card, a custom die cut in a pineapple shape with letterpress and gold foil.

Leather Business Card


Letterpress and real leather, a perfect combination. A multi-use as a hang tag that can double as a business card as well.

Seashell Business Card


3D embossed to the shape of a seashell with simple letterpress type. This card may look cute but is very difficult to execute!

Paint Swatches Business Card


his simple, colorful business card doesn’t seem so simple once you realize it was created with 19 different colors of letterpress!

Foxyards Business Card


Another stunning combination of Letterpress and 3D embossing.

Typewriter Business Card


This custom die cut typewriter is the perfect card for an old school writing enthusiast.

Read More at 17 Great Letterpress Business Cards That Define Past and Present Craftsmanship

Categories: Designing, Others Tags: