https://m.signalvnoise.com?source=rss----668e14b18fb1---4
https://cdn-images-1.medium.com/proxy/1*TGH72Nnw24QL3iV9IOm4VA.pngSignal v. Noise - Mediumhttps://m.signalvnoise.com?source=rss----668e14b18fb1---4
MediumThu, 24 May 2018 18:25:59 GMTThis is an XML content feed. It is intended to be viewed in a newsreader or syndicated to another site.http://feedproxy.google.com/~r/37signals/beMH/~3/42swamzLE-U/the-owners-word-weighs-a-ton-2772f0934a93
https://medium.com/p/2772f0934a93Tue, 15 May 2018 18:37:50 GMT2018-05-16T14:10:42.880Z

Be careful not to throw your weight around without knowing it.

Yesterday I was in a board meeting for a company I advise. Great group, strong business, profitable, all the good stuff. But the owner-CEO was stuck. He felt like he’d laid out a pretty clear vision and direction, but people’s priorities kept shifting. This thing was important, then all the sudden it was this other thing. Lots of bouncing around, not quite enough focus. He didn’t know what was causing it, but it turns out it was him. But how?

We dug into it. As we went, I recognized the problem.

As much as we’d like to pretend we’re just one of the crew, the owner is the owner. And when the owner makes a suggestion, that suggestion can easily become high priority. It’s rarely what the owner intends, but it’s often how it’s received. When the person who signs your check says this or that, this or that can quickly become the most important thing.

So something as minor as “Are we doing enough on Instagram?” can shoot Instagram to the top of the marketing priority list. It was a mere suggestion, but now it’s a mandate. “Why would he be talking about Instagram unless he really thought Instagram was super important?”

What’s worse is when the owner finds him or herself in the weeds. Meddling too much in this problem or that problem. If that’s where they’re spending their attention, people assume it’s top priority. It may be a mere curiosity, but that’s not the impression it makes. If she’s looking over there, then we should be looking over there. The owner’s presence in a problem area can re-prioritize the organization’s plate without intending to.

And that’s just one example. But owners like to lob ideas all over the organization, and often many at the same time. You can think of them as tiny pebbles being tossed into a pool. When the pebble hits the surface, it radiates small waves. If you’re in that pool, you’ll be affected. A splash over here sends waves this way, a drop over there sends them in another direction. Before you know it, the stillness is broken up by intersecting rings of water. It can get chaotic pretty quickly. And after a while, it’s unclear where all the action started, it’s hard to trace. It’s just busy, churning water. It takes a long time to settle it back down again.

So if you own the place, be careful what you say and when you say it. Most of the time your word carries more weight than you wish. Reserve that weight for when it’s really necessary.

We have another Mailbag episode, where Jason Fried and David Heinemeier Hansson answer listener questions. In this installment, they tackle questions about workplace communication and remote working. Alison Green of Ask A Manager, whom we featured in our previous episode, gives her advice on a couple of questions too.

]]>https://m.signalvnoise.com/opening-the-rework-mailbag-e0bea7cdf49e?source=rss----668e14b18fb1---4http://feedproxy.google.com/~r/37signals/beMH/~3/ixxNQ5OEBZc/heyyy-improved-hey-in-basecamp-3-for-android-5b16225b041a
https://medium.com/p/5b16225b041aTue, 01 May 2018 17:01:00 GMT2018-05-01T17:01:00.881ZPing and Message excerpts, image previews, and grouped Campfires make catching up with Basecamp a breeze.

There’s a new Hey! screen design in Basecamp 3 for Android. Hey! is already pretty good on Desktop and Web. Currently you get a chronological list of unread Campfires you’re following and discussions you’re part of.

On Mobile, however, you’re probably peeking in for a quick summary of What’s New. Hey! should help you prioritize what’s important at that moment. A better design can save time.

Here’s how the current Android Hey! and this new design compare:

The new design (right) makes Hey! easier to parse and prioritize.

✨ What We Improved

Show me my Pings. Excerpts from unread Ping conversations are now shown at the top of the Hey! screen. If you have more than one unread Ping conversation they’ll be grouped together. You’ll see all your new Pings in one place. Note: All Pings are still accessible everywhere in the app via the top navigation. Just tap the “conversation bubbles” icon next to Search.

