Planetary's Partner Josh Gross and Designer Tom Treadway discuss the new, and much anticipated, Planetary.co.

As an agency, Planetary creates immersive experiences for their clients daily. But what happens when their client is themselves? We chatted with Joshua Gross and Tom Treadway to find out what went into redesigning Planetary.co.

Congrats! Planetary's new site is live! I'm told it has been at least 3 years since the last build. Why now?

 We've done a lot of work, learned a lot of new things, and the web has evolved significantly since we built our last site. Now seemed like the right time to really take advantage of the new technologies to showcase the variety of work we've done in the past 6 years we've been around.

 The site began to feel out of touch not only for how we saw ourselves as a team, but also ineffectively represented the quality of our work & the extent of our capabilities.

When you started this process, what was your original design thinking, and how did it morph or change into what we see with the live version?

 We really wanted to put some lovely motion-centric touches on the site, which is something we really haven't done in the past. Historically, our site has been less… showy and we really wanted to try something different and more visually impactful this time around.

The design went through a ton of design iteration, as we bumped into technical limitations and refined the content and information.

 The original design thinking was that the site should be a reflection of our approach to any - simple & effective. I think the live site remained pretty true to those objectives.

What tools did the design team use to accomplish each stage of the design phase?

 We relied on Sketch to do most of the design work, including clickable prototypes. The design team mocked up some of the interactions in After Effects and our development team would prototype these interactions in code to see how the actually looked and felt in the browser. There was definitely a lot of back-and-forth.

How did you involve the rest of the team in this process of determining the general look and feel?

 It was a collaborative process with the team; we got everyone involved in determining what information to show, what case studies to feature and even the way we really positioned ourselves.

 We reviewed regularly with the entire team so that everyone had a say in the direction. It wasn't just a task for the design team, but for the entire team since we all work cross-discipline. Of course, as the designer, it's my job to try many as many different things as possible and exhaust all options. But it's the entire team's responsibility to collaborate on finding the strongest solution.

Obviously as an agency, Planetary has (paying) client work that is simultaneous with this internal work, how did you manage to break off time to get it all done?

 There's an expression that has come up time and time again over the years at Planetary: 

It's really tough to balance our client work and our internal projects since the former always take priority. Fortunately, we have a great team that was able to make some time to balance the design and implementation of the site between other work; it took longer than we'd maybe have liked but I think the end result was worth the wait!

 Of course - as a small team it was important for us to establish a workflow that allowed for the handling of internal experiments as well as client work at the same time. We're almost always building new products & technologies while handling client work, so this time it was no different.

What was the most challenging part of this project?

 Honestly, the homepage of the site. Up until the last two weeks of the project, we had an entirely different concept for this page. A pre-coffee moment of epiphany one morning between myself and Tom kicked it in the direction you see now, which is far stronger than what we had before.

 As is the case with any project, pivoting and finding our footing again when we hit a roadblock. When you're trying new things and experimenting with new technologies, those difficulties are inevitable.

Heaven forbid you had to do it all again, what would you have done differently?

 I don't think there's anything we would have done differently, but there's always room for improvement. The site took us a bit outside our comfort zone, so I think we will be better suited to handle these challenges come next time.

 Now we can get our focus back to our client work…along with a few surprises in between ;)

 We're working on lots of stuff both internally & externally. Redesigning our website wasn't just about marketing, but also about improving the way we operate as a team, so we're looking forward to tackling some big projects with new clients in 2019.

Planetary Launches its Newly Redesigned Website

You have a product, website, tool, or campaign that needs building. You need to find an agency or freelancer. Now what?

As an agency, we’ve seen our fair share of RFPs and Project Briefs from prospective clients. The variation between briefs is extensive: the information they reveal about the project and what they include has been different every. single. time. we’ve received one. Over the past 10+ years, I’ve seen and worked with everything from dozens-of-pages long RFPs to a couple sentences in an email.

While this isn’t the most engaging topic you’ll ever read about, it’s vital to hiring the right partner to build your project. The quality of a brief makes a huge difference in how any agency, studio, or freelancer will approach their recommended solution, estimate costs, compile their proposal, and present the pitch. The better the brief, the better you — 🎉 the client 🎉 — will be able to ensure that your expectations are met and that you build a successful relationship.