Group unread Campfires together. New chats from Campfires you follow are now easily scanned since they’re grouped together. The Campfire notification will also display who spoke last (which matches Basecamp 3 on the Desktop and Web).

Give context to Messages, Comments, and more. It’s a mystery what’s behind that unread notification. It might be 1 sentence, or 1 emoji, or a long paragraph. Now there’s an excerpt of text and image thumbnails so you can see what was posted without having to tap through.

💅 The Result: Better Insight into What’s New

Messages and Comments are no longer a mystery. Excerpts and image previews hint whether you should dive deeper or move along. Unread Campfires aren’t scattered across other notifications. You can prioritize chats you want to read.

The new design gives Hey! notifications more context. It helps you stay looped into Basecamp without having to tap each notification. Stay updated at your own pace.

🖼 Bonus: Swipe Through Multiple Images

We also updated our image viewer to know if a Message or Comment has multiple images. Now you can swipe back and forth between images! If there’s a caption we show that too.

We hope you like these improvements to the Basecamp 3 Android app (Version 3.9.1, updated May 1, 2018). We have a lot more planned and thanks for being a Basecamp customer—especially if you have an Android device!

Thanks for reading. If you have any questions about Basecamp 3 for Android please let us know.

Last summer, my little corner of the Internet blew up with a post on Ask A Manager, a workplace advice column by Alison Green. The letter writer said that 10 years ago, he’d ghosted on his girlfriend of three years. While she was visiting her family, he moved out—not just of the home they shared together, but of the entire country—without so much as a Post-It note. And then, as karma would have it, he learned that his ex-girlfriend was about to become his new boss. Oof. Alison responded with her trademark thoughtfulness and honesty:

I don’t know that you can salvage this! It’s not reasonable to ask Sylvia to manage someone who she has this history with. You can try and see what her take on it is, but I’d be prepared to have to move on, whatever that might look like for you. I get that it’s going to be inconvenient — maybe even quite hard — but there may not be an alternative here.

I got hooked on Ask A Manager with this post, but I’m a relative latecomer to the party. Alison’s been dispensing workplace wisdom for a decade now and today she launches a new book that provides practical advice for how to talk to managers, employees, and coworkers about a huge range of topics, from asking for raises or promotions to handling awkward social situations at the office. On the latest episode of Rework, I interview Alison about how she became an advice columnist, how she’s cultivated a community of surprisingly nice commenters, memorable letters (like the ghosting ex), and more.

Ask A Manager was originally published in Signal v. Noise on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]>https://m.signalvnoise.com/ask-a-manager-9c04be864e8?source=rss----668e14b18fb1---4http://feedproxy.google.com/~r/37signals/beMH/~3/9uTEHMwRmIM/the-little-trade-offs-7b31043b8584
https://medium.com/p/7b31043b8584Wed, 25 Apr 2018 15:23:13 GMT2018-04-25T15:23:13.365ZWhat seems small to you, as a leader, is not small to your team.

I was running a leadership training a few months ago, when a CEO said this to me…

“I think I know why it’s so easy to become a bad manager, even when we don’t mean to be: It’s because of the little trade-offs.”

I nodded and smiled. I knew exactly what he meant by “the little trade-offs.” I’d made so many myself as a leader, across my own career.

The little trade-offs are the moments when we succumb to what feels most pressing in front of us, at the expense of what our company needs down the road to be successful. We swap “The Thing That Will Help The Team in the Long-Run” for “The Thing That Needs To Be Done Right Now.”

As a leader, we make a dozen of these little trade-offs every week (if not every day!) We negotiate in our heads: “I need to finish this critical project, so I’ll postpone my one-on-one meeting with this employee. We can talk next quarter.” Or, “I need to be heads down on selling to this new client, so I don’t have time to explain the recent company changes. We can announce them later.”

“Next quarter.” “Later.”

In the moment, the little trade-off seems like the right one make. Executing on “The Thing That Needs To Be Done Right Now” feels like the top priority. It’s what will pay the most dividends. And when it’s such a little trade-off, how much does it really matter?