I’m not here to walk you through every possible element of building an RFP or how to find a good partner; those are larger topics covered extensively elsewhere. Instead, what you’ll find below is a checklist of seven vital elements to consider while creating a project brief. Each element has resulted in improving the ultimate outcome of projects I’ve been involved with over the years. Save it. Bookmark it. Put it in Pocket (do people still do that?). Reference it next time you have a brief to write.

Additionally, you’ll find a (free) template you can use for your own project briefs at the end of this article.

Do you have an upcoming presentation? Is there a drop-dead date where this project will no longer be relevant if not ready by then? Do you have a budget that expires at the end of the quarter?

This seems like it would be an obvious one, but it’s surprising how frequently this is left out because there is a soft timeline, certain dates aren’t yet confirmed, or simply because it’s overlooked.

Sometimes a project doesn’t have a hard deadline and that’s okay! Sometimes important dates aren’t yet finalized, and that’s also okay!

Even if you’re working with soft or unconfirmed dates, still include loose dates. It can be as simple as:

While these aren’t hard dates, it does provide some goalposts to keep in mind as the project progresses; times when the team may be distracted, unavailable, or need to demonstrate progress on the project.

Even better, include any notes about what may be happening during or needed for those key dates. Including this information allows the partner to plan for and mitigate bottlenecks if and when your team is out, as well as helping you look your best 😎 when you need to present progress internally or publicly. An example:

Presenting to the company board. Will want to show a complete walkthrough of the app.

~1,500 visitors for an industry conference; we’ll want to be able to demonstrate the product and it’s value to potential customers.

Who will be participating in this project and what are their roles?

In any project, there will often be several folks invested in the outcome and success of the project. While putting together a project brief, the potential partner may not know who these folks are, so including a reference of who will have some say in the project is extremely valuable.

Specifically, knowing each stakeholder’s job title and role within the project will allow the partner to understand who they should keep in mind at each phase of the project and how that might impact the timeline.

If, let’s say, a stakeholder is building the conference booth (from the example above), the partner may want to include them in the beta and plan to schedule training time in advance of the event. If you have a VP that is providing feedback during the design phases, the partner may want to be sure they’re available for a regularly-scheduled check-in time.

The best way to present this information is in a simple table, like this:

Talk about the goal of the project, not just what you want it to do.

At the heart of every project is a purpose: the goal that you, or your team, is ultimately trying to achieve. Goals may include decreasing customer churn, increasing internal team efficiency, improving mobile user experience, or any array of many other possibilities.

By providing this insight, your potential partners may identify a goal you had not considered or an approach you didn’t even know was possible. Ultimately, there may be better, cheaper, faster, or even more valuable ways to solve for these newfound goals. You’re looking to find a partner with expertise; take advantage of what they can offer!

How does this project fit into the organization’s needs, marketing goals, etc? What are the initiating factors?

In addition to providing insight into the goals of the project, an often overlooked aspect of a brief is the context. Why are you pursuing this project now and how does it fit into the larger [quarterly, yearly, short-term, long-term] goals that you, your team, or your company are trying to achieve?

This doesn’t mean you need to reveal long-term strategy or closely-held plans, but the more context you can provide, the better. A good partner will be able to empathize with the level of urgency or stress, or provide the right information over the course of the project to feed into the larger strategy.

This is definitely an “optional” element, as not all projects have clear measures of success (note: if yours doesn’t, it’s worth looking more closely at why), but aligning with your partner at the outset of the project on what success looks like will benefit the entire project and all teams involved.

Often, success factors can be an extension of the project goals: are you trying to decrease churn by 15%? Increase onsite time by at least 10%? Improve app usage on iOS by 25% while decreasing the crash rate by 5%? Any of these qualify as measures of success.

As a note here, payment typically should not be contingent on success being met unless your partner works under model or applies a “Fees at Risk” model. The reason here being that the work is still being done and, often, factors of success may be out of the hands of the partner; payment contingency implies that the partner is solely responsible for success.

Who will be using the product, seeing the end results, or interacting with the experience? Who do we need to impress?

Often, there are two audiences you’re going to be working for throughout the course of a project.