Well, here’s the rub: Little trade-offs are not so little. You might make just one or two, in the beginning. But when you’re stressed, busy, and operating on tight timelines, the frequency of those little trade-offs inevitably increases. The little trade-offs you make as a leader become big trade-offs over time.

Consider these seemingly “little” trade-offs:

You choose to respond to an investor’s message within 24 hours — but don’t respond to a team members’ email or message for days (or weeks) on end.

You choose to be out on the road marketing the company’s new vision to potential customers — but don’t take the time to communicate the vision to the rest of the company.

You choose to actively ask a client for feedback and how your product can improve — but are always late to deliver an employee surveys or hold one-on-ones to solicit feedback on how the company can improve.

These little trade-offs say: “I value investors over my team. I value my potential customers over my team. I value my current customers over my team.” These are not little trade-offs. They’re big.

Over time, the little trade-offs reveal your true preferences as a leader and the basic underlying assumptions you hold. It becomes clear who and what really has a hold on you, and where your interest lies. For your team, the little trade-offs you make speaks volumes to them, more than any stirring inspirational speech or pay increase you give. It’s the little trade-offs that they’ll most remember.

No wonder it’s so easy to become a bad manager. Our little trade-offs pile up. Rather than being the exception, they become the rule.

How many more little trade-offs are you willing to make?

PS: If you found this article helpful, please click the 👏 below so others can find it! And please say hi at @cjlew23 — I always love meeting new people.)

It used to be a fundamental requirement that you learned an extensive amount of SQL before you were able to start working on database-backed applications. It was taken as self-evident that you needed to speak the native language of the database before you were qualified to use it. And better yet, you really ought to understand and care about your particular brand of database engine.

This is no longer so. That fact has snuck up upon us, but it’s none the less true — and that’s amazing.

Through advances in leaky abstractions, we’ve managed to compress the conceptual overhead of the database so much that it needn’t feature in the introduction material for making database-backed applications. In Rails, we call that abstraction Active Record, and it falls into the category of object-relational mappers (ORM).

The ORM was long derided by programmers as an unreliable, even harmful, aid of the lazy or the weak. Something Real Programmers shouldn’t expect to lean on, as it was likely to break down if not immediately, then certainly soon thereafter. And then you’d better know all your relational theory!

That’s the past.

Basecamp 3 has about 42,000 lines of code, and not a single fully formed SQL statement as part of application logic! It serves millions of people. It not only leans on the ORM abstraction, it hardly even thinks about it the vast majority of the time.

Do you know what else application programmers rarely need to think about any more either? Memory management and garbage collection. It used to be just as foundational to know your pointers, your destructors, your mallocs, and all the other conceptual overhead needed to deal with manually managing memory. Now it isn’t.

Our abstraction of SQL isn’t quite yet to the point of our abstraction of memory management, and certain frameworks and environments are further ahead than others, but it’s getting closer. The first version of Basecamp had a bunch of #find_by_sql calls, the latest have none. That’s progress.

It’s not that knowledge of SQL isn’t nice to have. It’s good to know a lot of things. Just like it’s helpful to have a strong conceptual model of how computers deal with memory management. It’s just that you no longer need to know these things to start making applications, and that’s a wonderful thing.

SQL, like memory management, is a concept you can unpack when you need to. Further down the line of your career. Then after you learn it, you can compress it back down again and spend more of your mental capacity on other things most of the time. I used to write SQL statements every day. Now maybe I do so once a month? Less? And that’s against a major application that’s reached a scale that most beginner apps never will.

Some programmers will scoff at this notion instinctively. That it’s simply irresponsible for programmers to start writing code until they know these historical fundamentals. I suppose it’s natural to think that all the hard work you spent learning the basic concepts — that indeed were required when you got started — should still be taught to all on day one. This is one of the key pitfalls of experience. Falling in love with the trials and tribulations you had to suffer, rather than rejoicing in the fact that the next generation doesn’t have to endure them.