The first is the most important: the ‘end user’; the individuals that will be seeing/using/touching/feeling/experiencing the output of this project. It’s a good idea to have a picture in your mind — and in the brief — of who this person is, how old they are, and their “backstory.” While a good partner will help you round out the details, consider the high-level details that will go into a 

The second audience is either an internal audience of your peers or superiors, or an audience of industry peers. Who within the organization or industry do you want to help or impress? While this may not factor into the product itself, a good partner will help you identify the obstacles this audience may present and wants to make you look good too — it’s not just about doing the project well.

Existing infrastructure we need to work within? Someone we should talk to before suggesting any technical solutions?

All too often, we hear questions like the following after putting together a proposal:

“We were hoping to see a solution that uses X.”

“Our systems use Y internally; will the technology in your proposal support that?”

These questions often mean we’ll lose a project because we didn’t take into consideration the tools or technology limitations you or your organization has in place — even if we were fully capable — simply because they weren’t mentioned upfront.

If you want all partners presenting their best solutions 

that also work with existing infrastructure

, start on an even playing field by including any technology limitations or requirements you or your organization have at the outset. When this information isn’t included, don’t be surprised to receive proposals that don’t align with your organization’s needs. This may mean coordinating with your IT or internal technology teams before distributing the brief, so take into consideration any extra time necessary.

Above are just seven elements that you should consider when writing a project brief as part of an RFP or reaching out to a potential vendor for a software-based project. It is by no means a completely comprehensive list of elements.

However, we have also compiled these recommendations into a template document that you can use for your next project brief! The template includes sections for all of the above, nicely formatted and readily readable, as well as sections for additional information you may want to include. As a Google Doc, it’s print and PDF-ready, easily copied and used, or modified for your own needs.

You can get the Project Brief Template here:

7 tips for writing better project briefs

Since we first shared Spacetime publicly in 2016, 

 of teams have signed up and use our app every week. We’ve slowly become one of the most popular tools for sharing your work hours and time zone, especially amongst distributed teams.

Top teams are distributed over 15, 26, or even 40(!) different time zones and are adding new locations constantly.

In that time, we’ve received tons of positive feedback and dozens of requests for new features. We’ve definitely heard all of it and have spent the past few months rebuilding the Spacetime experience. Today, we’re excited to share the new Spacetime.

 tools, giving team admins the ability to better manage their team. Additionally, we’ve made the product more reliable, faster, and easier to use—the underlying technology has been completely rebuilt.

Today, we are also introducing Spacetime Pro, which expands on the already valuable features of Spacetime. With Pro you’ll be able to add single-channel, guest, and non-Slack users, support teammates with schedules that vary day-to-day, and group users by internal teams.

What new standard features are we introducing?

You can now update your name, profile picture, and email address from a convenient control panel.

Team Management: Administrators can now manage their entire teams! Yes — finally. You can now add and remove teammates, as well as control their level of permissions.

If you have contractors, consultants, clients, compadres, or cohorts that aren’t on Slack, or are Slack guests (single and multi-channel) you can now invite them to your Spacetime teams!

Personalize your Spacetime view by grouping members into custom categories like project, management level, team, location, or favorite color.

Multi-Day Scheduling: Many of you don’t work the same hours every day (especially, say, weekends?) and Spacetime should be able to correctly reflect your schedule. You can now set different hours by day of week — we’re really excited about this one 🎊

Not just weather. Show your current country flag (🇯🇵) or work availability (✅) as your status icon, updated automatically.

We hope you give Pro a try and we would absolutely love to hear your feedback. Sign up is completely free, so there’s no risk or cost to see if it works for your team. If you sign up for Pro with the link above, you’ll receive 20% off!*

We’re here to make your team work better, together. We hope the new Spacetime helps you do that! ✌️

Announcing Spacetime 2.0

In 2015, I wrote out my thoughts on creative feedback. Here’s that article in list format:

At the time, the Planetary design team was growing. We were grappling with one of the challenges every design team faces: how do we get good feedback?

Two years on, I’ve revisited that article many times, each time appending and amending my own mental notes. Looking ahead to even more growth, it’s the right time to do a proper update.

Do I still think feedback should be concise? Yes.

Concise feedback is the key to making small, quick iterations. The faster the turnaround on design feedback, the more velocity the design team has.

Do I still think feedback should be action-oriented? No.

It’s good to give actionable feedback, but it’s easy to over-emphasize the outcome. Prescriptive feedback sets unrealistic expectations, and is very frustrating to receive.

3. Feedback should have a consistent format

Do I still think feedback should have a consistent format? Yes.

Consistent formatting means less ambiguity. It makes feedback easier to give, and it makes feedback easier to process.

However, The format I described was a bit too consistent, and created a steep learning curve. More feedback is always better, and a good format should encourage participation.

Formatting feedback: it’s all about the process

My original framework for design feedback used a narrowly-defined template. In practice, such a specific and consistent format proved very unwieldy.

A person giving feedback is dealing with a lot of pressure, and the way they give feedback can change dynamically. What is their experience? How much sleep did they had last night? What did they eat for breakfast? Did they eat breakfast at all?

Asking someone to avoid words that come naturally to them discourages feedback. Giving someone a vocabulary bank means there’s less room for new ideas. All in all, imposing restrictions on language prevents fair participation.

Instead of standardizing our feedback language, the Planetary design team standardized our feedback process. It has four parts:

 is a powerful tool in the feedback process. Timeboxing means “setting aside a fixed amount of time.” It eliminates the greatest threat to good feedback: bikeshedding. Also, it sounds cool.

 is the enemy of good feedback. It’s a reference to 

. In short, bikeshedding is spending time discussing (usually, arguing about) minor issues. Bikeshedding saps momentum and distracts from deeper issues.

By timeboxing feedback sessions, we’ve been able to set the team’s expectations for how deep to dive. With practice, and a careful eye for bikeshedding, we can capture meaningful feedback from the whole team in 15 minutes.

While it’s sometimes useful to ask for spontaneous and immediate feedback, it’s also important to do some preparation if you can.

Before you ask your team for feedback, make sure you give the feedback-givers time to prepare. Ask for participation from key stakeholders. Schedule feedback sessions in advance, giving everyone time to review the material. Provide context, and make sure your team knows what you expect from them.

At Planetary, we have a standard template that we use for design reviews. It helps us paste in links to the design, questions for the reviewers, and any necessary context.

Empathy is like a superpower. If you understand how someone is feeling, you stand a much better chance of understanding their feedback. To give everyone a chance to understand your state of mind, check in before you gather or give feedback.

Here’s how we check in: each person, in turn, states anything that is influencing their mindset. This can be “I’m really hungry,” to “I’m distracted by an email I just got,” to “I’m excited about showing you our progress.” It’s also ok to say “no distractions.”

We usually check in popcorn-style, with each person calling out the next.

A common roadblock in the feedback process is a lack of information. It’s tough to give good feedback if you don’t have a good handle on what you’re looking at: how did the design come to be? Why is it blue? What does ‘lorem ipsum’ mean?

It’s important for the person asking for feedback to provide context up-front 

. But it’s also good to give the feedback-givers a chance to ask questions. This way, the team shares responsibility for gathering information. By asking questions, the team helps each other understand what’s in front of them.

Here’s how we ask questions: each person, in turn, asks as many questions as they’d like. The person requesting feedback gets a chance to respond, and then it’s on to the next person. We minimize back-and-forth, and put the kibosh on cross talk.

It’s tempting to try and sneak feedback into a question. For example, “Why didn’t you use Helvetica?” instead of “Why did you choose that font?” Take a second to think through your motivation in asking it: are you interested in the answer? With practice, you can keep your questions focused on clarifying and understanding.

Next, it’s time to gather feedback. This is where things get complicated, where empathy and transparency can make or break the process.

If you’re giving feedback, think about your feedback as a reaction. In short, a reaction is a personal response. It usually contains the words “I,” “me,” or “my.” It’s usually based on an impression or subjective interpretation. A reaction is easiest to define by way of example:

 This layout feels really cramped to me. 

Focusing on subjective feedback is good because … well, almost all feedback is subjective. Even feedback that seems objective — “these two blues don’t match” — comes with some assumptions that probably weren’t discussed beforehand — that the blues are supposed to match.

Not only is objective feedback rare, it also is less valuable. Any group of people has a wealth of experience, expertise, and viewpoints. Getting subjective reactions to your work delivers much more information than if the same group made objective observations.