The relational database is a glorious invention, but for most programmers it doesn’t need to be more than an appliance. Sure, take the time to learn how the drying tumbler machine works, it may well save you a service call to a specialized technician one day. But it’s hardly a requirement for living with such a device and getting your clothes dry.

The relegation to “appliance status” isn’t a dig, but an honor. It means we’ve finally made the technology and the abstraction so good that many, if not most, programmers don’t even have to think about it on a daily basis.

It also means it’s become a commodity. At Basecamp we happen to use MySQL, but to be honest, it’s basically only for historical and operational reasons. We could switch to PostgreSQL tomorrow, and I wouldn’t really give a damn. We have nothing in the application that relies on a particular brand of the database appliance.

Building stuff with computers means building on top of abstractions. CPUs, 1s and 0s, assembler, C compilers, database drivers, memory management, and a million other concepts are required to make our applications work. But as we progress as an industry, fewer people need to know all of them, and thank heavens for that.

It takes hard work to improve the conceptual compression algorithms that alleviate application programmers from having to worry about the underpinnings most of the time, but it’s incredibly rewarding work. The more effectively we compress the concepts of yesterday, the lower the barriers to entry become. And we need low barriers if we are to get more people started making applications.

SQL is perhaps the brightest example of conceptual compression over the past decade or so, but application work is full of other examples. And we need such conceptual compression more than ever to starve off specialization, and to preserve the power of individual generalists to make complete applications.

We’re currently living through an explosion of conceptual expansion and experimentation on the client-side in the web application world. That’s really exciting! Lots of new ideas and approaches churning rapidly. But it’s also needlessly intimidating in many ways. We don’t all need to spend hours or days learning how to configure build pipelines. Some day our leaky abstractions will be good enough that the conceptual compression will relegate such tooling to appliance status as well. That will be a good day.

You can’t learn everything. You can’t hold every concept fully expanded in your head. And moreover, you shouldn’t. As we compress formerly fundamental concepts, we make room for new, grander abstractions. These are the leaps of progress it’ll take to continue to make us more efficient and ultimately more effective.

But I get that it’s hard to break habits. Like the stereotype of an old person complaining about the price of gas or a gallon of milk because their frame of reference is anchored in a time past. Broad-based progress sometimes need that generational churn to really happen (and that’s not about your physical age, rather the years of experience).

Don’t be a fogey. Don’t fight the conceptual compression. Help make it happen.

]]>https://m.signalvnoise.com/conceptual-compression-means-beginners-dont-need-to-know-sql-hallelujah-661c1eaed983?source=rss----668e14b18fb1---4http://feedproxy.google.com/~r/37signals/beMH/~3/pMrwW-gUC70/introducing-boosts-an-all-new-way-to-show-your-support-in-basecamp-fae325634998
https://medium.com/p/fae325634998Tue, 17 Apr 2018 19:35:15 GMT2018-04-17T20:53:30.680ZWe gave up on Likes and invented a totally new form of tiny communication.

If there’s one thing you can’t avoid on the Internet, it’s Likes. They’re in nearly every software platform where people post photos or write text messages.

Sometimes Likes are called Faves, Hearts, Reactions, Claps, or something else, but the basic idea is the same: they’re a small, quick way to express your feelings about something, usually accompanied by a count of other people who had that same feeling.

Until today, we had exactly this sort of feature in Basecamp 3. We called it Applause. If you liked a post, you’d clap for it. Everyone who clapped was shown in a row.

Basecamp’s applause feature.

This was fine, of course—it worked just like all the other Likes.

But a couple months ago, we started thinking more deeply about this pattern, and we noticed it has a lot of insidious problems.

Likes are vague, especially in a professional setting. Let’s say your boss liked someone else’s post, and not yours. You might start questioning what happened. Was she just busy and not paying full attention to everything? Or did she do that intentionally? What does it all mean!? There’s no way to know, because there’s not enough information — just a bunch of digital grunting.

Likes are obligatory. How many times have you felt obligated to SMASH THE LIKE BUTTON because you didn’t want to seem like a jerk, or because everyone else was liking something? There’s a subtle peer pressure and herd mentality hiding behind those thumbs up.

Likes are vanity metrics. Whenever you post something to a social network, do you obsessively check to see how it was received? That’s because those little Like counts are a drug for your brain: you get a dopamine rush by observing your own mini-popularity contest. It’s a psychological trick to keep you coming back for more.

Likes are thoughtless. Has there ever been a more mindless form of communication than merely tapping a button? Liking something requires almost no effort or consideration whatsoever. Here’s what you’re really saying: “Thank you for spending your precious time posting this. In return, I have clicked a button. It took me less than one second. Bye.”

Likes are canned. In most apps you have to pick from a predefined set of acceptable symbols (or in Basecamp’s case, just clapping.) That’s not great for addressing the infinite range of nuanced human emotions, and it’s also totally impersonal. Why should some software company decide which 3 emotions you’re allowed to have?

Now, it’s not all bad. There are some good things about Likes too:

Sharing support for others is wonderful. We want to encourage that, of course!

It’s nice to respond to something without making a fuss. You might not have much to say, but you still want to let someone know you appreciated their ideas. Notifying a bunch of other people on a thread merely to say “good job!” is overkill.

It’s helpful to know that people saw your posts. When you see that 10 people liked your post, you’ll know they received it and thought about it (at least a little.)

With all of these ideas in mind, we went back to the drawing board and came up with a fresh new approach that’s never been done before. We’re calling it Boosts, and it’s way better than all of those crummy digital grunts.

Here’s how you boost something in Basecamp.

In various places in Basecamp, you’ll see a new rocket icon:

Boost button!

Click that, and it’ll morph into a small text field.

A field in which to boost

You’ll notice there are no predetermined options or smiley face buttons to choose from. That’s on purpose. You have to make it up yourself!

Add some emoji or write a tiny text note, up to 16 charactersmax. Then click the green check mark to save your boost (or the red X to cancel.)

You can add more than one boost if you want, and they’ll collect into a little bundle like so:

Boosting twice

Your boosts won’t notify anyone other than the original poster. So if you’re on a comment thread with 10 other people and you boost Dave, only Dave will get a notification about it. This is in contrast to comments, which send a notification to everyone on the thread. So if you just want to say “Great job!” or “I agree” or “👍”, but you don’t want to bug everyone with a notification, boosts are best!

If you messed up making a boost, click on it and a trash icon will appear. Click the trash to delete it. (If you’re an admin, you can delete anyone’s boosts in the same way.)

Deleting a boost

After a lot of people have boosted someone, you’ll see a sweet block of small supportive comments, where everyone’s message is totally unique! There are no vanity counts or anything like that.

Here’s how it looked when I announced that we’d be launching Boosts:

A block o’ boosts

Other times, boosts work like a silly mini-conversation.

lol juice boosts

When you’ve received some boosts, you’ll get notified about them every 3 hours as long as there’s something new to report—otherwise Basecamp won’t notify you.

Why every 3 hours? We think it’s the perfect amount of time: infrequent enough that you won’t be bombarded about little responses, but frequent enough that you won’t miss anything for too long.

When you click on that notification, you’ll see all your boosts, ordered by date:

You can also unsubscribe from the boosts notifications, if you prefer. Just hit the button in the top-right corner of the page above.

What happened to applause?

Applause is no more (it’s been replaced by Boosts.) But old posts that had applause will still show it—those claps have simply been turned into boosts instead.

Clap Boosts.

So that’s Boosts — we hope you like them! (Pun intended)

We’ve been using boosts for over a month, and we’ve found them to be a much richer form of communication than our primitive old applause system. They’re far more contextual, freeform, and creative: perfect for posting short, thoughtful responses.

After a few days, you’ll notice you won’t feel obligated to boost something unless you genuinely have something to say. Boosts are far less susceptible to vague interpretations, since every little boost is unique to the conversation at hand. And with no buttons to smash, there’s no more mindless button smashing!

Give boosts a try and let us know what you think. We’d love to hear from you on Twitter or in the comments on this post.

🚀🚀🚀

New to Basecamp and want to see what it’s all about? Sign up for a 30 day free trial over yonder.

This morning something happened that reminded me of an important lesson re: time well spent.