Thinking of feedback as a reaction also opens the door to feedback like, “I really like this.” This is a great reaction, both to give and to receive.

Step three and a half: say thank you 🙏

“Thank you for that feedback” is the best way to respond to any feedback, positive or negative. It keeps the conversation going, avoids conflict, and builds gratitude and empathy.

I used to have a hard time hearing feedback based on feelings. In my previous essay on feedback, I went as far to ban the word “feels” from the feedback lexicon. This was a big mistake.

Feelings are the most easily-accessed source of feedback. A gut reaction — a very strong, immediate type of feeling — is a great thing to share 

While it’s the last step in the process (and the easiest), capturing and sharing feedback is crucial. Without a record, most feedback gets lost, mis-translated, or worse: ignored.

You can capture feedback in any number of ways. Record a video or phone call, write notes in a notebook or google doc, annotate an image on InVision, or run the feedback process in Slack. Capturing feedback makes it easier to recall later, even if you don’t refer to the notes later.

 is all about keeping expectations and understanding consistent. Keep your notes or recordings in a public place (one that your teammates have access to), and everybody benefits. This also fights the Fear Of Missing Out; If I can’t be present during a feedback session, I can always catch up later.

The feedback process is a design tool, like Sketch or Micron pens. The best part about the feedback process is that it is, by nature, a team activity. Anyone can take part, and everyone benefits.

Like any tool, the feedback process gets better with practice. At Planetary, we’ve been running short feedback cycles for 6 months or so, and we’re still working to improve (this article is part of that work).

Overall, shifting focus away from the language of feedback and towards the process of feedback has allowed us to be more inclusive, work faster, and design better.

I hope you adapt this process to gather your own design feedback, and share what you learn.

A lot of this process was shaped by my work with friends and colleagues at 

. Each of those companies works hard to improve the way companies work, and I’ve learned a lot from them.

Additionally, this essay benefited greatly from the feedback of 

 As with most good metaphors, this one involves a nuclear power plant. 

 Gut reactions should be clearly communicated as such, as they are good things to revisit from time to time.

How to get the best design feedback from your team

Data visualization is more popular than ever. With modern tools, anyone can create complex charts; it’s also easier than ever to choose the wrong way to visualize data . While the consequences of using a pie chart instead of a spider chart aren’t dire in a high school powerpoint, mistakes can be much more costly in a professional setting.

Successful examples of data visualization make it easy to understand the complex data being displayed, as well as making trends and patterns easier to spot.

Whether we realize it or not, we are constantly exposed to data visualization. The nutritions table on the back of a pack of cookies, an infographic about puppies on Twitter, or a bar chart that breaks down your business’ monthly sales in 2016, these are all examples of visualizations in the real world. Data visualization can also be international; making insights understandable, regardless of the viewer’s understanding of language.

Data visualization is a key part of our lives, and if done incorrectly, it can lead to far worse than an upset designer. Someone with diabetes needs good data visualization to make important dietary decisions. A CEO might use a chart of forecasted sales to decide whether the company can afford to keep hiring.

Data visualization enables you to tell a story about your data, and every good story needs a well-defined setting. For data visualization, the setting is the type of graph: do you use a variable width bar chart? Or maybe a line graph, or maybe even a slope chart? Answering this question is daunting, but with a step by step method, it is less intimidating.

First, decide what you want to do with the data.

You usually have four options : visualizing how your data points compare with each other, how they are distributed relative to each other, how they are related , or how your data is composed. Once you conclude which of the four best achieves your goals, other necessary research is a lot easier. If you want a quick answer, use a tool like 

 to figure out what chart type works best.

Next, before you implement your visualization of choice, make sure that it accommodates all your characters: variables.

Making sure these characters fit on the stage can help you avoid the wrong choice. For example, a distribution with one variable should be visualized with a histogram ,whereas a distribution with two variables works best using a scatter plot.

Why is all this effort worthwhile? Spending so much time researching can seem wasteful when it’s so much easier to just select a row of data and insert the prettiest graph option. As I’ve said many times, data visualization has consequences! Here are a few potential outcomes if things don’t go to plan:

You found a really cool looking graph that you’d like to use in your next presentation. Unfortunately, you have a rather large and complex data set. “Oh well, as long as it looks pretty,” right? Graphs and charts can be rather difficult to figure out when done correctly, so messing up their structure will often lead to a severe lack of understanding. This is especially true when, for example, a pie chart is used to display a huge amount of data. The chart below looks cool, but is almost impossible to read. Not only are there far too many similar colors, there are too many variables, as well. It’s almost impossible to tell how one sliver compares to the other.

The correct usage of this pie chart would be to show how much of the total beer market one brewery owns.

Worse than not understanding at all, someone reading your chart might be mislead by the data. Even if you’re showing data truthfully, visualizing it the wrong way can lead to different interpretations.In a professional environment, misunderstandings can harm people, both financially and physically.

The chart below isn’t being dishonest about the data, but it is misleading. Note how the X-axis starts with one year intervals, switching to quarter intervals in 2013. At a glance, it looks like the non-performing loans are slowing down, until you realize that if 2013 was combined into one interval, the opposite would be apparent.

Pay attention to cyclical data vs. linear data

It’s often tempting to default to your favorite data visualization, but be conscientious of the fact that different data types require different solutions. For example, displaying ice cream sales data from one week in a spider chart might insinuate that it’s a cyclical pattern. Data like that changes over time, and should use a line chart to show that progression.

For instance, if an airline shows profits in a spider chart, investors might be mislead into believing that profits from a good year with low oil costs are regular and consistent.

Make sure that you’re highlighting the data you want people to be drawn to. If you have nothing to highlight, rethink your visualization. While we should be transparent and thorough about data, we should still respect a reader’s ability to comprehend. Highlight the data that is most relevant to the story you want to tell. Make the complimentary / secondary data available to those that want to dig in deeper. Choosing the right structure and graph type can help resolve this issue and keep from overwhelming your audience.

Large data sets tend to be, well, complex. Use labels and legends generously to guarantee that there aren’t any blind spots. It’s tempting to prioritise the looks of a chart over usability, and while that gradient looks beautiful, it isn’t worth much if it makes your chart harder to understand. This goes hand in hand with the previous consequence of not highlighting the relevant data.

The chart below illustrates how much revenue each person brings in . Not only are there no explicit values, the use of nested circles makes the entire visualization confusing. It isn’t clear which year is which, and the nested circles make me think that the total revenue is shrinking each year, or growing! This data would have worked better as a line graph, where the changes in revenue would have been more obvious. If you only wanted to show the values as a percent, a stacked 100% area graph could also get the job done effectively.

Tell the right story with the right characters and you’ll be successful. Keep it simple, make it easy for the reader to understand, and try your best to be transparent. This is just a small part of the art that is data analysis and visualization but luckily for most of us, it’s the part we’ll use most.

P.S : If you ever find yourself asking “which graph should I use?” like we do on a daily basis at Planetary, feel free to use 

. We built it to help us answer that very question!

How to Avoid Picking the wrong data visualization

As I’m writing this, the Planetary team is spread out across 4 time zones in 4 different countries. This isn’t unusual for us, but it makes our “office” a unique place: we don’t all start working at the same time, keep the same hours, or even have the same daylight or seasons.

These aspects, as I’ve learned, make a surprising difference when it comes to feeling empathy.

At a traditional office, Monday mornings come with shared jokes about caffeine dependency. Rainy days put a damper on the whole team, from the wet commute to the required wardrobe changes. Early meetings can happen over breakfast, and late nights aren’t quite as bad when you’re sharing a pizza.

 I don’t know when my teammate is worn-out from a long day when I’m just getting into the swing of mine. Unless a coworker drops a picture into Slack, I have no idea what the world looks and feels like where they are. I have to keep a close eye on meeting times, to make sure they’re not too early or late.

To help bring our team closer, about a year ago we decided to try something new: a tool to allow everyone on our team to share their working hours. It automatically detects timezone and location, displaying the team as a series of ever-moving timelines, shifted by their timezone and bounded by their work hours. This hacked-together tool in hand, showed us when team members were in the “office”, or whether they were beginning their day, or finishing it up.

It worked. Scheduling meetings became easier, knowing when not to ping teammates about decisions became smoother. No more “so how many hours from now is that?” or “wait, is that too late for some of you?”