Three of us are working on an illustration project for our forthcoming book, “It Doesn’t Have to be Crazy at Work”. In our previous books, we had an illustration per essay. This time we’re going in a different direction. Rather than an illustration per essay, we’re aiming for ~15 full page spreads spaced evenly throughout the book.

We’re going to be illustrating historical and contemporary figures with work methods that line up with our point of view on work. People who’ve done big important things without pulling all nighters, working crazy hours, or forgoing leisure for the eternal hustle.

Here’s an early example of a spread:

We like the direction, and so does our publisher. We’re going for it. So now we’re off to find interesting subjects to illustrate and feature. It’s research time. That means there’s going to be some design downtime — a gap in the project for the designers.

Now, back to what happened this morning… The designer leading the layout charge offered to continue to explore layout concepts while we look for more subjects to feature. He wanted to tweak the layout on the right, add some more details to fill out the space, etc. We’re happy with it, but could we be even happier with it? The tweak muscle yearns to be flexed!

That’s a perfectly natural reaction. Certainly there’s always room for improvement. And there is always more to explore. Always.

Always is the problem.

The always option is where you turn time well spent into time wasted. That time could be used on other projects that need attention, rather than projects that desire attention. The layout above is perfectly fine — it doesn’t need tweaking now. The designer may desire to tweak, because designers love to design! There’s a tendency to keep pushing the thing you’re on because you’re already in the middle of it. Natural. But it’s on us to inject a sense of enough so we don’t sink good time into something that doesn’t need it. Going from 99% to 100% is expensive. I’d rather we spend that 1% going from 0% nothing to 1% something (or 50% on the fence to 51% conviction) on something else.

So I gently reminded him that we’re all good here. He did great work, the layout looks great, and there’s even a risk of fucking up a good thing (it’s always easier to fuck up a good thing than to fix a bad thing). There’s more to do elsewhere, and his time would be better spent on those things.

He agreed. We’ll come back to the layouts once we have new subjects to illustrate and design. And maybe then we’ll see a different way forward once we have more examples in front of us. Now isn’t the right time to continue to tweak. Let’s wait to see if new ideas pop up via new work that has to be done rather than revisiting what we’ve already done.

Mind the gap was originally published in Signal v. Noise on Medium, where people are continuing the conversation by highlighting and responding to this story.

In 2014, Highrise was spun off as a separate (but wholly-owned) company from Basecamp. Last year it celebrated its tenth anniversary in business. And this year it’s moving back in with Basecamp.

In some ways, it’s like it never left. While Highrise operated as an independent company under Nathan Kontny as CEO, Basecamp’s technical operations team continued to run servers and systems. Our support team still has a lot of people who used to answer customers when Highrise was a direct part of our suite of products. And almost all the members of the original product team for Highrise are still with Basecamp.

In other ways, this is indeed a change. Nathan Kontny had built a team of seven to lead new development, and they made a lot of improvements over the years. We want to thank the team for all their work and wish them all the very best.

Spinning Highrise off into a separate company with a separate team and CEO was always a bit of an experiment. While that experiment had a bunch of highlights, we ultimate decided it was time to try something different on both the product and business side after a thorough review was conducted some time ago.

For customers of Highrise, we at Basecamp are committed to supporting the product until the end of the internet! Highrise is home to over 10,000 customers who’ve trusted their data and their business to us. We are grateful for the trust and will continue to operate Highrise to the same high standards as Basecamp.

In short, this transition back to the Basecamp team is going to be nearly invisible to Highrise customers. Highrise is returning to the team that originally built the software, and it’s being operated on the technical side by the same team that always did so.

We’ve also begun exploring a range of new directions for the product’s future. We’re not yet ready to share where this is going, but will do so as soon as there’s a final path set.

Thank you to all our Highrise customers whether you’ve been with us for 10 days or 10 years! ❤️

Find your ideal design process by sticking to a few simple principles instead of a rigid script.

You hear a ton of different advice on the right and wrong way to go about designing an app or website.

“You should be using Sketch.”“Design Systems or GTFO.”“Real Designers design 100% in code.”“Wireframes are a waste of time.”“If you’re not making prototypes, you’re not doing it right.”“You need to start on paper.”

You’d think there’s no agreement whatsoever about the right way to design, but there’s one point that’s largely free of controversy — that your process should be linear.

It’s kind of like those Rube Goldberg-esque manufacturing machines they use to make Doritos and Ding-Dongs. Drop an idea into the process machine, and after getting mashed and molded into shape as it winds through the steps a finished product pops out the other side! Predictable! Efficient!

Kind of.

Process machines work, but only when they work. They don’t adapt, and that makes them fragile. All it takes is one little Sabot to grind your process machine to a halt.

Hank, a.k.a. “the Sabot”

I’ve been watching Finding Dory with my kid lately, and part of the “making of” footage keeps jumping out at me.

In the movie, there’s this octopus named Hank:

Disney/Pixar

Septopus, technically. His character model was so onerous to work with, they lopped off a tentacle to make animating him doable. Still, with 4,000 separate controls he was incredibly challenging to work with.

At this point in the process, they’re well past sketches and renderings and animatics — those lower fidelity stages that help you vet a bunch of ideas quickly and cheaply. They already Got Real too. The character rig was built, technical details worked out, fundamental questions answered.

They’re in the final animation stage — 3D models in 3D environments. They could have soldiered on at the expense of the production schedule and budget. Instead, they did something really interesting — they went back to sketching.

Disney/Pixar

By sketching out the complex movement of Hank’s tentacles on paper, they could nail down the perfect, fluid animation they were looking for in a fraction of the time. Once they were happy with the sequence, they’d animate in 3D to match. They got a better product in less time because they chose to value process principles instead of a process prescription.

The cure for a prescriptive process

The Finding Dory team made a better product faster by making decisions that prioritized speed and quality instead of sticking to a rote process.

You might choose other things to value, but if you’re working in a commercial setting, focusing on the sweet spot between speed and quality should be at the top of your list. Turning around great work quickly is kind of a big deal for professional designers and artists after all.

Defining the principles that drive your process is just the beginning. Here’s how you can put them into practice.

Start with the big questions

If you value speed, start a project by figuring out what the biggest, most fundamental questions are. In Getting Real, this is called “epicenter design”:

Start from the core of the page and build outward

Epicenter design focuses on the true essence of the page — the epicenter — and then builds outward. This means that, at the start, you ignore the extremities: the navigation/tabs, footer, colors, sidebar, logo, etc. Instead, you start at the epicenter and design the most important piece of content first.

Whatever the page absolutely can’t live without is the epicen- ter. For example, if you’re designing a page that displays a blog post, the blog post itself is the epicenter. Not the categories in the sidebar, not the header at the top, not the comment form at the bottom, but the actual blog post unit. Without the blog post unit, the page isn’t a blog post.

Only when that unit is complete would you begin to think about the second most critical element on the page. Then after the second most critical element, you’d move on to the third, and so on. That’s epicenter design.

Epicenter design eschews the tradtional “let’s build the frame then drop the content in” model. In that process, the page shape is built, then the nav is included, then the marketing “stuff” is inserted, and then, finally, the core functionality, the actual purpose of the page, is poured in to whatever space remains. It’s a backwards process that takes what should be the top priority and saves it for the end.

Here’s an example of why this is crucial. I was working on a little side project iOS app that used a unique, possibly unworkable audio interface. If I didn’t value speed, I could have spent countless hours designing the myriad details that rested on the foundation of this one oddball idea. Design comes before code in the classic linear process, after all.

Instead, I started in code to figure out whether or not this idea was viable. It wasn’t! So I adjusted my plans, and saved myself an enormous amount of time and energy.

Just ask, WMGMTCATMQITLAOT?

Once you know the questions that need answers first, ask yourself: “Which medium gives me the clearest answer to my questions in the least amount of time?”

In the case of my side project, the answer was code. For a page on Basecamp.com, the answer is often text or a sketch. For you, it might be something else entirely.

Knowing when to change gears

That gives you a place to start, but how do you know when it’s time to switch to a different medium? When you hit resistance.