Standard view for a single user. The red line is the current time. Next, we added a Slack bot, allowing us to simply include an @-mention to convert a local time to others’. And, just for fun, a constantly-updated weather emoji automatically tacked onto the end of each person’s name.

Slack bot integration Meeting planning went from this:

We talk about the weather, and it’s easy to know when and when not to jump into a team chat. Team happiness is up, and (I’d like to think) everyone feels a little bit closer despite the distance.

Today, we want to share this tool with everyone. We’ve called it Spacetime and you can get it, free, right here or via the Slack App Directory.

While still in “beta,” we hope you enjoy using it with your remote team!

Bringing your remote team closer

Make your own tools. Hybridize your tools in order to build unique things. Even simple tools that are your own can yield entirely new avenues of exploration. Remember, tools amplify our capacities, so even a small tool can make a big difference.

While the tools we use to build on the web are complex, there are a few things we’ve taken time to make for ourselves at Planetary. Today, we’re especially excited to share the latest release of one of our tools; it’s called 

 is a foundation for modern web projects.

It takes care of a few things that are common to every project, no matter what architecture, environment, or scale:

 compiling to enable future Javascript syntax

We’ve been using it daily, adapting it, adding to it and sometimes subtracting from it since the beginning of Planetary. Though the specific tools have changed over time (From less to sass to postcss, from grunt to gulp to npm, from browserify to webpack), the basic values stay the same:

 Make sure the tools can be used in many contexts.

 Make it easy for developers to quickly start a project.

 Make the tool useful for as many developers as possible.

 Keep the tool sharp and strive to improve it constantly.

This release marks the clearest statement of these principals to date: while there’s less in the tin than ever before, we’ve really doubled down on the most functional parts to deliver on our values. In addition, we’ve documented all its features to make it even more accessible.

We share Airframe mostly out of simple curiosity: what does this tool look like in other people’s hands? What new ways will developers use it? We can learn a lot from seeing Airframe used by whoever finds a use for it.

As much as we hope Airframe receives contributions from the community, we also look forward to finding many forks and clones out in the wild.

And finally, even if you don’t use Airframe, we’d love to hear your feedback.

— The Planetary team: Andrew, Josh, Matt, Sam, Valdis, & Vince

Airframe 2.x — Why We Open Source Our Tools

For one week in August I charted the way our team uses emoji in Slack.

Going in to the project, I had a handful of notions about what I might find: I figured we probably 👋 a few times a day, near the end and the beginning, especially on Monday and Friday. I thought there’d be a lot of 👍, which can be a quick way to approve small design changes. I wondered if we’d use 😄 more on Friday than on Monday.

Here are the top ten emojis used that week, arranged by hour from 8:00am EST, Monday, August 1st, through 8:00pm Friday, August 5th, 2016.

I certainly didn’t expect 🙂 to show up at № 1 — mostly because :slightly_smiling_face: is a long string to type, even when you’re trying to communicate a very specifically slight feeling of happiness — but it turns out that it’s the face that Slack generates when you type :).

The second big surprise was @josh running away with the № 3 most popular emoji by himself 😄.

As it always happens when the data starts coming in, the study of our behavior began to change our behavior. We began to become self-conscious about which emojis we used — had we used 👏 too many times? Was there a less-creepy smiling face? How come @valdis didn’t have any emojis in the top five? Did he only use too-cool-for-school hipster emojis? Shouldn’t we have more ❤️s?

In observing this, we’ve probably raised more questions than we’ve answered. For a full week we couldn’t help but think about how we used these tiny jaundiced faces (and hands) to communicate much more complex ideas.

This Designer Made a Graph About Emoji: What Happened Next Was…

Being a small but profitable company, Planetary has the luxury of experimenting with some of the basics of what we sell and how we sell it. Simply put, we sell our team’s ability to develop products; other agencies and studios do this, and most measure their output in hours. We don’t.

Insights

3 of 4 pages

Planetary Launches its Newly Redesigned Website

7 tips for writing better project briefs

Announcing Spacetime 2.0

How to get the best design feedback from your team

How to Avoid Picking the wrong data visualization

Bringing your remote team closer

Airframe 2.x — Why We Open Source Our Tools

This Designer Made a Graph About Emoji: What Happened Next Was…

Why we don’t sell hours

Design Better Data Tables

Internet

Twitter

Instagram