Think about driving a car. You’re cruising down the highway — engine purring away like a contented kitten. But then you start driving up a hill. The gear you’re in was great for cruising, but not for hill climbing. In order to keep up your speed, you shift into a new gear.

Same thing here. But unlike cars, there’s no rock solid indicator that you’ve hit too much resistance in your medium of choice. Luckily, most designers and artists have a solid handle on when you need to switch to a medium that offers more fidelity. This is the part that lines up with the classic low fidelity → high fidelity linear process after all. You know you’re ready to move on from sketching when sketching stops giving you useful insight.

Once you’ve hit this point, figure out the next most important set of questions and ask yourself again: “which medium gives me the clearest answer to my questions in the least amount of time?”

The second case — shifting back to a lower fidelity — is tougher. Both because people are less practiced at it, and also because it’s tricky. Take working in code. You’re working at 100% fidelity, so there’s no limit to the medium’s ability to answer questions. But there is a limit to its ability to answer questions fast.

When you feel yourself not pursuing paths because it feels like too much work, that’s a really good sign that you need to back out. When things feel like they just aren’t clicking like they should, it’s time to reassess. Be mindful, and you’ll start to develop a feel for it.

Using a medium to your advantage

There’s a third case for switching to — or sticking with— a medium. This one doesn’t care about resistance, it only cares about a fundamental truth; process influences outcome. Just like drawing something with a pencil is going to look different than drawing it with a marker, designing in browser is going to produce an different outcome than designing in Sketch.

The more you understand how a medium affects your work — the kind of tool marks it leaves — the more you can use it to your advantage. Want your design to be expressive? Probably better to work with a visual tool like Sketch, Illustrator, or even *gasp* Photoshop. Want a minimal, lightweight design? Stick to designing in code.

A practical example

Now that I’ve railed on about the perils of prescriptive process, I’d like to share with you… my process. Not for you to follow step-by-step! Just to give you a real life example of how you can use principles to guide your process.

We’re launching a new way to work with clients in Basecamp, and my job was to create a new page on Basecamp.com to market it. Here’s how it played out:

Determining big questions, picking a medium

This isn’t a new site, or a wholly new layout. First, I needed to figure out the purpose of this page, what it’s trying to say, and the overall structure.

“Which medium gives me the clearest answer to my questions in the least amount of time?”

Comps and sketching are out. This is slotting into an existing design and an existing template. I could jump straight to code, but the markup is noise at this point. Text is just right.

A bunch of half-baked copy

Increasing fidelity

I didn’t stick with text long enough to finish all the copy for the page. Once I had an outline and a sense of how I wanted to talk about the feature, I shifted gears into code.

Why?

A text doc couldn’t tell me anything about whether a line would leave a widow, whether a paragraph “felt” long, how the images would flow, etc. I needed more fidelity. Some of the new questions could have been answered by a static comp, but that wouldn’t have answered questions about copy fit unless I wasted time matching the comp exactly to code. No thanks.

Working through copy edits in code

Selectively decreasing fidelity

After a few more rounds of copy revisions, the page was starting to take shape. Visually, it was mechanical and underwhelming. I wanted it to be more expressive, so I switched over to Sketch to riff on some ideas.

I could have stayed in code for the most part, but with Sketch I could fire off a bunch of ideas much faster than I could code them. It also let me directly compare those ideas against each other, and wouldn’t leave a CSS rat’s nest from all the churn. Win-win-win.

A bunch of half-baked Sketch comps

Notice how none of them are fully baked? It’s because they don’t matter! These aren’t for a client presentation or for developer handoff. They’re there to help me figure something out, then they’re trash. Investing time to polish them would have been a total waste of effort.

This isn’t how every project plays out. Sometimes I’ll sketch something in Procreate, sometimes I’ll start with a quick and dirty visual comp, sometimes I’ll write copy in Sketch, sometimes I’ll work 100% in code. It all depends on the project at hand.

Hopefully that gives you some insight into how you can use principles to guide your process on case-by-case without feeling like you’re constantly reinventing the wheel.

Think about your process and the kind of work that you do. Define the principles that are important to you, focus on the big stuff first, and keep questioning if the medium you’re working in is the right one for the moment. Your work will be better for it.