Journal

Design, Technology and Work

Design process

March 22nd 2016

Process has been on my mind a lot this last year; changing jobs and starting side projects are perfect opportunities to compare and contrast different teams and working cultures. This piece by Lopp captures beautifully one of the main challenges I've seen while joining a new (and especially-large) company.

“You can either blindly follow the bulleted lists or you can ask why. They’re going to ignore you the first time you ask, the second time, too. The seventh time you will be labeled a troublemaker and you will run the risk of being uninvited to meetings, but I say keep asking why.”

I'm still navigating this path. It's hard to ask why and to challenge the status quo.

One thing I've started doing recently is blocking off at least three 4-hour blocks of time per week to go deep on production. I'm finding this to be not only a period of high output and productivity, but it also seems to align my own goals with the rest of the team's. It forces me to cluster meetings towards one side of the day, and usually towards one side of the week. The result? Less interruption, better work, happier teammates.

“Insist on understanding because a healthy process that can’t defend itself is a sign that you’ve forgotten what you believe.”
Share
Community

April 8th 2016

The design community deserves better than this.

I remember when DN was a rad little site that was growing slowly and everyone just...got along. We shared cool articles and stories, talked about what was happening in the industry and generally acted like normal, decent people.

But something broke along the way. This 'Men of Designer News' post is the coup de grâce in my mind. I'm disheartened to see a place that so many people once loved turn into a place where women and people of color don't feel safe and don't feel welcomed to join the conversation.

So we're building something better.

First, context: The Spec community has been growing like crazy over the past year. Our Slack team has over 4,000 people talking about what's new in design and development, sharing job opportunities, talking about tools and techniques, and generally helping each other level-up.

But at 4,000+ people, Slack also starts to break down. Conversations get messy, it becomes daunting to jump into a conversation-in-progress, and maintaining a history of discourse is nearly impossible.

That's why we're working on a replacement - and we're calling it Spectrum. Our goal is to build a place for people of all backgrounds and all job descriptions to connect and talk and help each other grow. The name Spectrum not only captures the kinds of content we want to share - from technology to design to development and more - but it also captures the kind of community we want to build: one that is inclusive of all genders, races, backgrounds, experience levels, and locations.

It's not going to be an easy problem to solve, but we believe it's the right problem to solve.

If you want to be notified whenever we have progress on Spectrum, you can get email updates or follow us on Twitter @specfm.

iPhone SE

March 21st 2016

A good design process accounts for any screen size. Not breakpoint-based-design, but true responsive design. However, I have to admit that for the past year all of my artboards in Sketch were sized for the iPhone 6. Screens have been trending larger and larger for nearly a decade, so it was relatively safe bet to anticipate the extra screen real estate.

After today's announcement, I'll be switching back to a smaller default artboard that will be more representative of a 4-inch screen.

Not only does this make sense from a user experience perspective (hey, your design will be optimized for emerging markets!), but also it makes sense from a practical process point of view. Scaling a design up one inch is infinitely easier than scaling down by the same amount.

Product Design Portfolio Examples

September 23rd 2016

In the last few months I've had emails from folks looking for advice on product design portfolios, how to structure case studies, how to describe a design process, etc. I thought it might be helpful to start compiling a list of some great ones, as a reference for anyone in the future:

Let me know if I've missed any!

Information Addicts

September 29th 2016

The users weren’t fully aware of how addicted they were. They thought they picked up their phones half as much as they actually did. But whether they were aware of it or not, a new technology had seized control of around one-third of these young adults’ waking hours.

It took me over a week to finally find a distraction-free time to read this article. I disagree with some of it, agree with most. Finding a quiet moment is rare these days, constantly tempted by Twitter or Reddit or Facebook or Instagram. This isn't noteworthy for anyone who reads this, I imagine; it's ordinary.

Leveling Up

September 30th 2016

Show me your bookshelf, or the courses you take, or the questions you ask, and I'll have a hint as to how much you care about levelling up.

This idea pairs well beautifully with an earlier post this week, Investing for Geeks:

I’d be remiss if I didn’t mention that most people in the tech industry have one asset which is orders of magnitude larger than all their others: the present value of their future career.

Reading the right books can be a cheat code to leveling up in unexpected ways and in entirely new fields. And they don't have to be dry business-y or design-y books; some of my favorites this year were Ready Player One (sci-fi), Replay (sci-fi), Sapiens (anthropology), and Thinking, Fast and Slow (psychology).

Discourse

April 5th 2016

A few things I noticed on Twitter over the past 72 hours:

  • People taking cheap jabs at others for having the "designers-coders" debate. It's become a meme at this point despite the fact that there is still strong disagreement among design leaders. This indicates a need for deeper understanding and community discussion to evolve our thinking. When younger designers see leadership-level designers dismissing the entire argument then they too will be more prone to dismiss it without fully understanding the history and complexity of the subject.
  • Anti-coding sentiment for the sake of being pro-design. These are not, and never were, mutually exclusive. If you don't think that designers need to code, please don't say that they shouldn't code. Designers should learn everything they possibly can to better understand the discipline and be better at their craft; code is one such tool that will help them level up in a way that most other tools won't.
  • We have not built a healthy way to talk about nuanced topics as a design community. The "designers should code" debate isn't solved. It's an evolving discussion that will likely continue in perpetuity as our tools and technologies change. Let's embrace that and build a culture of support, not snark. Let's give designers context and understanding, not cheap one-liners meant to paint the argument as a binary win or lose dialogue.

I love this community. Let's please just be better and support each other and spend time thinking about what kind of standards for discourse are being set on Twitter and elsewhere.

Writing for Beginners

August 22nd 2016

So what if, instead of thinking about writing as a way to transfer knowledge from one brain to the next, we thought about it as a way to build understanding? First, in ourselves, in our minds...

This pretty-well sums up the reason I've been writing on this page for the last five months, almost every day. It has made me more critical of the things I read. And when I come across something particularly thought-provoking or insightful, I use this space to explore my own thoughts and try to build understanding. That alone is valuable to me, enough so that spending time building this site and forcing myself into a daily routine becomes trivial.

The reason I hit 'publish' at the end of this process is simply to overcome the fear of shipping work.

Q&A

May 2nd 2016

I've got a lot of love for what Dann is doing with his video series. Anything that can inspire people or bring the community closer together is 💯 in my books. Thanks Dann for letting me say things into your camera and for letting the world finally meet the one-and-only Taco.

Sidebar: you don't fully realize your own quirks and mannerisms until you have both seen yourself on video and heard your voice recorded. I highly recommend both, no matter how uncomfortable.

Anyways. Super fun to hang with Dann – I hope it was fun to watch! Here's some more Q&A that didn't make it in.

Hardest thing is definitely the fear of: judgement, sounding dumb, being wrong, coming across as self-promote-y or any other thing that the voice in the back of your head shouts whenever you think of doing something new. If you put out a lot of work you'll inevitably say or do something stupid or annoying or silly. I've embraced it. Who really cares?

If I had to choose between shipping a lot of things and being wrong or looking dumb, versus shipping nothing and never quieting that voice in my head...well, the decision seems clear. Ideally I'll get better over time.

The best thing: when someone tells you that your work was inspiring, or encouraged them to do something new, or motivated them to move across the country. The Design Details Podcast has been amazing in this regard; the people who have reached out saying that the show helped them realize they wanted to be a designer, or inspired them to move to SF, or helped them land a dream job – that makes every hour of work worth it to me.

Tomorrow. See ya at the studio, buddy.

That's paradoxical question. If I've never done anything mean in my life, it's impossible to have a meanest thing. Truth.

🤔

The moon. Fingers crossed for Elon to make this a possibility in our lifetime...

For the most part, yes – people are generally awesome and generally willing to help anyone that needs it. Of course there's always more we could be doing; I think that design education and building better tracks for junior designers to get their first job (and actually be successful in that job) could be better.

Bryn and I talk often about what it would look like to take a new designer from 0 to 1 as fast as possible: learning the basics, the objective truths, the core principles of design. The better and faster we can transfer that knowledge to the next generation of designers, the faster they can land their first design job and start working on the problems that need solving. That is an exciting area to me.

Talk to people who experience that problem. Get feedback on product decisions early. Find people you trust to give you honest critique. Create space to move vertically and horizontally through possible solutions. Ruthlessly eliminate and prioritize those possibilities. Ship and learn.

I realize in the video I said rockstar because it was the first thing that came to mind. In hindsight that was a terrible answer.

I think Taco (the pup) would be a very suitable, if not exceptional, taco (the food) designer. His attention to detail is unmatched and his appreciation for fine meats is paramount.

There was a point where I just needed to work with a team of designers so badly. I needed to learn more and get better and learn about process, shipping at scale, user research, craft, etc. Facebook felt (and still feels) like one of those rare places where you can learn about all of these things in a structured, supportive environment surrounded by a crazy amount of talented people. So it's been a blast; I'm so fortunate and thankful.

There's an answer to this in Dann's video, although I'm not sure it's super helpful. Everything is hard to ship in one way or another, whether it's because of the significance of the desired outcomes or just the fear of sharing something that you care about.

I've found that surrounding myself with people who know how to turn this fear into productive momentum has been incredibly inspiring and made me realize that most people still feel the fear of shipping. People like Dann Petty who ships Epicurrence and his videos, or Bryn Jackson who is writing guides to help designers level up – being around this kind of energy every single day has been the single-best thing to help me grow and motivate me to be better.

Why not both?

Eating. Sleeping. Generally staring at computer screens. Supremely boring.

I try to write every morning, read every night, exercise a few days per week to keep balanced. Right now I'm really trying to get better at development, digging deeper into Javascript and frameworks like React.

Mostly Design Details and Spec. And this website, too!

Thanks again Dann – everyone should subscribe to his videos on YouTube!

Becoming designers

March 25th 2016

Last night we had a great chat with Dylan Field on Design Details (episode will be released next Wednesday) where we came across a topic that is as open-ended as it is exciting. I'll try my best to unpack it...

When I look back at the past ~115+ conversations we've had on Design Details, plus the wealth of chats with friends and just generally having paid attention to the design community, there is a common trend of folks being interested in computers/technology/code long before they realized that design is a thing.† If you reflect on your own personal story, perhaps this rings true; I know it does for me.

Usually the story starts with the momentous day that you clicked View Source. And from there you built small side websites, dove into freelance web dev, and only then began to discover the intricacies and complexities of design as a mechanism to solve problems. And then, as I was, you're hooked forever...

So Dylan got us wondering: what does the future look like where kids learn about design from a young age first? A future where young people admire the design craft and process long before they realize that coding and programming are things? What does a primary school system of the future look like where type and hierarchy and usability are taught and esteemed to the same degree as functions and objects and methods?

As design become more valued, taught, accepted and understood within organizations, perhaps we'll start to soon hear more stories about design being a person's first interest, which only then led to a deeper fascination in computers and technology and programming.*

† Of course, this isn't the only way people become designers

* Some people out there went down this path; it's just not common

Design systems

September 15th 2016

This was a turbulent thread yesterday about design systems versus style guides. The waters are still murky in terms of how we've defined these terms, and how designers are talking about systems in their day-to-day work.

After consulting Twitter, here are a few more resources/people to follow in order to learn more about design systems:

A design system is more than just a presentational layer for how things look. It's more than a bunch of buttons and grids. And it's definitely not a Sketch mastersheet.

For the past few months these concepts have been my deepest fascination. I thought about writing my perspectives here, but realized my understanding of the subject is still very rudimentary; I need to build a lot more before being able to articulate anything meaningful.

Also:

Oops.

Multiplayer Design

September 28th 2016

Introducing multiplayer actually reduced the overall complexity of Figma’s UX because it removed all of the awkward workflows that people had been using to work around the lack of multiplayer. The result is a few simple features that combine in powerful ways to provide a great collaborative editing experience.

I'm very curious to see where multiplayer might fit into my design process and where it can be creatively bent to fulfill new purposes (e.g. using it to multiplayer myself on a phone as a mirroring solution).

The Figma team has been building up to this moment for a while now, and I'm excited for their product to keep evolving. A tool with files that are automatically version controlled, are treated as a single source of truth, and that enable online collaboration by default is a huge step forward.

Calculated, not cute

April 1st 2016

Illustration creates an intimacy that communicates sincerity in saying “we’re working on it” or “we understand that this software is your livelihood”. It’s an opportunity to take your user out of a frustrating situation, and lead them back into a positive experience.

It's been fascinating to watch the demand for talented illustrators explode in the past few years. Non-designers have started to care about (and invest in) illustration like never before. They recognize the value that it can bring to a digital product, not only from a user experience level but also from a dollars-and-cents business level.

That's insanely exciting and is a huge opportunity for the illustrators of the world who are interested in tech. And for non-illustrative product designers: don't forget that illos can be one of the most powerful tools in our tool belt of ways to connect with the people who use our products.

Writing CSS

March 23rd 2016

My ability to write "good" CSS has a direct negative correlation to how close I am to finishing a particular task. When a project first kicks off and I have a blank slate it's a chance to do things The Right Way™. Re-usable code, crisp lego blocks for building a complete UI...It always starts off so easy, right?

But when I'm nearing the finish line, getting ready for the deploy, something in my process breaks down; I get lazy, I start to over-specify and over-nest and mix content semantics with visual semantics. Ugh.

I suppose this says something about myself and my process. But at the same time I think it says something about how big of a pain in the ass it is to write "good" CSS.

Adam Morse wrote a really well-articulated view on this issue, which I've attached as a source to this post. I highly recommend that anyone who writes front-end code give it a read.

When I write bad code, it isn’t because I’m not trying to write good code. There are always other forces at work.

The scary thing for me is that I've actually only ever written CSS with a handful of people or as a solo designer. So it haunts me to think about how frustratingly difficult it would be to scale this thing to teams and organizations. So I'm especially thankful for folks like Adam and Dan Eden and Brent Jackson who are fighting the good fight to help everyone in the community learn a better way...

So what does DRY even mean? Because you do have to repeat yourself somewhere! You either repeat yourself in html or in css.

One of the key takeaways from Adam's post is the above quote. If you have to write HTML no matter what, in order to build a new component/page/widget, wouldn't it be nice if you didn't have to write any extra CSS? Tachyons and Bass.css are two tools off the top of my head that encourage this behavior.

And of course the obvious counter-argument is that you're just moving bloat from CSS files to your markup. But I'm starting to think that's okay, despite having grown up learning otherwise. It can be good not only from a performance point of view, but also simply because it's nice to read your markup and have a pretty good guess at how the thing will render on a screen.

The real way to scale css, is to stop writing css.

Lots of great thoughts in Adam's post - give it a read.

One Year

July 20th 2016

Today marks one year since I started my work at Facebook. Some quick thoughts:

  1. It took me a lot longer than I expected to ramp up. This is my second day job, and first at a big tech company – the key challenges in the beginning were around not feeling ownership, not realizing that I didn't need permission for every little thing, and not knowing the right processes to ship ideas. I'm glad those days have passed.
  2. It takes a lot of effort to say "no" to projects and ideas in a thoughtful and articulate way – I'm still not great at this, but hoping to level up here in the next year. The result of learning this the hard way is often feeling stretched too thin or losing important cycles to context switching. Saying "no" more often will be top-of-mind going forward.
  3. Side projects continue to be a source of deep fulfillment. My work at Facebook is fun, and challenging, and I'm lucky to have the opportunity to be a part of a few projects that I hope will be valuable to people. That said, it's projects like Spec and Design Details and writing here every day that keep me energized and focused and happy. That's not to say I'm going anywhere, but rather that I feel fortunate to have found a way to scratch multiple itches, both at the office and at home.
  4. Process is still damn hard. I remember at my last job, a startup where I was the only designer for nearly two years, that process was a daily struggle: we were a remote team, there was more that needed to be done than our team could reasonably ship, and we were still finding our footing in terms of communication tools and workflows. While Facebook is more mature in some regards, I still find that it's still a messy (see: human) process to go from an idea to a strategy, from a tactical plan to a design, and from code to, most importantly, the people we serve around the world. It feels like I've leveled up in the past year, as far as process goes, but in the scope of the game I'm still a noob.

I could devolve further into more platitudes about balance and people and process – but I'll save it. It's been a fun year, I've fulfilled my original goal of "leveling up" by joining Facebook, and I'm excited because I know there is enough room for many more level-ups in the coming year. ✌️

Investing For Geeks

September 27th 2016

I’d be remiss if I didn’t mention that most people in the tech industry have one asset which is orders of magnitude larger than all their others: the present value of their future career.

Patrick's advice is awesome, and is worth understanding if you're new to – or want to get started – investing. The quote above from the last section is a particularly acute way of keeping things in perspective as you approach an investing strategy, especially given the temptation to optimize for marginal increases in return.

Also remember the rule of 72 – the doubling rate of your money (relative to a 7-11% annual return) will be between 7 and 10 years. This means that if you're in your early 20s, anything you invest today essentially gets an extra doubling period before retirement versus someone just starting to invest in their 30s. Think:

$5k invested at 20 years old, given an annual return of ~9%, will double roughly every 8 years.

$10k at 28, $20k at 36, $40k at 44, $80k at 52, $160k at 60.

Play with those numbers accordingly, but never forget the power of compounding interest and the insane value of starting early. Even through high and low markets, the power of dollar-cost averaging means that one of the best things you can do right is to set up a recurring investment in an index, automatically withdrawn from your bank account. This will generally adjust risk in your favor through the inevitably tough years at some point in the future.

Valistration

June 13th 2016

This weekend Jason popped up on Hacker News and I was stopped in my tracks. Hey! That's my idea!

For the past few weeks I've been working on a small app that parses JSON into a UI that can be tested, shared, modified, etc. in the browser. Here's an early demo. The vision was definitely to expand the functionality from building a simple UI in the browser to compiling native components. That would be cool, right?

But Jason did it!

So I tweeted this:

And the responses people sent have given me a better perspective.

  1. Ideas aren't all that unique. Mine isn't, certainly. I bet there are a dozen more apps out there doing similar things that I've just never heard about. So the name of the game is execution.
  2. I wasn't really frustrated, but it does take the wind out of your sails to see someone ship first. You lose a bit of that pressure and drive to ship because, well, someone else kinda solved that thing already. What's the point?
  3. Then I started to ask, what's the point? For me the app was about scratching my own itch, becoming a better programmer and exploring new technologies (React + Redux, whoa!). It was also a pretty intense design exercise, trying to think about UI and the components we interact with as data trees. It was a lot of notes and writing and sketching, with basically no time in imperative design tools like Sketch. That felt liberating.

I'm really excited to see that Jason shipped with a tree very close to where I'd landed, although admittedly much more advanced and customizable. I'd broken my data tree down to the following structure:

  • A view (i.e. the Home Page of your app)
  • A view has properties (i.e. this is an iOS app, or an Android app, or the view is in landscape orientation)
  • A view has a unique ID that can be used to link itself to other views, grab subcomponents from other views (like a modal), etc.
  • A view contains children
  • Children are components, and these components always have: properties, children, actions
  • A child might be something like a table view. This table view has properties, children and actions
  • Each sub-child has its own properties, children and actions
  • For example a sub-child in a table view could be a table cell. This table cell might have properties like small, large, hidden, expanded, etc. – anything, really! It might have its own sub-children, too, like toggles, buttons, links or text. And it also carries its own actions, like: tapping this goes to a view with the unique ID 12345. Or maybe the action is to open a modal. Anything at all!

And the tree continues down forever, components with properties, children and actions. That was the core idea. But then I started thinking, what if I could either encode all of that in a URL or just snag it from an API with URL params to build my UI however I wanted, instantly? Something like dazzle.com/api?id=12345&os=material&orientation=portrait&accessibilityText=on.

Then I could just share that url with an engineer, they could tweak properties and components from a web editor, grab measurements and rules, etc. And then, of course, where Jason shines is taking that data tree (in this case, stored as JSON) and compiling it into native components for a mobile app.

The neat thing is that React plays really well with these concepts by cascading state and props to child components, and then re-rendering components when a parent's state (passed as props) changes. It's a logical way to build an editor that interacts with an infinitely-nested tree of components.

These tools opened my eyes to new concepts like state management in applications, how and when to modify state, when to use state versus props, etc. This led me to explore deeper concepts like Redux and Flux which are used to manage application state. These concepts led me to explore lower-level tools like reducers, pure functions, immutable data structures, virtual DOM diffing and more.

So yeah, it's been a few very fun weeks of intense learning. And there's still so much more.

Probably one of the best outcomes from this project was showing it to designers who I respect and look up to and asking for honest feedback. They pushed me incredibly hard to be better about framing the problems a tool like this might solve, thinking about where it fits into a designer's process, questioning what kind of designer it would provide value to, and more. They pushed me to think philosophically about why a tool like this might exist or be useful for a designer: should designers be constrained to a data tree? Or does the tree have to be abstract enough to parse anything the designer can possibly dream up?

There were friends I showed this to who told me this is something they couldn't envision using. And those are the best kinds of friends. The no-bullshit, honest friends who give feedback that is so crucial when forming early ideas. That feedback (while honest, was also kind-hearted) forced me to rethink problems and framing in totally new ways.

The way I eventually envisioned this tool working was, loosely:

  1. A designer would do their thing in Sketch, Photoshop, whatever. Rapid exploration, divergence and convergence. Iterating and exploring the hell out of whatever problem it is they are trying to solve. Drawing squares and such.
  2. Once a solution is chosen, the designer would move to this tool (Jason, Dazzle, whatever it is) and either a) build their component with React + CSS or b) sit down with an engineer and talk about how that component should work and behave. I dreamed of a closer collaboration with engineers to enforce early thinking about things like accessibility, state, properties and flows.
  3. An engineer would work with the designer to build a React component that would output a UI in the browser for testing and sharing, and would also compile itself to a native component skeleton.

In a way it's not really a design tool, as we might traditionally think. It's more about maintaining libraries of components, screens and flows that can be shared, diffed and maintained better. Imagine: being able to test your design on any screen size without every having to duplicate artboards and nudge dozens of layers!

Perhaps I'm naive about whether this process would ever work. I haven't finished thinking about it yet, and as all early projects go, things are bound to change and become refined over time.

Oh man I'm getting excited about the project all over again.

And that's the point for me. Just learning and exploring and trying to be better. Trying to think abstractly and pragmatically. Trying to understand systems and details at the same time; abstractions and declarations.

No, I'm not really frustrated. If anything Jason (or: {insert app name here} that shipped first) is inspiring. It's a chance to learn from that person and use their ideas and execution to refine my own way of thinking.

Computer Vision Syndrome

June 1st 2016

Studies have indicated 70 percent to 90 percent of people who use computers extensively, whether for work or play, have one or more symptoms of computer vision syndrome. The effects of prolonged computer use are not just vision-related. Complaints include neurological symptoms like chronic headaches and musculoskeletal problems like neck and back pain.

Unfortunately I've started to experience this over the past three months. Continual fatigue, frequent headaches, inability to focus on screens for long periods of time, higher sensitivity to brightness...it sucks. For a while my routine had me in front of a screen for more than twelve hours per day.

I'm not sure what to do besides be aware of it and start taking small steps to reduce screen time. This means more frequent breaks at work to walk a lap in the hallway, or moving back to paper books, or dimming the brightness on all my devices as low as comfortably possible. It's starting to help, but I'm still far ahead of the three-hour-per-day range of comfort.

Anyone else?

Homogeneous Design

March 24th 2016

Yaron Schoen published this amazing piece last week, In Defense of Homogeneous Design and I honestly just want to quote the whole thing...

Yaron's article was written, I believe, in response to this piece, The Unbearable Homogeneity of Design. And I have to agree with Yaron's take on the matter; but after reading comments across the web it seems like his opinions really rubbed some people the wrong way...

Digital product design isn’t abstract visual expression. It’s a conversation framework between a human and a computer.

I don't think Yaron is talking about homogeneity in terms of culture or gender or race or background or social class...I don't know him personally, but I don't think he's coming from a place of privilege or "better-than-thou" product standards. No, homogeneity in design is about creating experiences that people can understand, that will allow them to interact with computers in ways that are comfortable, familiar and efficient. Defaults are defaults for a reason: people know how to use them, people know what to expect when they click on this or tap on that.

And that's a really powerful, beautiful thing that we should be thankful for (and take advantage of) as designers.

It's why the Human Interface Guidelines exist. This is why Material Design exists. They're frameworks to help you build products that people will know how to use.†

Character is super important in a product, but a lot of that character isn’t only in its visual design. In fact, a lot of it isn’t. It’s in the micro interactions, it’s in the copy, it’s in the nuance.

Some say the world would be boring if every app just used OS defaults. I think that's crap; OS defaults help to create a world where people can accomplish things faster, with less cognitive overhead, without having to learn a new system, without having to guess and make mistakes.

There is still so much freedom in digital product design to elevate usability and clarity, functionality and utility. Introducing new components alongside defaults can help us all in the pursuit of that ever-elusive delightful experience.

It seems that the most-common designer-y reaction I hear to statements like this are: "But how will we push the boundaries? If we all conform to Material and HIG and defaults, design will never advance!"

And I don't disagree, but: let's iterate our way towards that future.

Pull to refresh was a small - and incredibly innovative - piece of a very simple app. Loren didn't have to design an entirely-new app experience just to introduce PtR. No, it was iterative; a small push towards a better user experience. And now that experience is universally understood on touch devices around the world...that's mind-blowing.

And while I think game-changing interactions like PtR won't come around very often, there is still so much untapped opportunity to iterate on the defaults in order to improve products for billions of people. Motion, color, long-press, 3D-touch, haptic...there are so many tools that are still underutilized and underdeveloped in digital product design.

Homogeneity is great. It means we can all go through our day-to-day tasks without more added friction. It means that, as designers, we don't have to reinvent the wheel every time we sit down in front of a screen. It gives us the room to get creative with new paradigms and tools and inputs without people giving up on our products.

So let's embrace that. And of course, we should keep an open eye for the cracks and flaws in the defaults that will inevitably emerge as the world changes, as technology changes, and as we (as humans) change.

Related: The Boring Designer

† And don't even get me started on accessibility...

Designing remotely

March 30th 2016

So what I often recommend people do is ask their boss for a single afternoon a month where they can work from home. Take the first Thursday afternoon of the month. You leave at lunch and work the rest of the day at home. Prove that the sky isn’t falling. Prove that you can get your work done without physical supervision or proximity to your co-workers. Better yet, show you get even more done at home than you do at the office.

People ask me a lot about remote work, having previously spent two years at Buffer (a company well-known for its work-anywhere policy). I'm fortunate to have seen both sides of the remote work lifestyle from a designer's perspective.

Moving from Buffer to Facebook meant trading full-time remote for an office culture - it's been an eye-opening transition. There's a lot more to be unpacked on the subject (especially how remote work impacts design teams), but that's for another time.

One thing I want to call out, however, is Facebook's generous design culture that encourages a (much-needed) no-meeting-Wednesday tradition. This means that most of the design team works from home to split the week in half. For the past eight months, Wednesdays have served as heads-down time for asset creation and pixel pushing while the rest of my week tends to be spent in strategy/alignment mode with various teams across the org.

This feels like a healthier balance to an all-or-nothing attitude towards remote culture, and one I'd encourage companies to try. If your leadership is hesitant about remote work (for designers), try to push for an experimental one-day-per-week split; see how it goes and how it feels (the sourced article above will help with this). To me this balance has helped to capture the best of both worlds and has resulted in better-designed artifacts and faster project sequencing.

There's no doubt in my mind that I'll try full-time remote work again someday - but for now it feels so good to be in a workplace that lets you build the relationships and skills that could only come from an office environment without neglecting the practicalities (and productivity benefits) of a 20% remote workweek.

A good week for design

April 13th 2016

This week I'm feeling more excited about design and the progress we're making as a community than I have in a long time. New Framer, new Origami Studio (coming soon), and a new Sketch point-release all dropped in the last 48 hours.

Across the entire product design workflow, every tool has leveled up:

  • The new symbol system in Sketch 3.7 makes it easier to manage UI components across screens, flows and pages. The new system also makes it harder to corrupt all your layers at once by accidentally tweaking a symbol (this is why I haven't used symbols in years). Treating UI as reusable components makes so much sense and maps to how things actually get built in code.

    I've been using Sketch 3.7 for the past eight hours (no beta for me, sadly) and I'm already sold. Today I worked on four core groups of symbols:

    • OS chrome (status bars, Android navbar, browser URL bars, etc.)
    • Mobile web
    • iOS
    • Android

    Each of those groups are arranged in columns, with each component aligned horizontally in rows. UI tweaks can be made x-platform in just a few clicks by editing these master symbols, and I can make sure I'm matching all platform specs with a glance.

  • Better, faster prototyping from Framer and Origami. I haven't had a chance to dig into the new Framer yet, but I've been working in Origami Studio for the past few months at Facebook. It's a massive level up from the old QC + Origami plugin system. I remember first jumping into Studio earlier this year and being sufficiently ramped up within 1-2 hours. That was mind-blowing. Now I can iterate on multi-step flows in minutes. As in, 5 minutes to throw together a stateful, multi-level-navigation prototype, mirrored on-device. It feels like cheating.

    I've heard from many people that the noodle-port system of QC and the old Origami plugin system felt messy and over-complicated. I felt the same way for a long time (much to the annoyance of my friends working on Studio). But the product team has been pushing obscenely fast to make the app a fast, abstract-able, and easy tool for prototyping across all platforms. It'll come out later this year and I highly recommend everyone give it a try.

Happy designing everyone, it was a good week for the entire community.

Deep Work

March 28th 2016

Last week I finished Deep Work by Cal Newport on a recommendation from Jon Gold - it's a fascinating read for designers and engineers and so-called "knowledge workers." The book will only take you a few hours to get through, but offers an incredibly-dense amount of information that will you have you reflecting on just how messed up modern-day work culture really is.

Here's one of my favorite passages about craftsmanship:

Throughout most of human history, to be a blacksmith or a wheelwright wasn't glamorous. But this doesn't matter, as the specifics of the work are irrelevant. The meaning uncovered by such efforts is due to the skill and appreciation inherent in craftsmanship - not the outcomes of their work. Put another way, a wooden wheel is not noble, but its shaping can be. The same applies to knowledge work. You don't need a rarified job; you need instead a rarified approach to your work.

I highly recommend this book if you're feeling consumed by persistent distraction and circular-progress in your work.

Javascript apps

April 13th 2016

The state of Javascript development is overwhelming and confusing because everyone is over-engineering their apps by default without even realizing it.

This weekend I wrote a small app that tracks how many downloads all of the podcasts on the Spec Network see per week, month, and year. It shows which shows are up or down, as a percent, for each of these timeframes, and can track the network overall to see what our growth looks like.

It's a fairly simple app; it came together after writing ~300 lines of code. But I just ran a script to see how many lines of code were in the entire project: 26,537.

Holy. Shit.

I'm actually embarrassed to admit this next bit: this blog post you're currently reading is built on a codebase of over 400,000 lines. I probably wrote ~2,000 of those.

So yeah, I'm a rookie.

That's what happens when someone who is just starting to learn grabs the nearest boilerplate and goes to town; a million dependencies lay under the surface making magic happen. That's both beautiful and terrifying because I don't know what 99% of my project is doing behind the scenes.

This personal revelation is something the industry has acknowledged for years. I found this great comic to illustrate:

Via Cube Drone

All I can do is recognize that I have a lot left to learn. And now I have a personal challenge to build the next thing as lean as possible.

The software designer

April 18th 2016

The separation of the user interface from the overall design process fundamentally disenfranchises designers at the expense of programmers and relegates them to the status of second-class citizens.

Yes. There are so many amazing bits of commentary packed into Mitchell Kapor's manifesto delivered in 1990. It's fascinating to read this piece more than a quarter-century later and compare it to the state of software design today. So many of the same battles are still being fought inside businesses: explaining what software design is and why it's important, the role of design alongside engineering, the need for proper design education, the usefulness of prototyping and design tools...it goes on.

Naturally, programmers quickly lose respect for people who fail to understand fundamental technical issues. The answer to this is not to exclude designers from the process, but to make sure that they have a sound mastery of technical fundamentals, so that genuine communication with programmers is possible.

Should designers learn to co– ...oops, sorry.

Early feedback

April 26th 2016

Last Friday night and Saturday morning I hacked on a small project idea that would make it easier to see a UI under different constraints with just a few clicks. Imagine being able to check your UI on small screens, large screens – different operating systems – with just a few dropdowns and checkboxes.

It turns out it's quite possible. I tried my best to make a working prototype, put a video up on Youtube and started asking for feedback from the community.

So far the comments have been great – so many people telling me, quite bluntly, that they wouldn't use it, or that it doesn't solve a problem in their workflow. But it's rad because a) I'm getting that feedback really early so I can change the way I iterate on the idea and b) because people are telling me what tangential problems they have based on this prototype, so I'm building a more clear understanding of how to solve those problems.

One of the best learnings from sharing this thing super early is that I'm not great at describing the vision I have in my head for what kinds of problems this product could solve now and in the future. Which means I failed (this time) as a designer. My responsibilities go so far beyond the pixels – it's up to me to actually convince people that this is something worth using and that it can solve real problems.

In this case, what's in my head did not map to what I said out loud. And the pixels on the screen for this super-early prototype certainly weren't enough. I'll keep practicing and be better next time.

Either way, I'm still excited about this prototype and idea. It's also a great excuse to dive into React. More updates to come...

The Motions

August 18th 2016

It sneaks up on you. One day, without warning, you've done it: you've gone through the motions. That feeling that something you once loved has now become mechanical, that you've become a robot – it's a dreadful feeling.

On a few occasions in my life I've found myself going through the motions. And each time it scared the shit out of me. It meant that I was no longer doing the thing for the thing's sake, but rather treating it as a means to an end. It meant I was no longer pushing myself to be critical or to take risks.

Over time I've built a workflow to deal with The Motions. It feels good to articulate it here, in case anyone else finds it useful:

  1. Decide whether the activity is worth continuing at all, based on factors like time investment, reward (financial, or otherwise), value to others, etc. Usually this means being brutally honest with myself about why I do the things I do. This step is probably a whole other post on its own, for another day.
  2. If No, begin planning a how to stop doing the activity. Maybe it means quitting right now. Maybe it means formalizing a plan to gracefully exit, as to not leave anyone else dealing with my shit.
  3. If it's worth continuing, identify core characteristics of the activity that I can influence in order to understand why things have stagnated. A few characteristics come to mind:
    • frequency (how often do I do this activity?)
    • timing (what time of day or week, and how long, is the activity?)
    • content (what constitutes the activity?)
    • people
    • team
  4. Begin testing and iterating. I like to tackle the above list in order, by magnitude of change, starting with timing and frequency.
  5. Timing and frequency can often be trivial to tweak yet have high impact on the overall enjoyment of an activity – for example, I might switch from night workouts to morning workouts. Or I might switch from reading once per week to a few minutes per day. I might adjust the ratio of pre- and post-lunch work hours.
  6. Content feels like the second hardest thing to tweak and is next on my list to test: can I write about different things to revive my interest in writing? Can I take on new projects at work to revive my passion for design and problem solving? Can I read a different book? Or start a different workout routine? Can we talk about different things during a podcast recording?
  7. Finally, if frequency, timing, and content still have me feeling like a robot, I move on to higher magnitude changes like people and team. Can I pair up with a new coworker to solve a problem? Can we interview a new type of person on the podcast to keep things interesting? Is there another team out there doing work tangential to the current activity that I could work with?
  8. If after spending honest time and effort working through this list, testing each step rigorously, I still feel like a robot, it's time to return to step one.

I had to go through this entire flow with a previous blog that I had been managing for 5 years. I tried everything to stay interested and keep posting every day. From building a team of writers, to changing the content of the blog, to changing the posting frequency – at the end of it all, I was still going through the motions.

So I returned to step one, identified that this thing wasn't no long fulfilling in the same ways it had been in the past, and I built myself an exit plan.

Since that time, life has been all the better – it's been a weight lifted from the mind, and now I can move on to things that are rigorous and challenging in new ways.

One big thing

March 29th 2016

In contrast to these big things, I noticed that my to-do lists rewarded small tasks. Checking that “done” box feels good, and if you spend your days on bite-size activities you get to check that box a lot. Yet at the same time, the list was never complete. At best, I felt like a super-productive machine back in those days; at worst, I felt like… well, a machine.

For the past few years I've had a daily morning ritual: write down the things I accomplished yesterday, journal-format, and then write down the things I want to accomplish today. Every Monday I write down the things I want to get done that week and each Friday I recap my successes and failures.

The problem is I'm always focused on lots of things and not one important thing at a time; this often means multitasking and the inevitable Friday recap where I see all the different tasks where I fell short.

It feels like a good time to experiment with something new; something with a heavier emphasis on one big thing at a time to make sure I'm having the most impact possible on my work and on my self.

Also, there's an app for that: One Big Thing.

The attention economy

April 1st 2016

If your daily commute isn’t filled with trivial things like watching the road and trying not to kill people you suddenly have a lot more time to search — and be served search ads. Building a self driving car may seem like extreme measures just to free up people’s time, but it’s really just the tech equivalent of fracking — Oil’s extreme attempt to unlock untapped reserves.

First: I strongly disagree with the author's conclusion in this post (tl;dr: Facebook should charge users for the service and pay people to produce great content). I think that the post was painting a compelling picture right up until this proposal, so for now I'll choose to focus on everything leading up to that point:

It is mind-blowing the strategies that are being taken by corporations to free people's time and convert it into eyeballs and attention and ad dollars. I don't think anyone would deny that this is our world and it's happening.

So my question to you is this: what will you do with the extra time that startups and tech companies are working so hard to set free? Is it more time to read Twitter, or more time to build that side project you've been dreaming about?

We all have a choice in how to spend our free time - I personally find it liberating and empowering to know that so many corporations value my time enough that they'll invent the craziest things to get more of it. But that extra time will be mine, not theirs.

Transparency

April 19th 2016

As a company, we try as hard as possible to be transparent in everything we do, whether it’s the good, the bad, or the ugly. But as a community it seems to be taboo to talk about costs, while bragging about profits and revenues is the norm.

I'm excited to see more companies embracing transparency. Most of us are apprehensive to share internal numbers with the world. This is usually a result of social conditioning telling us that sharing things openly will dull our competitive edge.

But when Unsplash published this transparent breakdown of their costs, the only responses I could find were people offering suggestions on how to save even more money by tweaking their infrastructure or migrating services. That was a wonderful thing to see and speaks to the power of transparency as a tool for discussion and shared learning.

Of course, this is familiar: I used to work at Buffer, a company lauded for their openness and transparency. They recently published their 2016 Pricing Transparency Report that explains where a customer's monthly subscription is being spent (down to the cent). On the more extreme side, Buffer also publishes all employee salaries for the world to scrutinize and compare against.

I've been asked: what was it really like working inside such a transparent company? And the honest answer is that I have not yet seen a major negative drawback from sharing information openly. Buffer's transparency has created a community of people who believe deeply in the company's mission, has sparked meaningful discussions in the startup community on salary, equity, and fundraising, has increased internal trust among employees, and so much more. It was never the easy thing to do – sharing so much information with the world – but looking back, it was certainly the right thing to do.

I believe in the power of transparency. But believing is easy. What's truly meaningful is to act on that belief and share what you've learned with the world.

Props to Unsplash for continuing to share and help all of us learn.

Crutch

August 25th 2016

I feel stuck in this place where I want to work more because I enjoy what I do, while also recognizing that there may be negative consequences if unchecked:

  • overwork
  • burnout
  • creating unsustainable expectations
  • leaving companies every 1-2 years

I wonder whether it's good to work more even if you want to, or whether it's better to self-impose work restrictions in the hopes of building sustainability (perhaps with an opportunity cost of faster career growth?).

Thoughts?

Sketch symbols overhaul

March 30th 2016

I love Sketch.

As a tool, it has made my workflow a million times better than everything that came before. As a company, they have been nothing but supportive and helpful over the years as the community continues to demand new features and fixes.

But symbols...oh, symbols...Those have been the bane of my existence for the past year or two, to the point that I couldn't use them at all despite the potential value they provided.

But it looks like things are about to change for the better - the Sketch 3.7 beta introduces an overhauled symbols system with nesting, easy text overrides, and more. The video below should get any UI designer excited about how much faster their workflow might become with the update (hover to play):

Via @tmgrhm

A Seat at the Table

April 11th 2016

A great Monday-morning read from Jon Schlossberg (published 2 years ago):

I’m not saying design is unimportant—design is often critically important. I’m saying design doesn’t create real value. Design is a tool for multiplying real value and creating perceived value.

Doesn't this depend on the definition of design? Heh, like that will ever happen.

But design overall doesn't create any real value? It seems that, like all broad generalizations, this one can be nit-picked to death. It even looks like Jon might agree that a change of semantics would have made the argument more clear:

But: I won't lose the forest for the trees - the rest of Jon's post is fantastic:

Design can multiply utility that already exists, as it certainly did with the iPhone, but design isn’t the hero. Nevertheless, because design is the most outwardly evident aspect of a product, design often takes much undue credit.

It seems to me that designers can also be involved in the non-outward facing parts of a product that make it successful. Not a zero-sum game here.

I’ve slowly realized over many years that good design is a matter of talent, but great design is a matter of process, and this process is in direct conflict with the way most businesses are run.

Read the full post.

Obscurity

April 6th 2016

We’re afraid that releasing unpolished stuff will garner us public ridicule and rotten cabbages. The reality is that no one but the most extreme haters will react if the work is bad. Unless you live in a snake den, people will only let you know what they like, rather than what they don’t.

Ash writes a beautiful piece about embracing obscurity as we try to carve our small niche in the world. I love it. But I'd add one thing which I've found to be a deterrent to people like me sharing work in public:

What happens when I'm wrong?

Every time I click publish on this little blog I know that, someday, I'll look back on the posts with a sense of naivety. Naivety for having been short-sighted, or not having had a clear understanding of problems and solutions. And that's scary to confront: that I'm most likely going to be wrong and might end up shouting that wrong-ness into the world.

But I do it anyways because it's fun, and it's challenging, and it helps to clarify the thoughts racing around in my head. But more importantly, every once in a while, somebody reaches out saying that it made a difference.

Google Play Redesign

May 23rd 2016

Unsolicited redesigns are tough: they often miss valuable context and critical constraints, or they ignore business goals completely. But sometimes, just sometimes, the unsolicited redesign will strike on something better and true.

I can't say for certain that Flatstudio has achieved this with their unsolicited redesign of the entire Google Play store, but there's no doubt that they've touched upon a beautifully-executed design system for every kind of media Google sells. From a visual perspective, the imagery and color theming work wonders – I immediately went to the production Google Play Store and was hoping to see something equally as rich. Flatstudio is far, far ahead – at least in the visual dimension.

Regardless: Flatstudio has built an interesting case study with a fun, interactive demo website. I can't imagine how many hours went into this, but I'm glad it's live for all of us to admire.

Design in real time

April 7th 2016

Last night I ended the evening by watching Bryn drink beer and move some pixels - live. And it was amazing. I hadn't truly understood how fun it could be to watch a live design process until I experienced the chat room and back-and-forth banter happening between viewers. The chance to ask questions and see Bryn's shortcuts, processes and problem-solving abilities with that degree of transparency is new and exciting.

So now I'm hooked. I know that live streaming isn't even close to a possibility for many designers, but I anticipate that for others it could become a real source of income and interaction as the design industry expands. If you have the flexibility and freedom to live-stream your process, there's no better time to start than now.

If you're looking for some designers to watch in real time, follow these channels:

If I missed any designer-streamers, let me know!

Design management

March 31st 2016

As a manager, you don’t need to know it all. You don’t even need to pretend to know it all. The best coaches aren’t the best athletes. The best teachers aren’t the best executors. Your job is to get better work out of the team then they could have gotten without you, either because they are afraid of you, or because they are motivated by you.

The design management path has been on my mind lately, not as something for the short-term (😬) but as a longer-term area of expertise I'd love to explore. It seems appropriately scary, to the point where I know that if I go down that path I would grow and learn and be better for having tried.

With that in mind, I am 100% behind the way Facebook approaches design management: it is not the only path forward for a young designer! At a certain level, individual contributors can choose to keep pushing forward in IC work or jump over to the management track - it's a step sideways, not a step up. You can be successful on both paths, with corresponding promotions and increased areas of influence.

If you want to work in pixels forever: you can. But if you want to try something new and scary and push your personal comfort zone outward: you can try that, too.

I hope that more companies will start to embrace the idea that a good designer does not always equal a good manager, and vice versa. And forcing someone to take a dead-end path where they can't be their best-self will only result in frustration and churn.

Julie's post, linked above, is brilliant. I can't wait for part two...

Material Motion

May 13th 2016

The material environment draws inspiration from real-world forces, such as gravity and friction. These forces are reflected in the way user input affects elements on screen and how elements react to each other.

Material has its quirks, without a doubt. But the latest Motion guide makes a clear and logical argument for how motion in software design should work. Next: we need some sort of library embedded in our design tools to communicate these principles in our own mocks; until then, at least we have something to point at*.

*Of course, those designers with more time to spare should be able to prototype most of these interactions without too much trouble. But that's a band-aid on a bigger problem with our design tools.

Specifics

March 29th 2016

Design apps and prototyping tools allow you to create fantastical visions of what UI could look like. But when it comes to digital product design, a mockup or prototype’s sole purpose is to clearly communicate a proposed solution to stakeholders and developers. In the end, only what a developer can reproduce in code (in combination with assets) can make it to production.

It's been fun watching Bryn work on this guide over the past week. Designing on an 8-pt grid is something we talk about a lot on Design Details as a practical, useful process for any designer. This guide explains in-depth how to use the grid properly, from baselining text to pixel-fitting icons.

As a side note: this is the launch of a new Spec project, Specifics, meant to share guides and resources to help designers and developers improve their workflow, process and output. Follow along with us on Twitter, @specfm!

My Side Project Graveyard

September 2nd 2016

There's a graveyard on my computer, filled with half-baked concepts and unshipped ideas. It can feel pretty crappy to see all those things that were once so thought-provoking and exciting sitting dormant, broken. What would have happened if I'd followed through? What might things be like if those ideas had come to fruition and gotten real feedback from real people?

Right now I'm just trying to not get hung up – there will always be more ideas, more things to learn. It seems like the key right now is to embrace the graveyard as a symbol of all the things that were tried and learned, not as a reflection of failure.

All the more reason to respect those who ship side projects: this shit's hard.

Sydney Opera House Identity

March 28th 2016

Last month the Sydney Opera House refreshed their identity, adding motion as a core pillar of their brand.

Revealing structural shapes amidst flat fields of color, the motion work is subtle yet dynamic and surprising with some absolutely stunning moments and animation behaviors.

What excites me the most about this rebrand is how a simple, semi-transparent black shape can morph and change in a way that feels both unique and instantly recognizable for the Sydney Opera House. Watch the video below:

Now I'm left wondering what kind of CSS magic it would take to get this degree of dynamism on the web...

Techies

April 4th 2016

The project has two main goals: to show the outside world a more comprehensive picture of people who work in tech, and to bring a bit of attention to folks in the industry whose stories have never been heard, considered or celebrated. We believe storytelling is a powerful tool for social impact and positive change.

I still can't wrap my head around the fact that Techies launched in three months. Talk about hustle (the good kind) and dedication. Thank you to Helena for this project - I can't begin to imagine the impact that this will have on future generations of designers from under-represented backgrounds.

We were able to get a couple hours of Helena's time last week to talk about Techies on Design Details if you want to learn more: Listen here.

iOS 10: Wishes and Concept Video

April 20th 2016

There's never been a better time to be an iOS user. But that doesn't mean that everything's perfect. When it comes to iOS, happiness is often a fleeting moment – a temporary satisfaction with the current state of things before the inevitable longing for something deeper. Such is the constant pursuit of the future.

My fingers are crossed for 3rd party integration in (a customizable) control center. On a less-realistic note, I would love a dark mode at the OS level, but this feels highly unlikely given that Apple just shipped Night Shift.

It's silly at this point that iMessage doesn't support richer content. Peek/pop seems like Apple's toe-in-water moment for a richer messaging experience, but as we've come to learn, 3D-touch still remains incredibly undiscoverable and underutilized.

As always, I'm eager to see what Apple has in store for us at WWDC 2016.

Learning

September 16th 2016

In the United States, the emphasis on understanding sometimes seems to have replaced rather than complemented older teaching methods that scientists are—and have been—telling us work with the brain’s natural process to learn complex subjects like math and science.

This is a worthwhile post to read, reminding me of the most basic methods for learning. I'm especially interested in ways to get better or faster at chunking – a method for storing small chunks of knowledge in long-term memory. An example:

It’s not necessary to go around with 25 marbles in your pocket and lay out 5 rows of 5 marbles again and again so that you get that 5 x 5 = 25. At some point, you just know it fluently from memory.

Of course, that's as simple as one might get. But humans can chunk things much more complex than multiplication tables. We can chunk formulas and concepts, visual arrangements and flows. As designers working with grids and constraints, white space and rhythm, colors and contrast, this is meaningful because we can actively build neural connections between visual expressions and design concepts that will manifest as instinct.

The tough pill to swallow in this article is that the main path to learning new things is through sustained repetition. And it makes sense, but carries certain implications: either you sustain a normal amount of work and repetitive practice for a long period of time, and then become good; or sustain an intense amount of work and repetitive practice in a short period of time, and then become good.

For me, the only time I actually get better at programming is when I program every single day. No brainer, huh? It's tempting to think that I can read a few tutorials and hack on an app once per week and actually get better. But this is an inefficient and ineffective way to learn.

Love your side projects

March 5th 2016

Today I officially stopped work on a side project I’ve been maintaining for the past five years, The Kollection.

The Kollection started in 2010 as a simple blog where my friends and I could curate music. But we poured our hearts into that thing for five years. We wrote thousands — yes, thousands — of posts, and we were able to share music with more than 3 million people around the world. It opened doors I would have never imagined: backstage passes, meeting some of my favorite artists (interviewing Macklemore and Ryan Lewis remains one of the most special nights of my life), selling apparel to fans around the world…man, what a ride.

But momentum turns into burden. The long nights fighting fires, trying to keep the wheels turning. The next exciting project tugs at your shirt. And pretty soon you follow that tug towards the Next Fun Thing™.

Five years of work and love and all I got was this stupid 301 redirect.

The internet quickly moves on. But it’s a sad thing that five years of passion and effort and frustration and joy can all just get wiped away with the click of a button.

It’s time to take what I’ve learned and move on to bigger and better things. Spec, Design Details, my blog…these are all things I love and hope to work on for many years to come. Love your side projects.

The reactions launch is big

February 23rd 2016

The reactions launch is big. It’s going to change the way more than a billion people communicate every day; it’s rare that a small team can have such a massive, sweeping impact.

But today the design community is also taking a big step forward. This post about the work that went into shipping reactions represents a continued push towards a more open and transparent design community.

Showing work that didn’t ship is scary; it‘s opening yourself up to scrutiny and it takes a lot of guts to share that piece of your team with the world. But the result of facing that fear means that every designer can now learn from the battles that Facebook designers spent the last year fighting.

Sharing failure, sharing less-than-pixel-perfect, sharing findings…that’s what this is all about.

At the end of the day any designer can read this piece and take away lessons on emotional design, internationalization, and get a glimpse into the craziness that sometimes comes when a design is iterated upon hundreds of times over the course of a year.

So my hat is off to Geoff and the team that worked on reactions, and equally to Facebook for allowing this kind of open sharing. It’s my sincere hope that this will help other designers around the world to push their companies further along the spectrum towards a more open and transparent design process.

Coding is the New Business Literacy

July 12th 2016

We expect our executives to have a strong understanding of the financial performance of their companies. Shareholders would find it strange – or more likely, unacceptable – if a CEO said, “I’m not financially-inclined” and passed along financial performance inquires to his or her CFO. Similarly, CEOs in an increasingly digital world will struggle to say, “I’m not technical” and hand over mission-critical business questions for the engineers to answer.

I'm not yet sure I agree with most of the points in this article – a lot of the assumptions are a bit naive and I think miss the point of being technical at all in the first place. But this quote did stand out to me as an interesting question: at what point do we expect leaders of technology-powered companies to be technical themselves? And where on the spectrum of technical literacy do we expect them to be?

Is it enough to know how if/else loops work? Or do we expect leaders to be further along towards execution and understanding the way software is architected and shipped? Certainly in the startup world, the latter is going to leverage the team and product in a fundamentally more powerful way. But at a higher-level, later-stage company? I'm not totally sure.

Of course you might even reject the entire original premise, as I'm somewhat inclined to do. An argument could be made that the CEO does have intimate awareness of financials within their organization by way of the CFO. In the same way, the CEO could have an intimate familiarity with the technical architecture and construction of their business by way of a CTO or trusted engineers.

I'll always argue in favor of learning more over learning less, but I'm not convinced that we're ready to start asking the big question: should CEOs learn to code?

Building the Design Details CMS

February 29th 2016

Note: this post is mostly for my own records. It’s not super interesting, but feel free to read. That being said: if you’re an iOS dev and want to collaborate on something fun and simple, scroll to the bottom.

Two years ago I started writing a series of blog posts called Design Details. In 2014 these posts were viewed a bunch and ended up inspiring the Design Details Podcast which I co-host with Bryn Jackson.

Problems

The posts were all written on WordPress, which is great and all, but as anyone who has ever worked on WordPress themes knows, there are a few key problems:

  • Generating structured data out of a post is kind of a nightmare
  • WP wasn’t designed to have a seamless, version-controlled deployment flow
  • WordPress, as a rule of thumb, is slow

Those are my thoughts at this point in time, anyways. So I wanted to see if I could build my own CMS for Design Details while solving each of the aforementioned problems:

  • Create structured data that is accessible via private API endpoints
  • Version controlled, hosted on GitHub, deployed on Heroku — reliable, cheap, fast
  • Minimal dependencies, fast page loads

1. Design

The visual design here wasn’t a long process; I’m not reinventing the wheel. Posts with titles, subtitles, content, permalinks, etc., add in some colors, shadows and small animations and call it good.

The harder design challenge was creating a data structure that would be flexible enough for my current needs and hopefully support future ideas for the posts. I’m not an engineer by trade so a lot of this stuff is pretty abstract to me. But I hacked on a data model for a few hours and came up with something that makes sense in my head and will hopefully work going into the future.

2. Build

I used this boilerplate for a Node + Mongoose + Express setup. It’s fairly straightforward, although I probably lost a good 3 hours trying to figure out session handling and it took me another hour or two to wrap my head around the way Node handles async requests.

Anyways…

In the spirit of transparency, this app is a total hack: yeah, I have simple CRUD functionality, but my deployed app has those routes commented out of the production build because I couldn’t-for-the-life-of-me figure out session handling for user authentication. Next weekend’s project, for sure.

I also don’t really know how to handle complex forms with Node: for example, I have an array of “detail” objects within a post. How do I edit multiple details and save them in-order? No idea. So for now I have to write/save/delete each detail individually. Not too concerned about this, because hooray, I’m the only user!

Oh, I also haven’t really figured out how to handle media uploading. Which I should probably do but honestly sounds like a giant pain in the ass; so for now I’m doing manual uploads to another CDN and just copy/pasta-ing the urls.

Also, I wanted the post data to be available at private API endpoints. So I did that; it’s actually really easy to setup, but now the hard part will be managing access to those endpoints. This will be another weekend’s project, too.

The front-end is all Jade + Sass. I started out hating Jade. I still kind of hate Jade. But just not as much as before. I guess this is a common feeling; next time I’ll use EJS or Swig or something a bit more…normal.

3. Launch

The only reason launching took minimal effort was because I have the good fortune of having spent countless hours debugging Heroku apps in the past. So getting the app online was relatively straightforward; I’d never used MongoLab before, which added a few extra steps to navigate, but overall it was quite seamless. Then I tweeted the thing and called it done. It’s better to ship early than to ship perfect, right?

Next: iOS Devs Wanted

Want to work together on a sweet iOS app to showcase Design Details? Want me to design the thing and you build it? Want to call this a passion project where neither of us get paid? Want to talk on the phone and tell jokes and get to know each other and stuff?

Tweet @ me.

Failed Interviews

June 9th 2016

Communication skills, professional attitude and being trustworthy are just many of the important traits everybody should embody when being interviewed. However it’s a two-way street and sometimes even the best candidates are challenged by poor interviewers.

This post is likely time-sensitive, because Claudio Guglieri is on a streak of replacing his home-page stories with stunning new visuals and arrangements every couple of months. After he's done, the old ones move to Medium and the new one takes center stage. This makes his work all the more enticing – it's here today, replaced tomorrow (although I'm sure he has an archive hidden somewhere with his past creations).

This fourth entry, Failed Interviews, is a concise series of stories and tips for both interviewers and interviewees. My favorite: don't talk trash about a previous company, ever. It's a bad vibe for everyone in the room; in an interview setting, positivity goes a long way in demonstrating professionalism and getting people to feel comfortable being vulnerable with you.

AI, Apple and Google

June 26th 2016

These jokes reflect two issues. The first is that it's not totally apparent that human intelligence itself is actually more than 'a bunch of IF statements', of a few different kinds and at very large scale, at least at a conceptual level. But the second is that this movement from magic to banality is a feature of all technology and all computing, and doesn't mean that it's not working but that it is.

By any standard, the computing power we have today would have been considered magic just a few years ago. I wonder how long it will be until VR and AR are as much a part of our day to day lives as smartphones and cloud storage?

The rest of Benedict's piece is fascinating, I highly encourage a read for anyone interested in technology and where this crazy world is heading.

Burnout and Mental Health

June 28th 2016

I didn't fully realize that I had more power now as a programmer. I didn't think about power struggles-- how other people did go home, but because they took the risk of standing up for themselves.

Engineers have this power. Designers have this power. Stand up for yourself. I see, and participate in, conversations about the hustle on Twitter – "work your ass off, don't party, don't do this, don't do that, give up this, give up that..."

It's a balance (cliche, I know). You can have a social life and be a successful designer. You can party and be a successful designer. Everyone's time scale for success is different.

Some people have been tuning their process for years in order to create a massive amount of output per day. Trying to jump straight to that point can be dangerous. Ten thousand hours, or something like that...

What's more important than the hustle is finding your hustle.

Sometimes your hustle might be working late at night to ship a product that you're proud of. Sometimes your hustle is working your ass off to set the expectation with your peers and managers that you do not check your email after 7pm.

That's a hustle I admire: the hustle of self-respect, understanding your own personality and style, and understanding that, yes indeed, there are some things more important in life than "shipping great products."

A reminder from Meg:

Why Do Anything?

September 22nd 2016

The story is a fable, but its main idea — that a thing’s ideal state is before it comes into existence, that it is better to not be born — is equal parts terrifying and uncanny, especially today, when progress and productivity are practically worshiped.

This is an interest piece, especially as I substitute in the things I build daily at a large tech company, where nothing is permanent and everything is in a state of iteration. I find myself disagreeing wholeheartedly with the idea that to not build something is better; that nothingness is perfection.

For me, to build and create is a worthwhile pursuit in and of itself. To solve problems and exert energy in the pursuit of making the lives of others just a small bit better justifies itself, time and time again.

The decay of material things that time inevitably brings is a force worth fighting. And to fight that battle makes me admire, even more, those who have built anything that continues to stand strong against the test of time.

Reading further:

Idleness, as we know, has a bad rap in Western culture, but it can be a philosophical experience in its own right.

This struck me, because I'm wholly influenced by Western culture, and I wonder if my thinking is so betrayed by my surroundings that I'm unable to distinguish a better path.

But then:

It pains us unbearably to realize that, for all our good intentions, we are agents of degradation, that instead of creating something that stays whole and incorruptible, we by our very doing make it 'perishable and mortal'...

I would rather build and fall prey to the decay of time than to idle away in the perfection of that which doesn't exist, and never have made a difference in people's lives.

Inhuman

April 14th 2016

Talking about how technology and online design has evolved, Stefan Sagmeister:

It's a gigantic mistake. I think we will reach a time where we will look back at this idea of pure functionality and we will shake our heads, and we will think...were we nuts? Were we crazy? Were we completely out of our minds?

He continues:

The crap that's happening now online or in tech - 'let's concentrate on functioning' - that's exactly the same idea as the Soviet building factories, it's that same mindset: let's make it work. But that's not human, that's not who we are...beauty is part of who we are...The shit we are making now that's only functional is actually inhuman...not made for human beings.

Sagmeister continues, critiquing Apple and Google for not delivering on beauty (Apple, specifically, for its online presence). It was an "oh snap" moment in the conversation; a divisive statement if I've ever heard one. Sagmeister's counter examples of where beauty exists – and has succeeded – are physical places like The High Line in New York City and Grand Central Station.

The people who really figure out how to do something online that's actually beautiful...I think there will be unbelievable riches and incredible success associated with it.

My initial reaction to his statements – some may call it defensive – is that in the same way there is inherent function in beauty, there too is inherent beauty in function.1 Not to mention that there is a different subjective beauty in digital places and physical places; I'm not yet sure if one should try to be like the other. 2

On a screen it's different. I'm trying to get something done. I'm trying to connect and communicate. I'm trying to read and be informed. I see beauty in being able to do all of those things faster, without interruption, with thoughtful interactions and with clear expectations. This is possible because of people who build products with a focus on function, but are not blind to the form that will make their products great.

To be clear, I don't disagree with Sagmeister. A world of pure function is cold indeed. But I do disagree with the assertion that tech believes function is the only goal.

I haven't met any designer in tech who believes function and beauty are mutually exclusive. In fact I'm not sure where this assumption comes from in the first place – perhaps I've missed something.

No, the overwhelming mindset I see in tech is function before form, not in spite of it. And to me, that's beautiful.

Jump to 24:30 in the linked episode to hear the full discussion.

1 I know from experience that what Stefan articulated in ten minutes is just a glimpse into his thinking on the subject, so there's more context to be gathered.

2 VR seems like an exception.

Lonely people

June 15th 2016

The corollary is that isolation and loneliness are devastating to a person’s mental and physical health, deadly even. Isolation is, in part, a state of mind, but it is also a physical reality. So we need to ask ourselves how our surroundings, our homes and our cities contribute to the scourge of loneliness.

Loneliness isn't necessarily a result of being alone. Being alone can be healthy and rewarding, especially for people in this field who may be further along the introversion spectrum. That's me.

I'm not sure who all reads these posts, but if anyone ever finds themselves feeling lonely or isolated, let's grab a coffee and hang out.

Learning React

August 15th 2016

Here are the things I follow/use/read to learn about building React apps as I go (two months in so far):

React:

CSS:

Every time I run into an issue I'm blown away by how active this community is. I've especially appreciated Dan Abramov's tweets and thinking about how to make React more accessible for beginners – you should follow him if you're learning.

Being A Developer After 40

May 16th 2016

The stories surrounding the genesis of our industry are fascinating, and will show you two things: first, that everything is a remix. Second, that you could be the one remixing the next big thing. No, scratch that: you are going to be the creators of the next big thing.

This piece is overflowing with so much wisdom applicable beyond software development. Never stop learning, read more, teach others, respect those who have invented before, don't get caught in the hype...the list goes on.

A lot of people agree that 2007, the year of the iPhone, was a defining moment for the current "digital product design" profession. If you buy that notion, it means our little world isn't even a decade old. We're still in the early days of inventing and failing, several decades behind on the same path that programmers have walked before.

It's an exciting time to be a product designer: we can look to software development as a rubric, but the present and future are wide open for invention and innovation.

Content and Quality

April 12th 2016

The only answer, as I see it, is to cut back on the junk and start writing good content again, and to charge in full for it. In a world full of Buzzfeeds, Wireds, and Voxes, there are only a handful of Aeons, Economists, [New Yorkers] whose strategy is not reliant on ad networks, but on a reputation.

It's becoming really hard to read things on the web. Vicki Boykis does a great job walking us through the pain of finding – and actually reading – quality content. Yikes...

Publishers and ad networks are becoming increasingly aggressive and intrusive. This trend is making the web harder to use every day. For many of us, this represents a frustrating regression in what originally made the web so great. But in that frustration good ideas are beginning to emerge.

The Information is one of the more progressive publications taking a stand for both content and presentational integrity. At $400 per year, it's not a cheap subscription. But Hunter Walk makes a great point about what makes this lofty price tag worth it:

For me the value in The Information is not solely in what they’re providing but what they’re leaving out. The ~two articles a day are both interesting. Because they’re not playing a page views game, they don’t need to overload me with 25+ posts every 24 hrs. The site is spartan because they don’t need to worry about IAB units. A small number of writers building their beats give me the chance to see each journalist’s style distinctly, not settle into some random byline slot machine of varying quality.

For what it's worth: I gave The Information a try. Despite not becoming a long-term subscriber, I have to admit that it felt good paying for the content I was consuming – buying the signal without the noise. By subscribing, the articles became a priority in my daily reading routine: after all, I was paying for it.

I did eventually unsubscribe, more for a disconnect between my interests and the content and not necessarily because of the subscription fee. And as a result, it's back to the same popup-filled world of banners and javascript injections and content-pivot overload.

I don't know if The Information is profitable, or what their numbers look like. But from the outside I'm rooting for this model to succeed. If it does, I'll be eagerly counting the days until a couple bucks per day can buy me high-signal, meaningful content in all of the verticals I care about.

Redesigning Chrome Desktop

September 26th 2016

You don’t necessarily need to understand how to code, it’s more important to understand the people who do.

This quote is the most compelling argument to me for people to learn code and fundamental programming concepts: to build shared understanding and empathy for the people who are doing the building.

The rest of this (crazy long) post by Sebastien is worth a read. He has a fanatical approach to visual systems and pixel perfection, which is inspiring to see shine through in a beautiful final product.

When the update started to roll out, the hardest feedback I received was: “That’s it?”.

I love this.

Startup hell

March 28th 2016

Arriving here feels like landing on some remote island where a bunch of people have been living for years, in isolation, making up their own rules and rituals and religion and language—even, to some extent, inventing their own reality. This happens at all organizations, but for some reason tech startups seem to be especially prone to groupthink. Every tech startup seems to be like this. Believing that your company is not just about making money, that there is a meaning and a purpose to what you do, that your company has a mission, and that you want to be part of that mission—that is a big prerequisite for working at one of these places.

I don't know anything about Dan. I don't know much about HubSpot. But this piece is a good laugh, especially since there's a lot of truth wedged in-between the lines.

A reading list

April 20th 2016

There are so many great sources in this reading list from mrmrs. I just finished On Writing Well and can't recommend it enough.

Aside: I'm a big fan of people putting together lists like this – writing that was influential to you in some way. Dan Eden's library also comes to mind.

What's on your list?

More:

The way we build

April 21st 2016

The challenge today is that we are often still using the same methods we were 20 years ago. Tools don’t communicate well, if at all, with each other. We continue to mock things up. The way we work today can broaden the gap between engineering and design, and the many layers between designing and building are a burden.

We can do better. We can work better.

It's fun to catch a glimpse inside Airbnb's latest design investment. Their new Design Language System, or DLS, looks powerful and feels like a natural progression for design tools: put the code and the designer closer together. Mapping components across apps like Sketch and Photoshop and then tying them to production code is a logical (albeit daunting) step forward for the design process.

One of the most pressing challenges in product collaboration is attempting to standardize naming conventions and component designs across product, design, and engineering teams. From a naming standpoint, creating a shared language is hard because different people experience the world with a different vocabulary. One woman's UITableViewCell is another man's list row.

From the nuts-and-bolts angle of building products, if there is any degree of separation between the final code and a component's visual design, entropy within the system takes over; small tweaks accumulate over time and degrade any semblance of a consistent UI.

So my snaps go out to the team at Airbnb who are working to tackle these problems and share their findings with the rest of the community. My only wish is that more of these tools would be open-sourced as a way to give the whole community a level-up.

Entertainment, Hobbies, and Work

July 15th 2016

Everyone finds non-day-job fulfillment in different ways.

For some it's taking photos. For some it's watching TV. For some it's video games. For others it's insert any possible form of entertainment here.

Each of these has an opportunity cost.

For every minute I'm taking photos, I'm not becoming a better writer. For every minute I'm watching TV, I'm not becoming a better programmer. For every minute I'm playing video games I'm not becoming a better photographer.

And it goes on and on with every imaginable form of entertainment and every possible creative endeavor.

I think it's easy to feel better than someone else because your hobby appears more worthwhile or productive. Or to feel better than someone else because your form of entertainment has a higher perceived intellectual value. It's important to distinguish between what makes us feel better, versus what actually makes us better. I'd argue that our side projects and 16-hour days make us feel better about our work and impact, but might not be necessarily making us fundamentally better people.

It's tough because I do believe in working hard and building things that bring value to the world. But I'd be arrogant to sit here on a high horse and think that everyone should share my same beliefs. And it's wrongfully naive of me to assume that working on side projects is somehow better than anyone out there busting their ass to catch 'em all.

Work shaming is a frustrating reality of the tech industry. Frustrating because on the one hand it can motivate me to get off my ass and build things! But it's also a dangerous peer pressure mechanism that creates burned-out, cynical, and jaded human beings.

I want to believe there's a balance in there, somewhere.

Building a New Illustration Style for Shopify

July 27th 2016

Illustration is a communication tool with three super powers. It can add clarity to a complex idea. It can link concepts to the words we’ve assigned them within our respective products (aka on-boarding). And, it can capture the values and traits of a brand in a single voice, shift the tone depending on the situation, and speak directly to the user.

Another awesome post from Meg, sharing actual scrapped-work that helped the Shopify team arrive at a new illustration style. As a designer who doesn't get to work with illustrators often, it was helpful to read about the Shopify team's process and the level of technicality that a final illustration style strives to reach. Illustrations can be composable systems, too.

IOI-655321

March 31st 2016

“Bull,” Lacero interrupted. “That’s just an excuse people use to dodge responsibility. The world is what we make it. We could have found solutions to the energy crisis if we’d tried. And the corporations only took over because no one else was willing to deal with the crap necessary to run a society. No one cared. The whole damn world is obsessed with this place. It’s a constant escape from reality. But it’s not reality. And the real world is crumbling around us while the people obsess over idiotic video games.”

I picked up Ready Player One late last year on a recommendation from Joel Califa - I devoured it in a matter of days. They say this book is required reading for anyone who wants to design/develop in VR.

So here's your order of operations:

  1. Read Ready Player One
  2. Read Lacero - just a short 2 pages of fanfic
  3. Build cool stuff in VR
Getting critiqued

May 12th 2016

But design is different. As a designer, I don’t matter. My work doesn’t matter. Nothing I make matters in the context of my process. It’s all about the people you are building for. You’re just trying to solve problems for people. Once you realize this, it’s the most liberating thing. Because every critique is valid. It doesn’t need to feel like your soul is being ripped apart.

Adam's post on critique surfaced yesterday on Twitter during the discussions about Instagram's new app icon. This post is packed with valid points for people receiving feedback – it's a learned skill and something we should all aim to be better at. We are solving problems for people, yes, and our process or craft is a means to that end.

But that doesn't excuse designers in our community for shitting on other people's work with knee-jerk, emotionally-charged words. Giving feedback is a skill as well, and Twitter is rarely a conducive medium for such things. Logo-redesign-day is becoming as loathed as the "should designers..." diatribe. Which is too bad, because redesigns (such as Instagram's) are a chance for us to learn, to ask more questions, to build context, and to try to understand the changes in relation to a product's goal.

Dealing with consistency

August 11th 2016

I've been writing pretty consistently here for a few months now, but only because I've set up certain (helpful) constraints for myself:

  1. I don't write on the weekends.
  2. I don't write while on vacation.

For the last 10 days I've been on vacation, at home with the family, and there was a lot of temptation to get online and just write one little post. It was important to not fall prey to that temptation – I created my constraints for a reason, and to break them would be undisciplined and lazy.

Over the last 8 years of my life I've maintained at least three daily-post blogs. One about design, one about music, and now this one. But the problem with daily blogs is that they a) put a ton of pressure on you to always be online and b) rarely survive longer than a month.

I learned a while ago that to solve these problems you need to either a) front-load the hell out of your posts in order to take multi-day breaks when you need them, b) get help from other people, or c) set constraints on when you won't post.

For my first design blog, I would front-load a week's worth of posts at a time on the weekends, and then spend the weekdays focused on other projects and gathering new resources.

For my music blog, I got help and worked with over 50 friends around the world who were also passionate about music to make sure that we were posting every day. As a result we posted over 6,000 blog posts during the course of a few years.

Throughout these experiences, I've met with many people who want to start blogging every day – I love that, but just know from experience how rarely it works out. Daily production is really fucking hard. Like working out, it can be painful at first and slow to see results – the perfect prerequisite for quitting. I've also found that when working on daily production, missing one day feels like failure and an excuse to quit.

To solve this for myself, here on my third regularly-updated blog, I've slightly modified my own definition of daily publishing. For me, daily publishing means weekdays-only, and not when my mind should be present elsewhere (e.g. vacation). In some ways, this feels like cheating. But in execution it's the only reason that I've now written hundreds of blog posts in 2016 on this journal. And I'm still having fun with it.

This amount of production, with constraints that create a stress-free schedule, is unbelievably fulfilling.

Priorities

June 2nd 2016

Things I want to be doing right now, in no order:

  • recording more episodes of Design Details with people I look up to
  • helping organize a 2017 Spec conference
  • helping organize more live Design Details events in SF, NYC
  • iterating on a design tool that parses JSON into UI components (demo)
  • related: be better at javascript
  • working on that Messenger bot I started hacking on like two months ago which hasn't gone anywhere
  • working out
  • having more coffee with new people and old friends
  • traveling
  • learning more about photography
  • learning React
  • learning Swift
  • building/designing Spectrum, an app for the design community
  • redesigning spec.fm
  • learning Rails to properly hack on the spec.fm website
  • designing this one unsolicited redesign of an app I love but hasn't been touched in years by the creators
  • reading more books (currently reading)
  • exploring a new format for written interviews with designers
  • starting a solo podcast because it sounds appropriately fun and scary
  • redesigning this website
  • publishing more Design Details blog posts (currently: one draft)
  • building a chrome extension to fix contrast and readability issues on popular website
  • oh yeah, keep building rad things at Facebook with the incredible team I get to see every day

Surely there's a few things missing here (especially personal things, like spending more time with family + friends). But it feels good to have everything in writing.

Problem: it's too much.

Solution: focus and prioritize and sequence.

Problem: that's easier said than done.

If I had to reprioritize and trim the list, it'd look closer to this:

  • Facebook
  • Design Details Podcast
  • Spec.fm
  • Spectrum
  • JSON -> UI design tool
  • Exercise
  • Writing
  • Reading
  • Travel + Photography

The way I try and think about priorities (in theory, not always in practice), is to sort by the highest impact on my professional and personal pillars of life. Interestingly when I look at the reprioritized list all my professional goals are higher than personal goals (like hobbies and reading more).

One of things that's been on my mind a lot lately is how people end up with this kind of ranking system, where professional is put before personal. It's not that professional is bad, or not fun, but more the internal mindset that shapes our goals and priorities in life.

Sometimes I want to just flip the whole list on its head, escape the world and read, write, and take photographs without an internet connection. Cut the cord.

But I realize that's just swinging to the opposite side of the spectrum. No, the resolution is somewhere in the middle, a balance of personal and professional goals. I've lived on the extremes, but finding the middle ground is a challenging exercise in time management, saying no, and being a balanced human.

Questions to Ask Yourself When Reading About Design

July 13th 2016

Other forms of culture benefit enormously from critical thinkers who stand clearly outside of the profession, who don’t “ship” work—whether it’s art, theater, film, music, architecture, or even technology.

This is a solid list from Khoi Vinh, and I do agree with his premise that design critics as non-practitioners either don't exist, or are exceedingly rare (as it relates to designing digital products).

Among his list of questions one might ask when reading about design, this section about how it's said felt particularly relevant:

  • Does the writer use exclamatory or hyperbolic language in making his or her assertions?
  • Does the writer make unsupportable leaps of logic, e.g., equating correlation with causation, or inferring generalities from specifics?
  • Does the writer use language that is unfairly dismissive or disrespectful of the people who created the design?
  • Does the writer use simple, understandable language?
  • Does the writer use excessive jargon or technical terminology?
  • Does the writer offer opposing points of view and does he or she treat them fairly?

These questions resonate with me. It's easy to criticize and dissect and point out the flaws in a design. It's much more difficult – and valuable – to be understandable, respectful, constructive, and positive.

I don't believe that good critique can be born of bad intentions, and right now there are some bad actors with bad intentions writing about design in our community that bring us all down.

Good criticism is not black and white, it’s unflinching in its grayness. It’s not quantitative but qualitative. Its purpose is not to answer questions but to raise them.

And very, very difficult to get right, both as a giver and receiver. But as long as we're all working on it together I'll remain optimistic.

Beyond the Beep

July 18th 2016

A look (and listen) at the use of sounds in user experience design.

This is awesome – it's like an audio version of Design Details! Beyond the Beep by Jordan Kolasinski digs deep into sound design in products, with explanations and technical insights into the tiny sounds that add context to our digital experiences.

Sound design is an exciting field that can add a whole new layer to an experience. I believe that, if tastefully done, sound can create an immense amount of delight (aka the holy grail for designers) and help people connect with products in an entirely different way. See: pressing and holding on the thumbs up button in Messenger...pop!

Beyond the Beep hasn't been updated in quite a while, but I hope that Jordan will revive it soon. Until then you can follow him on Twitter.

Employee #1: Apple

July 28th 2016

Well, to succeed early on you have to be a self-starter. You have to be self-empowered. You have to have a sense that, “I can do whatever needs to be done even if it’s never been done before.

A fun interview filled with stories from Bill Fernandez, Apple's first employee and eventually a software designer for the Mac. Somehow I never get tired of these early stories – this bit was also great (and relevant to how I feel today):

And sure, it was great working with my friends. It was also great having the opportunity for us to build our own computer, so yeah. It was great.

Bryn has imparted on me a different kind of mindset than I'd had when first moving to SF – let's just build cool shit with our friends. And that's kind of the underlying drive of Spec and Design Details: let's go have fun, and work with people that are smart and energizing, and hopefully we can all teach each other and build things people want.

That feels like a good place to be.

Self-awareness

August 26th 2016

Is there a line between being self-aware and over-thinking even the most insignificant daily occurrences? Can being too self-aware of one's character — both flaws and strengths — be a disadvantage? I've often praised self-awareness, and it's a trait widely sought by designers. But (like most things) is there a harmful extreme?

Thoughts?

Shields

March 30th 2016

Your shields drop the moment you let a glimpse of a potential different future into your mind. It seems like a unconsidered off-the-cuff thought sans consequence, but the thought opens you to possibilities that did not exist the moment before the thought existed.

I'm trying to remember my own past 'shields-down' moments after reading Rands' latest post...it's a good reminder, as an individual contributor, to speak up when things are going poorly or when small instances of pain/frustration/anger are happening a few-too-many days in a row. I owe that to my team and to leadership and to myself to make sure that it's never a surprise when the shields start falling.

Taking The Robots To Design School

May 26th 2016

Design is a series of rules, whether you realize it or not. There are some simple, explicit rules. Lines of text should be around 66 characters wide. Text colors should have appropriate contrast so as to be accessible. Widows and rivers in paragraphs of text should be avoided; the variations in a type scale reduced to provided juxtaposition to each other. These are the explicit rules; those which we can easily write books about.

I was able to get a sneak peek at some of the early work on The Grid's typographic system. And being lucky enough to spend time with Jon Gold has dramatically influenced the way I think about designing systems. Rules, constraints, logic and math are a deeper part of my design process and vocabulary (though I still have a long ways to go) because of a handful of conversations with Jon.

His thinking on typographic systems is fascinating and should give pause to anyone who finds themselves spending too much time on the "what" of design, rather than the "why." I won't pretend to understand all of the complexity in the algorithms Jon worked on, but his post makes a point clear enough to me: design isn't magic. It's a series of rules and logical decisions that can be compared, contrasted, improved, learned, and taught. And the opportunity that exists to bring this kind of thinking into our design tools, processes and teams is staggering.

Gold:

Our tools could take us towards trends, or away from them. We can, right now, suggest a more popular font, but equally we can surface similar but undiscovered treasures for those looking to branch out from the mainstream. We can suggest, hint and correct; all built from solid design principles and the collective sum of our experience as designers. All this is within reach.

I'm excited to see what's next.

Objective management

April 15th 2016

The art of management is that most of the time, in the moment, it can be entirely unclear whether you’re doing the right thing...Ultimately, you need to have faith in yourself and do what resonates with you. And when you reflect back on those outcomes, you need to recognize and learn from your mistakes.

I'm trying to find any objective truths about management but it seems they are few and far between – if they even exist at all. And while I enjoy Julie's writing, I ended Part 2 feeling more uncertain than when I began.

I know that these posts are reflective of Julie's own thoughts and experiences, which means they come from a certain set of constraints and contexts i.e. there is more to be interpreted.

But in my mind this quote above seems to be both a problem and solution at the same time. People following their gut, against all odds, and learning in retrospect – it feels like this advice is prone to creating both good and bad managers in a given system (or at the very least, creating good managers slower).

1987 Human Interface Guidelines

May 3rd 2016

1987 was the year that the Macintosh II, Apple’s first Macintosh to be released with a color display (supporting a spectrum of 256 colors), was released. It was also the year Apple published their Human Interface Guidelines.

What a treasure; I really need to grab a copy of this original HIG. I enjoyed Bryant's brief recap of some relevant quotes, but most importantly the emphasis on how little has changed over the last 30 years with regard to core user experience principles.

Reading the HIG front-to-back just once was really useful for me. Same for the Material spec. After having a foundation, it makes designing for each platform much faster because I have a better sense of where to go looking for answers.

Better

September 14th 2016

Yesterday I complained a lot on Twitter, mostly about iOS 10 and having to relearn the way to use some features of my phone. But unconstructive complaining isn't fun for anyone.

So I'll try to be better going forward.

Blind positivity isn't the answer. But the line between a justified rant and a public complain-fest is a challenging – and worthwhile – line to find. Hopefully I'll land on the right side more often than not.

Preparing a Design Talk

June 9th 2016

One of the most creative and captivating talks you'll ever see, I promise. Alex is a master at what he does (and he does a lot of things). Grab forty-five minutes and enjoy.

(Design) Lead Starter Kit

June 29th 2016

My fears were unfounded. After watching my craft grow exponentially, working with other teams to solve nuanced problems on a large scale, and seeing them through to the finished product, I watched my fears grow with me too. I’m not afraid of getting stale, and not personally growing as an designer any more.

This particular quote stood out to me from Meg's latest article on leading a design team. Her writing style is so personal and honest – I can't get enough.

There's a natural fear associated with doing or creating anything new. People have always told me that when you're no longer uncomfortable, it's time to move on to something new. I think Meg is living in that world right now, and it's fun to watch things unfold for her.

Overcoming fear is one of the surest signs of growth, embrace the fear.

Talk Turkey

July 5th 2016

Sorry if this comes off as super self-promotey, but I really did have a lot of fun chatting with Gabe on his newest side project, Talk Turkey.

When Gabe first shared his idea with me, I got immediately caught up in the excitement and possibilities of this kind of surface. Talk Turkey would be a series of interviews with different people, but rather than having an editorial Q&A format, the interviews would literally be copy-pasted chat conversations.

As a result, you end up with interviews that feel much more honest and true to the person's voice. As a reader you get this deep voyeuristic sensation of peeking into what was once a private discussion, almost like you're reading Gabe's phone over his shoulder.

All of the chats so far have been real and honest in ways I've never quite seen before – I highly recommend taking some time to read them. My own conversation with Gabe is about writing, side projects, and internet fame – it was a lot of fun to talk about and I hope you enjoy reading!

Assertiveness

August 24th 2016

Being assertive isn't the same as being reckless. Assertiveness doesn't mean being a lone-wolf designer. Asking questions or getting a second opinion isn't in conflict with being assertive. Having an opinion about a feature or a design decision is necessary, but validating that assumption or opinion with people you trust isn't a sign of weakness.

People who ask for advice in order to refine their prior thinking or opinions are more trustworthy designers. Those designers don't assume themselves to be perfect and recognize that intuition isn't always the best way to navigate a design process.

SF and tech

May 10th 2016

There are things I’m proud of and things I’m not proud of when it comes to what our department has accomplished over the last few years, but standing above anything related to our craft is the responsibility the team took in building empathy for women and minorities in our industry, having honest conversations about where we needed to improve, and finally diversifying our team substantially.

This is one of the best pieces about tech and SF that I've read in a long time. Set aside 15 minutes and dive in, there's something for everyone in Mike's piece. From the role of product management to diversity to culture to hiring to empathy to management to, well, everything else – this post covers so many important and nuanced topics. These topics are often difficult to discuss candidly – the design community in SF is so damn small and everyone seems to know everyone.

Something on my mind recently is the tough realization that what's published online by designers about work, culture, careers and happiness is rarely an accurate representation of reality. But somehow Mike has managed to be real in his piece without calling out people or companies. That's really hard to do – thank you Mike for sharing so honestly with us.

Possible vs. Easy

May 20th 2016

But herein lies the difference between a program which is possible to use versus a program which is easy to use. Even smart, experienced, advanced users will appreciate things that you do to make it easy for the distracted, inexperienced, beginner users.

It's been a pleasure digging back into the archives of Joel's blog – so many bits and pieces relevant to the work we are still doing today. This particular piece from April, 2000, reinforces one of the core principles of designing great software.

I can't help but be reminded of designing modals – it's quite easy to manipulate the button a person clicks by just moving it to the bottom right corner, where a person expects the primary dialog action to be. So for example if someone is trying to delete their account on your service, the confirmation modal might have two actions: Cancel, Delete. We know that people rarely read text in a UI, so by putting 'cancel' in the bottom-right corner (with louder styling) you could probably reduce dropoff by a trivial amount. Of course, this will inevitably create more frustration for people who have to go through this flow a second time.

But the question you should be asking at that point, when you're splitting hairs over a button position, is: why was that person here in the first place? Why did the person want to delete their account? Instead of manipulating the common behaviors of dialogs, you have an opportunity to initiate a live chat, or suggest a better plan for their particular use case, or just ask what's going on.

You'll not only feel better about your work, because you're not trying to abuse user experience paradigms (which inevitably reduce long-term trust in your product), but you might find that the original intention (in this case, deleting an account) can be transformed into a positive outcome (for both the person and your business) by adding genuine humanity into the product.

Has Design Become Too Hard?

June 7th 2016

We judge designers by their work, not by the tools they use to do that work, right? If learning something new excites you, go for it. If it’s causing undue anxiety, don’t force yourself to learn it now. You are still a good person.

The designer's toolbox has and will forever be changing, evolving. That's the double-edged sword that makes building products for screens so equally exciting and challenging: there's always something new that can make a user experience better; there's always something new and cutting edge that takes time to learn.

There's a nuance to the question of whether or not one should keep up with the latest, trendiest tools. On one side it's clear: most of the tools won't last, it would be time-consuming and counter-productive to try and keep up. On the other side, and probably closer to where I live, is that by keeping up one can more clearly understand the evolution of our tools and the "why" behind each new thing.

For some people that's not important, and that's okay. Investing time into tools and experimental processes is a function of time and energy – scarce resources for those with families or kids or, dare I say, hobbies. It makes more sense in that case to let the young and foolish (like me) vet new tools and invest the time to try and find what can legitimately solve design problems (much in the same way that it's a safe bet to start using Sketch as a designer today; the early adopter community has collectively proven its value as a tool for design).

And at the end of the day, Zeldman's right: it's the work that speaks, not the tools. There are unreal designers out there solving hard problems with Photoshop and vanilla CSS. If that's not a wake-up call that the new Framework.js™ isn't a panacea, then I don't know what is.

Sketch Pricing

June 8th 2016

So, to confirm the upcoming change: Sketch will be dropping its traditional version numbering scheme, and everybody will receive at least another six months of free updates, after which you can extend your license to receive another year’s worth.

Sketch is moving to a yearly pricing model, with a guaranteed 6-month window of free updates for existing users. After that, people will be billed annually with rolling updates and no more major version releases.

I personally don't mind this change, for a few reasons:

  1. Sketch literally makes me perform my job better and faster. Software that makes you faster usually pays for itself within a few days or weeks.
  2. If you don't choose to continue paying after a year, you can still use Sketch. Of course, you'll miss updates and new features. Backwards compatibility will be a bit, dare I say, sketchy. But at least you won't lose access to the software.

If this new model ensures that Sketch will be around for years to come, and that the team can afford to keep building features that make designing products faster (and better), then I'm all in.

After a few hours, it looks like the biggest concern for people is backwards compatibility. From what I can gather, the team is focused on building as many features as possible with backwards compatibility in mind. Only certain major launches (like the new symbols) will cause issues, at which point updating versions is a no-brainer.

Think Less, Think Better

June 19th 2016

In general, there is a tension in our brains between exploration and exploitation. When we are exploratory, we attend to things with a wide scope, curious and desiring to learn. Other times, we rely on, or “exploit,” what we already know, leaning on our expectations, trusting the comfort of a predictable environment.

This feels like common sense after reading it, but having the correct terminology to describe the two processes (exploration vs. exploitation) is helpful.

I've found myself living a more distracted life over the last few months. Even while writing this post I've checked my phone notifications, checked Twitter, thought about a Facebook message I haven't replied to, checked in on a side project I'm working on, and tried to quickly debug a feature I'm building.

Not only am I scared of burnout – always being "plugged in" like this – but it now seems like overthinking and heavy context switching can reduce my ability to live in "exploration" mode.

Not ideal.

I'm worried that I'm losing my ability to concentrate for long periods of time or go deep on a particular topic. Those are hard things to do when the mind is busy in several domains at once, but only on the surface level. This feels like a worthwhile problem to invest energy in reversing.

Inconsistencies

July 19th 2016

I had a good friend call me out yesterday, holding me accountable for the intention and meaning of the words I write here. First of all: if you don't have someone in your life that holds you accountable in this way, I highly recommend finding one. Second, in our followup conversation I realized something troubling about myself.

Too often I say what I believe, but don't always act on those beliefs. Example: I don't believe that work shaming is healthy for our community but I find myself silently doing it when people work less than me.

I don't believe it's healthy to take pride in staying late or pulling all nighters, but I keep a mental tally of who stays in the office longer (and feel guilty that I'm often among the first to leave in the evenings).

There's more of course, and some far more embarrassing than the two inconsistencies listed above.

Perhaps I'm just an asshole. In my defense, at least I'm trying to be a self-aware asshole. And that seems like an okay place to start – to admit that my actions and world outlook don't align yet. Even writing this now, and having an honest conversation with a friend about it, has helped to add perspective.

The Inaccessible Web

September 1st 2016

While it’s easy to get discouraged, it’s worth noting that making accessible websites isn’t hard and doesn’t take a huge amount of time. But that’s assuming it’s not treated as an afterthought, and that it’s not the responsibility of a single individual within an organisation.

I'm guilty of treating accessibility as an afterthought in many projects. It shouldn't be this way. It's up to us, as people building digital products, to teach ourselves and each other about the tools that exist which make our products usable by all people. That's the least we can do.

Storytelling

September 7th 2016

We can endlessly argue about why Apple should keep or remove the headphone jack; what I’m interested in is which argument Apple chooses to make.

Apple has succeeded in removing the floppy, the optical drive, and more. I'm also excited to see the story that unfolds today; I remember when the Macbook Air was released and there was an initial scramble and confusion – what about our CDs!?

But here we are, in 2016, and I haven't touched a CD in years. The over-the-air-software story Apple told was not only more valuable to customers, but also an incredibly opinionated perspective on how the world should use computers.

What I'm curious to see today, as I sit here with my headphones plugged into my iPhone, is what story might win the world over today, and whether it's true that removing the 3.5mm jack is the most valuable thing for customers as we move into the future.

Probably.

Design at 1x

May 5th 2016

Shouldn’t your designs be speaking the same language as the code that’s implementing them? Yes, yes they should. And engineers use points, not pixels.

Kurt Varner digs into the reasons for designing at 1x over 2x. The post touches on all of the key arguments and feels compelling enough for designers working at 2x to consider changing their workflows. The key here is to make sure your whole team can buy into a 1x workflow. That's easier said than done, of course.

I finally made the leap to 1x this year and it feels great. Less mental math, better performance in Sketch, etc. All my projects now start at 1x on a 4-inch screen. Why? 1x for all the reasons Kurt has listed above. 4-inch because Apple is clearly investing in smaller, cheaper devices both in the US and abroad. I'd rather build products knowing that the design will work well within a system of greater constraints (and internationally, where smaller devices are more common). Scaling up after the fact is easy.

Building a Visual Language

May 27th 2016

Since the design language and code are often shared, we can now build and release features on all native platforms at roughly the same time. Development is generally faster, since product engineers can focus more on writing the feature logic rather than the view code. Additionally, engineers and designers now share a common language.

I'm glad to see Airbnb sharing more of their design process and evolution. This post by Karri Saarinen is a great start. A few observations:

  • My favorite part of this entire post came in the last footnote, describing how the Airbnb design team uses git to version and maintain a master library of components. This could should be an entire series of posts on its own.
  • We did not get to see what didn't ship. From a process perspective, I think the post offers a good amount of value. But from a tactical perspective I wish that more literal work was shared so the community can understand why final solutions were chosen. It sounds like this was the first in a series of posts, so I'll keep my fingers crossed for future deep-dives into why they landed on certain components and styles.
  • If designs aren't mapped to code then a "system" is not a true system. Airbnb is investing in tools that map sketch files to production code; this is a step closer to the future of software design. Let's hope for a future where we can get a peek at how these tools work, and ideally open source them so that we can all build better software, faster.

We initially tried to create these components as symbols in Sketch, which resulted in a mess. Even now, our Sketch files are sometimes challenging to maintain. Moving forward, we hope to find better ways of maintaining and creating new components.

  • This one hits a bit too close to home. If anyone has figured out a better way to maintain Sketch files please please please write about it. I've gone all-in on symbols to the point where my files crash from bloat. I've gone all-in on layer groups to the point where it was impossible to maintain changes. I've gone all-in on component-files to the point where it was impossible to name, share and maintain the system. My next move is to just code everything. That way the end result will by default have proper reusability, version control, and collaborative iteration. Is this the best solution that exists right now?

Overall: this post is a start. And a good start, at that.

At the very least I hope it inspires more teams to keep sharing their challenges and processes to be better. I'd love to see more work that didn't ship and reasoning for the why. I'd love to see more of the tools that are being used to maintain Sketch files and map them to code shared and open sourced. But of course, I'm asking for a lot.

I believe we'll get there.

Evaluating Employees

June 10th 2016

The traditional way of evaluating employees — based on things like results, metrics, and impact — is just another manifestation of easy-to-measuritis. We want objective, binary ways of evaluating people so that they are uncontroversial and unassailable, but what we end up with are objective, binary ways to measure the wrong things, or at the very least, things that employees are not in direct control of.

It's murky waters all the way down when it comes to measuring people. But Mike's argument is strong: measuring a person against metrics is lazy and and can end up hurting the best people.

Embracing subjectivity isn't easy. It becomes more about dialogue and thoughtful analysis than numbers and dashboards. And when you have multiple people on multiple layers of an org, there's so much room for things to get messy. I've really enjoyed Mike's thinking on this subject; trying to understand how to identify strong designers without metrics is a challenging mental and interpersonal exercise. But that challenge feels worthwhile.

Tired

September 12th 2016

This weekend I was lucky enough to attend XOXO in Portland, Oregon. It's the largest conference I've ever been to, with over 1,200 attendees. I'm so thankful I was able to go, especially after hearing so many good things about this gathering over the last several years.

Despite being surrounded by so many friends – new and old – I left feeling totally drained, possibly stressed. A few friends expressed similar feelings; on Sunday afternoon a few of us sat outside, dodging the sun and not getting too serious about anything at all. That helped.

Introversion seems to have become a glamorized condition during the past few years. There are good things about it, I know, but this weekend I found myself wishing I fell further along the spectrum towards extroversion. I'm mostly concerned that I'm not cut out for conferences like this: festivals and gatherings filled with people who I look up to, many of whom I call friends, who I want to learn from and get to know better.

But now I'm just tired, wondering if these kinds of events are for me.

Secrecy

April 19th 2016

But the transition to the cloud does not alter people’s expectations of privacy and should not alter the fundamental constitutional requirement that the government must – with few exceptions – give notice when it searches and seizes private information or communications.

From last week's announcement that Microsoft is suing the US Government. Of course, Microsoft has been under fire for its own privacy issues, so you have to wonder how much of this is just PR spin or truly meaningful action by a major voice in the tech community.

Holistic Designers

May 18th 2016

Just like we ask designers, engineers and PMs to consider the entire system when designing and building their slice of it, we should also ask the same of ourselves as managers.

Beyond just the inefficiencies in process, siloing is harmful to the product itself. It's why in the last 1-2 years we've seen an explosive focus on style guides and shared component libraries. Designers working in large systems should always be asking themselves: has someone else solved this before me? If not, will my new solution fit in with the global system? If not, why?

Thinking locally within an org creates short term wins that feel good and fast and efficient, but in fact it only accumulates a crippling backlog of inconsistencies and design debt.

Related: The Boring Designer

The Futility of the Workout-Sit Cycle

August 17th 2016

The main conclusion is that vigorous physical activity...doesn’t cancel out the negative impact of time spent being sedentary, which appears to increase the risk of cardiovascular disease (the leading cause of death) and diabetes, even among people who exercise regularly.

A lot of people turned off their "stand up" reminders on the Apple Watch. Mostly because a buzz every hour has the potential to be extremely annoying. I get that. But I've come to appreciate the reminders, and actively pay attention to them, for exactly this reason. Even standing up for 5 minutes every hour falls prey to this "tradeoff mentality" mentioned in the article, but hey, every bit counts for those of us who work on computers for a living.

Slowing down

September 6th 2016

This week we've made the transition to releasing one episode of Design Details per week. For over a year we've been cruising at a steady two-episodes-per-week pace, and I'm so thankful we were able to pull it off. But slowing down is the right move: it will give Bryn and I more time to work on other projects at Spec and will make the Design Details podcast itself more sustainable for the long-term. Side project burnout is a thing, too, and the last thing I'd want is to hit a point where projects that are a source of creative and personal fulfillment start to feel like a job.

Being aware of when that feeling starts to creep in is the first challenge. Navigating a way to reverse that is the next phase.

Thanks to everyone who has been listening to the show for the last year and a half – we have so many more great shows to come, but now at a more realistic pace for everyone.

The really big one

April 18th 2016

On the face of it, earthquakes seem to present us with problems of space: the way we live along fault lines, in brick buildings, in homes made valuable by their proximity to the sea. But, covertly, they also present us with problems of time. The earth is 4.5 billion years old, but we are a young species, relatively speaking, with an average individual allotment of three score years and ten. The brevity of our lives breeds a kind of temporal parochialism—an ignorance of or an indifference to those planetary gears which turn more slowly than our own.

I loved this bit from last July's piece about the next big earthquake due to hit the Pacific Northwest; beautiful prose to illustrate a very serious problem that everyone seems to be ignoring.

Designing Inward

May 6th 2016

But turning our own design methods on ourselves revealed a lot that we didn’t know before and led us to improve our practices and processes to try and create the best possible environment for design and our teams.

Self awareness at a team level is crucial. I'm interested in hearing more about how Cap + Team ended up clarifying the design manager role: what changed and how did it impacted team collaboration and happiness?

Design management has been on my mind a lot lately, specifically trying to understand what it means to be good in that role and what success looks like for a manager. There's a lot of nuance, and probably not an objective truth (yikes) but that's okay. That tells me there is craft involved, which means it can be practiced and learned and improved over time.

Instagram

May 11th 2016

Today we’re introducing a new look. You’ll see an updated icon and app design for Instagram. Inspired by the previous app icon, the new one represents a simpler camera and the rainbow lives on in gradient form.

Typography for User Interfaces

June 23rd 2016

Overall, I see the future for UI typography being all about sensors and font formats that can respond to data acquired from these sensors, and eventually also new typographic tools that have contextual awareness which integrates more intelligent algorithms to our workflows.

I'm excited to see where this world goes, too – we've come a long way in the past 10 years. Lately I've been using SF for everything, not only in the things I design but also in the products I use. My Mac, iOS devices, Watch, and even this website you're reading now (if you're on a Mac/iPhone) are all displaying SF – so really, I mean everything. But I wonder where this goes next – will contextual typefaces emerge that adjust based on what I'm reading and where/how I'm reading it?

On Being A Senior ________

June 27th 2016

They recognize that at some point, their individual contribution and potential cannot be exercised singularly. They recognize that there is only so much that can be produced by a single person, and the world’s best engineering feats are executed by teams, not singularly brilliant and lone engineers.

What an amazing post, targeted towards engineering but maps so beautifully to design. "Senior" is a challenging, ambiguous word to define. And in the design world it seems that anyone with more than five years of experience finds themselves with this title – it makes sense given that (our current idea of) mobile app design has only been a thing for less than a decade.

But Allspaw challenges the idea of years of experience as an indication of seniority in a clear, thoughtful and articulate way. As someone early in their career, this will serve as an incredible framework for growth and development in the coming years.

Sketch Runner

April 25th 2016

Runner helps you to get around Sketch quicker by giving you an intuitive interface to supercharge your daily workflow. Stop searching through your menu & start running commands directly from your keyboard.

Looks promising – I gave the plugin a try last week and had a few feature requests I sent to the team; this has the potential to make my Sketch workflow (especially with the new Symbols system) 10x faster.

Bots won't replace apps

April 29th 2016

This notion of a bot handling the above sorts of tasks is a curious kind of skeumorphism. In the same way that a contact book app (before the flat UI fashion began) may have presented contacts as little cards with drop shadows and ring holes to suggest a Rolodex, conversational UI, too, has applied an analog metaphor to a digital task and brought along details that, in this form, no longer serve any purpose.

It took me too long to finally catch up with this post by Dan Grover about apps, chats, bots, design, and how we use digital products. It's a long piece but is worth the time, I promise.

Dan articulates so clearly many of the things that have been frustrating me about apps and OSs; ideas I have never been able to clearly form or articulate. Red dots, lock screen notifications, walled gardens of content...there are so many tedious, confusing, and frustrating aspects of how we've built (and use) our phones (on the West Coast, at least).

It's clear that Chinese companies, like Tencent, have found a meaningful way to think about some of these problems – we all have something to learn by studying WeChat and the model they've created for an app-within-an-app platform. But we're all still at the first step of this long road towards building better, more meaningful systems for people everywhere.

Funny code

May 4th 2016

Ok, I feel like you’re with me on this, so let’s get real. I’m gonna write a much larger example below here. I want you to hang on and breathe through it. Remember what we practiced. Two short breaths in, and exhale. Repeat.

Why can't more programming tutorials be this much fun to read? Teaching like an actual human and less like a computer is refreshing and somehow does something to my brain that makes the examples easier to ingest and recall. Well done, Noah; what a great lesson for the next time I ever try to teach something hard.

Design Systems

May 12th 2016

One of the most attractive aspects of design is the sense of freedom it offers. To a designer, there’s something exciting about a blank canvas — ultimate creative freedom. But the reality is, when it comes to design systems, creativity and freedom are just not that important. Noodling about in Sketch might appeal to a designer’s creative needs but it’s not at all conducive to a performant, cohesive web product.

Sharing a design system can be a scary thing. It opens your team's process and craft up to the world's judgment and critique. It also feels a bit like giving away some of the secret sauce that makes your product/brand/style your own.

But sharing the system also allows your team to talk honestly about what they've learned, understand mistakes and invite improvements from the community. More importantly, I believe, is that it continues to push our community further in the direction of transparency and shared learning.

Marvel's own public style guide is one of the better-executed guides on the web. The writeup sourced above gives us a glimpse into their process and is definitely worth a read for anyone working on design systems.

More systems:

Send me more suggestions for this list on Twitter!

Codes of Conduct

May 19th 2016

First things first: the new Epicurrence has been announced! The site is gorgeous, as always – definitely take a peek. I'm still trying to figure out how the dynamic underlining on input fields work...🤔

Second: I'm a big believer in what Dann has built with Epicurrence. It's the best design "conference" I've ever been to (twice!). Everyone should request an invite – I know there's some sticker shock attached to these events, that's totally reasonable. But apply anyways. There are a lot of creative ways to make the price a non-issue, I'm sure Dann is working on some things now as he has done in the past.

And now the main point: Epicurrence's Code of Conduct. This is a document worth reading regardless of what event it's attached to; it holds truths that apply to all conferences and design events. Marc Hemeon put a lot of love into this document, and now it serves as a foundation for all future Epicurrence events (and as a rubric for other aspiring communities) – thank you, Marc.

Starting a community is hard, growing it is harder, but the hardest part of all is turning a community into a space where everyone is welcomed, respected, and encouraged.

Codes of conduct have been on our mind a lot lately at Spec. We owe so much to people like Paul, Marc and Sean who devote their time and energy into making the design community a better place for all of us.

If you are part of a design community, or run one on your own, please consider making a code of conduct. I believe that these documents over time and added-up will shape the future of our community's discourse.

Related:

Am I missing any other CoCs? Tweet me.

Declarative Design Tools

June 3rd 2016

And yet… our design process is still limited by our meatspace interactions bridging between our brains and devices that have unbounded computational power. Our brains and computers are fast; our hands, mice and keyboards are slow.

Dungeons and dragons references abound, Jon Gold shares a new piece about our design tools and why iteration is so damn hard.

On a current project at work I'm moving around hundreds of artboards across multiple pages and files. Maintaining iterations, diverging and converging, and keeping consistent content and interaction patterns is near impossible without some kind of programatically-backed infrastructure.

Right now there aren't really design tools to help with this, as far as I can tell. An interim solution I'm exploring is a git-sketch plugin that allows for version controlled components with image diffing for clean commits. But it's hard, and it has pushed my mindset over the last 3-4 months into the world of design tools and where we're falling short.

Back to Gold:

Imperative programming is telling the computer how to calculate something. We give it step by step instructions—procedures—to get to the answer. Declarative programming, by contrast, focusses on what we want to calculate - we don’t concern ourselves with the details.

An example: Rene by Jon Gold. It's a declarative tool to explore hundreds or thousands of possible iterations in quick succession. It enables a cleaner process of diverging and converging on solutions by inputing atomic changes into the system. It's fun to use and the possibilities are exciting. Think: iterating on an entire website or system of components in seconds, with a coded output and a systematic hierarchy of sizes and variables. That sounds rad.

It's still early days for Rene, but I highly recommend playing around with the first beta. Jon's thinking has been so fun to follow over the past few months – I'm excited to see where these concepts will push our tools and processes in the future.

Norway's New Currency Design

June 6th 2016

The bills should enter circulation in 2017. Until then, perhaps you'd consider saving your own ugly-ass money for a trip to Oslo so you can see (and spend) them in person.

We got into currency design in last week's Design Details with Jasper Hauser. It's a fun topic because currency notes are so universal to the point of being an afterthought. When was the last time you really stopped to admire that $20 bill stuffed in your wallet?

The notes are a utility which serve a specific purpose. But every now and then a country or person makes a case for adding thoughtful design to an otherwise plain utility.

These prototype Norwegian notes are particularly gorgeous. The color and illustration and infusion of nature feel more rich and interesting than what one might see in the US.

More:

The Right Tool for the Job

July 5th 2016

“Those who can’t, teach,” is clearly wrong. I certainly still design things. I write code every day, too. Sometimes I even design and code well! However, I’ve never worked on something that multiplied my efforts as much as when I started building things to help others learn and help each other.

I've been waiting for Bryn to make this announcement for a while – I couldn't be more excited for his next move to join Figma and help the entire design community come together, level up, and build better products together.

Also some cool updates:

If you're in our Spec Slack team you can now use Figma! Just select "sign in with Slack" and enter 'specnetwork' as the Slack team name. That will give you access to some Spec projects in Figma like Inspect, where we host public critiques, and Spectrum, where we'll be building our next community product in public. And, of course, you'll be able to use Figma for personal projects and whatever else you want to work on!

And if you're in the bay area, come hang out with the Figma team (and me!) next Thursday. Sign up here.

You Don't Need Javascript

July 11th 2016

Css is powerful, you can do a lot of things without js.

There's a handful of solid demos in here, although to be fair if you wanted to actually do anything with some of these components you'd probably want Javascript. I also found it odd that the to-do list example is built entirely with Jade and programatic declarations. So I guess it's not technically using js, but it's close enough to feel out of place in this list.

More to the point, however, is that there are some really awesome ways to hack native inputs to handle on/off states with pure CSS. If anything, that kind of info will help anyone building websites to push themselves as much as possible to find the pure solution, rather than falling back to an easy jQuery fix.

A Sense of Where You Are

July 14th 2016

The reason you need a discrete, substantial Understand phase is not to appease designers’ need to be creative. It’s the time it will realistically take your team to express their ideas properly and get them into a form in which they can be realistically evaluated.

The understand phase is the tricky one, and it's where I find myself being challenged the most: moving pixels too soon, showing work that starts getting built too early (when it should really just be a starting point for a conversation), misinterpreting data or research, not gathering enough data or research, aligning on a framing for internal stakeholders, aligning on a framing for the people who will use the product, aligning on why this is the most important problem to be solving right now, accepting the opportunity cost of building the thing right now, aligning on how many people it will take to build the thing...

The list goes on. It's hard and messy and requires a shit-ton of meetings, one-on-ones, staring at whiteboards, and walks away from the desks. Some days I question everything and realize I know nothing.

But understanding is also the phase of the design process where I've learned the most about how to communicate and tell a story, how to match business needs with product goals, how to build relationships with cross-functional team members, and so much more. Tom Broxton's post (linked above) is a nice articulation of why it's important to know when you're in this phase, and when it's time to make the leap and build the damn thing.

Pushing and Pulling Goals

July 22nd 2016

The third part of it is that things done for push goals usually suck.

A problem is that I have a lot of short-term goals and almost no long-term goals; no career or skill-level long-term (5+ years) plans or strategies (aside from the obvious "be better" principle of growth). There's value in just letting things happen but this post about push/pull goals frames this lack of intentionality in a different way. Push goals force us to fit our thoughts and actions into a post-facto fabricated worldview. It's a way to find justification for doing the things we do after they've already happened.

I haven't met many people with goals beyond a year – or maybe five years, for the truly introspective. It's often the case that people realize how quickly things change, especially in the design industry when you never know what kinds of opportunities will pop up next month. So right now I'm just questioning what are the right kind of long-term goals (if any) and when is it okay to just let the waves roll in and deal with change as it comes?

Push versus pull goals – nice in theory, but challenging in execution at a long-term scale.

How to Think About Your Career

July 26th 2016

It’s precisely because I didn’t see my manager as a coach that I missed out on years of asking for and receiving training and feedback that would have helped me become better faster.

Coach, mentor, manager. These can all be the same thing, and sometimes – rarely – the same person. Julie's advice in her latest post rings true to me; one of the biggest level-ups I've experienced this past year has been finding a manager who acted as a coach and not as a judge. Someone who is willing to have honest conversations about the things that are going well and the things that I need to work on. And someone who pushes me to be a more valuable designer – both to the team, to the product, and to the organization; the trifecta of value.

The Heart of the Builder

August 12th 2016

The danger in user-centered design is that it releases the designer of the responsibility for having a vision for the world. Why have one when we can just ask users what they want?

Research is not as simple as asking users what they want. Good research identifies problems that people face, even if they are not explicitly stated as problems. Good research seeks to empathize and understand, not to ask for solutions. So while I don't disagree with the underlying message of this article, I do disagree with the proliferation of the idea that designers can go into a room alone and change the world.

The Future of Technology

August 23rd 2016

These are just a few of the amazing technologies we’ll see developed in the coming decades. 2016 is just the beginning of a new age of wonders.

Apps and websites are cool, but there's so much room for designers to impact the things that have yet to be invented. It seems prudent to not get too comfortable designing 2D screens.

Optimism

August 19th 2016

...part of what I will describe today will explain why it is difficult for people who feel optimistic and happy in life to understand people who are pessimistic and sad.

This is a fascinating post: a concrete framework for understanding why we are pessimistic or optimistic, with a discrete breakdown of factors, and a path to become a "learned optimist." I highly recommend this small post, along with – what appears to be – a healthy amount of follow-up books and posts. Being able to understand why someone has the outlook they do is important at a fundamental level for empathy, but also seems to be a prerequisite for change.

I'm currently working through "Thinking, Fast and Slow", and there is an entire chapter dedicated to optimism. Here's a brief excerpt:

Optimistic people play a disproportionate role in shaping our lives. Their decisions make a difference; they are inventors, entrepreneurs, political and military leaders -- not average people. They got to where they are by seeking challenges and taking risks. They are talented and they have been lucky, almost certainly luckier than they acknowledge.

This book has already had a profound impact on the way I think about the world, and I'd recommend it to anyone. But if nothing else, it's worth reading the chapter on optimism to understand the profound impact a mindset can have on your happiness, health, and success.

Developing UI

April 28th 2016

Visualizing all the discrete states an application can be in will make your design systems better. This in essence is the most pure form of a ‘living style guide’ and will help your design team develop a cohesive and modular design system.

And from the recommended reading, Pure UI:

The design and creation of an application serves a clear goal: the creative representation of some data a set of users are interested in.

States for network failure, stalled loading, failed server-side requests – these things might rarely happen, but at some point they will happen. I want the experience in any app I design to be as helpful and familiar as possible for people who encounter these edge cases. And to do that, it means considering these states early and not as hurried, band-aid after-thoughts.

The UI is not done until I understand what people using an app will experience in all possible states. But this requires a much more rigorous process than anything I've ever done. As always, there's a whole lot left to learn.

Session with Adam Michela

May 3rd 2016

Quora sessions have turned out to be surprisingly valuable – lots of tough questions for industry leaders, often accompanied by meaningful answers and discussion. The recent session with Adam Michela is packed with useful, practical advice for any designer working with software.

Here are some of my favorite bits, but be sure to check out the full session:

What tools do you think every design team should use?

I believe that design teams should be cognizant of that fact that, for many common uses, these tools do not create direct value. As such I believe that the use of and the time spent in any of these tools should be limited to the creation of artifacts that are necessary to inform the actual creation and alteration of software that is of direct value.

How technical do Product Designers need to be in order to be effective at their job?

A digital product designer must have practical technical knowledge to design a product which effectively delivers on the characteristics of utility, reliability, and efficiency. Further, that technical knowledge will greatly increase the degree to which they are able to design solutions that effectively improve upon the characteristics of desirability and usability with which they are already focused.

What's your interview process like for design candidates?

The job of a designer is to identify problems. Often this requires discontent with the status quo. Discontent must be balanced with a desire and drive to resolve that with which one is dissatisfied.

How do you balance art and design?

In design, it is common for practitioners to only claim responsibility for those first three characteristics. Desirability, Utility, and Usability. Early entrants to the field will typically take the most interest in attempting to deliver on desirability alone.

Do you think as a design community we are building the right tools for ourselves?

It is within these later stages of the contemporary software design process that organizational tensions and non-meaningful specializations are created. We expect production implementations of our interfaces to correspond directly — “one to one” — with our graphics and presentations regardless of their quality in reality. We as Design practitioners demand ownership of our interfaces but eschew the responsibility of ensuring they are realistic, robust, and complete.

Unlimited private repos

May 11th 2016

We couldn’t be more excited to announce that all of our paid plans on GitHub.com now include unlimited private repositories.

This is the first time I can think of in the history of ever that I'm now paying less for a service that I use more by doing nothing.

Hell yes.

PhotoViz

May 25th 2016

Nicholas Felton is back, this time with PhotoViz, a book about the intersection of photography and visualization. If you haven't seen Feltron's work before, just uh, go spend a few hours here.

See: Another preview of PhotoViz

Know the Business Model

May 31st 2016

“Like, man, this is a really nice office,” he recalls thinking. “Open floor plan, lots of really cool perks, the food. It just felt really modern. It felt like that startup kinda vibe I was looking for.”

Yikes.

Take the time to understand the business model of wherever it is you're working, or planning to work. That business model dictates company priorities and, for better or worse, should inform your decision on where to invest design effort. It's worth keeping in mind that sometimes the revenue can be quite far-removed from a project you're working on. The further removed a project is, the easier it can be to justify.

How Not to Fail

June 16th 2016

I’ve made startups sound pretty scary so far. I’m sorry, I can’t help myself sometimes, I’ve just seen so much. The good news is, this is a pretty complete list. If you avoid all the mistakes I warn about here, you’ll be in really good shape.

We stand on the brink of Spec being considered a true "startup" – I'm not quite sure what we really are. We technically have employees and revenue, we pay taxes and worry about things like growth and expenses.

But somehow it doesn't feel like a "tech startup" in my mind. And I'm not sure if that's a healthy or dangerous – either way this was a helpful article to read. It's a reminder to not get sloppy with revenue and expenses and to continually focus on providing value to the community.

Loyalty and Layoffs

June 20th 2016

Your career is yours and yours alone, whether you want it to be or not. The sooner you own it, and take responsibility for all of the consequences of said ownership, the sooner you will find yourself creating your own safety from the corporate predators who pillage and destroy in service to the soulless legal fiction they call your master. Not their master, by the way. Yours.

A perspective worth considering, especially given the amount of Kool-Aid that gets passed around in SF/SV. Having a backup plan is pragmatic. Becoming indispensable is a whole other game, and one I feel is worth playing. Perhaps I'm naive.

ELI5: Black Lives Matter

July 8th 2016

TL;DR: The phrase "Black lives matter" carries an implicit "too" at the end; it's saying that black lives should also matter. Saying "all lives matter" is dismissing the very problems that the phrase is trying to draw attention to.

via Kris Straub

The Apple Goes Mushy

July 29th 2016

Explaining how Apple has violated each of these last three principles, I will establish why that fact should sadden anyone who believes, as Apple once did, that using a computer should be easy, fun, and even gleeful

A worthwhile two-part read about UI design, clarity, and experience design in macOS. The author is quite scathing in dissecting Apple's UI and feedback mechanisms as they've evolved over recent years. Several of the points had me nodding in agreement – things are becoming less obvious and I find myself, more and more, having to hold the option key to perform so many basic functions that should just be exposed as buttons, or at least visible in a menubar dropdown.

My latest holy-hell moment with macOS was trying to find a way to speed up audio playback while doing podcast show notes (listening @2x is so much more efficient). Turns out there used to be a playback speed option in iTunes – gone. There also used to be a playback speed menu item in QuickTime – gone. I spent way too long Googling my way around this, trying to find 3rd party apps that wouldn't cost hundreds of dollars, like Logic.

Turns out, there is a way to change playback speed in QuickTime: option + j. Yup, option. Plus j.

It was bewildering to think that this couldn't be in a right-click menu on the play button or scrubber, or as an item in the menubar. I recognize that tradeoffs and ruthless prioritization needs to be made in software design. But this is functionality that has existed for a long time and used to actually be exposed as an explicit function for users to click. But now playback speed will never be found or used by anyone in QuickTime, forcing people like me down long rabbit holes of Googling and downloading 3rd party apps only to discover later that there are obscure shortcuts to solve these problems natively.

I want to end on a positive note, but it's tough. I think that macOS has become prettier over time. But when certain feedback mechanisms and affordances disappear completely as the software evolves, it becomes painful to watch everyday users struggle to perform basic tasks. I do feel some sense of relief in knowing that software like macOS is a work in progress – they'll keep learning and things will keep evolving.

I just hope it's in the right direction.

Humanæ

April 22nd 2016

The process followed in Humanæ also is rigorous and systematic: the background for each portrait is tinted with a color tone identical to a sample of 11 x 11 pixels taken from the face of the photographed.

What a beautiful project, not quite like anything I've ever seen before.

By Angelica Dass.

Aphantasia

April 25th 2016

I have no visual, audio, emotional or otherwise sensory experience. I have no capacity to create any kind of mental image of a beach, whether I close my eyes or open them, whether I’m reading the word in a book or concentrating on the idea for hours at a time—or whether I’m standing on the beach itself.

Crazy, I can't imagine in my mind's eye what it'd be like to not have a mind's eye.

Learnable programming

April 27th 2016

Likewise, a well-designed system is not simply a bag of features. A good system is designed to encourage particular ways of thinking, with all features carefully and cohesively designed around that purpose.

This is a fascinating read for any designer or engineer. It dives deep into different ways of thinking, how to illustrate and visualize complex systems and processes, and how the current state of tutorials and learning tools could be better.

There's still so much we can do to help the next generation of designers and engineers level up faster than ever before.

Uncanny valley

April 28th 2016

The internet is choked with blindly ambitious and professionally inexperienced men giving each other anecdote-based instruction and bullet-point advice. 10 Essential Start-up Lessons You Won’t Learn in School. 10 Things Every Successful Entrepreneur Knows...

A gripping piece by Anna Wiener with irony that is certainly not lost on me.

People I meet online frequently ask what it would mean to move to San Francisco, or the Valley, to join a startup or big tech company. And, of course, everyone has their own experiences – stories like the one linked above should be shared far and wide in order to paint a better, more nuanced picture.

But I never quite know how to answer. There are so many cultural problems here and things we do that must seem absolutely bat-shit crazy to the rest of the world. I'm reminded of this whenever friends and family from outside the Valley visit, each time I catch a glance saying you've got to be fucking kidding me.

But there's also a lot of goodness here, and an energy that's unmatched by any place I've ever been. And a lot of us are happy – people of all backgrounds and shapes and sizes.

Related, also by Wiener: Inside Silicon Valley's Big Pitch Day

Apple and podcasting

May 9th 2016

They can’t know exactly who you are, whether you searched for a new refrigerator yesterday, whether you listened to the ads in their podcasts, or even whether you listened to it at all after downloading it.

Big publishers think this is barbaric. I think it’s beautiful.

As a non-big publisher, this was a thought-provoking read about Apple's role in the podcasting ecosystem.

At Spec and Design Details we use http://simplecast.fm as our audio host – they provide us with basic stats like download counts, and based on IP addresses give us a basic understanding of our audience's geography. We also see a close guess about which app our shows were downloaded on (Apple's Podcast app, Pocket Casts, web browser, etc).

That's it.

There are some things we really don't care about, like knowing the search history of our individual listeners. Gross. But I admit it would be interesting to know more about listening patterns over time so that we could provide content at a better time or in a more meaningful way.

At this point it's up to listeners to initiate those suggestions to us in reviews or on Twitter. The downside is that we'll get less feedback because of the higher friction. That means, however, that the feedback we do get is incredibly valuable and can truly instigate change.

At times I find myself wanting more powerful data and tools for podcasts. Perhaps that desire is a side effect of the data-driven (see: data-obsessed) world we live in. But after reading Marco's thoughts on the potential consequences of centralizing, tracking and controlling the monetization of audio content it becomes more clear: it's just not worth it.

Firing People

May 17th 2016

That’s really been a hard lesson for me. I was pretty wrapped up in working there. It’s a broader concept, really, shoved down our throats in the tech industry. Work long hours and move fast. Here, try on this company hoodie. Have this catered lunch so you don’t have to go out into the real world. This is your new home. The industry is replete with this stuff.

This is my first encounter with Zach Holman's writing and it's not quite like anything I've read before: honest and transparent (as much as possible, it seems), critical, and thoughtful.

This particular piece was a long but particularly insightful read. Firing people, as it turns out, is complicated and nuanced. I love that Holman dispels the bullshit "fire fast" mindset right away – it's never that easy.

Software and services

May 18th 2016

Apple, by comparison, designs and builds products with a very distinct vision of what a product will do and how its customers will want to engage with it. This works well for hardware, just as it did for pre-Internet software. But it doesn’t serve to capture the unexpected or mundane behavior of people on the Internet, and it certainly doesn’t allow the company to learn or adapt as quickly as others.

Not only iTunes, but all first-party apps in general. Calendar, notes, mail, camera, photos, etc – a couple incremental improvements per year and a refresh with each X.0 iOS release feels archaic at this point. As far as I've heard, there is a very small team of designers that works on first-party apps, so this makes sense from a bandwidth perspective. But it's an underinvestment, nonetheless.

Replay

May 24th 2016

I'm not one for book reviews, but Replay ranks up there for me in the list of thought-provoking and fun-to-read stories. The premise of the book is interesting enough, but the way Grimwood tells the story peels back layer upon layer of complexity and nuance that I'd never really considered in the time-travel-ish genre.

I'm beginning to lean much closer to the type of sci-fi that feels more grounded in modern reality. The kinds of stories that, with a small stretch of the imagination, seem possible, if not plausible. Books like Replay and Ready Player One come to mind.

Do you have any other recommendations?

Starting from scratch vs. frameworks

June 14th 2016

Building from scratch versus frameworks: a long-standing question and struggle of mine that still needs resolution. I have a perverse fascination with building everything from the ground up. It's very satisfying to say I built this whole thing. Look at it. Yes, I know this is dripping with ego: I'm trying to be better.

My mindset is starting to shift, although it hasn't been an easy path. Lately I've accepted that code is just a tool. It's not the product (in my role as a designer). No, it's a tool to build the things that can solve problems for people; a means to an end. So sure, it's fun and satisfying to build things from scratch, but it's also like building my own hammer any time I want to hang a picture.

Code is a tool indeed, and we live in an amazing time where there are countless free tools at our disposal to use and learn from. The big hurdle, of course, is coming to know the proper way to use that tool: understanding its architecture and opinions and prescriptions. But that takes less effort than building the thing from scratch.

Perhaps this way of thinking is quite obvious to many people out there. I'll admit my ignorance and ego. In the meantime, I'm going to try and spend the next few months getting out of the weeds to see the bigger picture and solve problems for myself and others, even if it means conforming to someone else's framework or mindset.

On components

June 17th 2016

Premature optimization is a trap that’s easy to fall into. Embrace the chaos as you build. Patterns will emerge from the primordial goop of UI that is your product, and by consistently thinking about a composable system you’ll probably come up with something more flexible and more robust than if one person dictates a dogmatic framework to work within.

I struggle with the chaos and spend way too much time building, then abstracting, then building again and getting stuck in an endless loop without much progress on the final product (as it relates to side projects). I know that there's a balance between done and perfect, but I still struggle with thinking too far ahead and prematurely optimizing for that vision. Jackson's thoughts on systems are a helpful reminder that I'm not alone.

Don’t Get Surprised by Burnout

June 21st 2016

To a doer, the inefficiency of these gaps can feel frustrating, so we check our mobiles while we wait, or schedule calls for our commutes. But if we’re comfortable with not-doing, we can take these as opportunities not to do, but to rest.

It feels as though, more and more, the only way to escape this trap is to be somewhere without access to the internet. Either that, or build an incredible practice of discipline and self-restraint to avoid filling every down moment with Twitter, Facebook, Social Media, etc. Both options are equally difficult to achieve, and that's been the most troubling part for me.

How to get value from wireframes

June 30th 2016

After a decade in the design world, I’ve learnt that how something works or why something is the way it is, is much more important than how something looks. Senior designers spend much less time on cosmetics, and much more time validating that they’re going the right direction.

Looks are still important, too, of course. But I subscribe to Dustin's underlying point all the same: if the thing doesn't work, or solve a meaningful problem, no amount of polish will make it valuable.

Metrics Versus Experience

July 7th 2016

Being able to measure stuff gives you insight into what people are doing within your product. Unless you like living under a rock, having more information is a good thing.

Data is only another input. The latest semantic tweak is to say "data-informed" instead of "data-driven." And I agree with that: data is one more lens through which to look at a problem. Qualitative research, taste and style, strategic bets...those are other lenses, and when used in tandem can solve bigger, more complex problems.

Julie's post here is solid and provides a lot of talking points to anyone who might be trapped in a "data-trumps-all" workplace. It's not a panacea. It's a lens and a place to start a conversation.

Pre-Touch Sensing

May 5th 2016

Another fascinating Microsoft tech demo, this time showing us how a capacitive touchscreen can detect pre-touch events.

The most interesting piece to me is detecting rate of motion both before and after the physical touch event as a way to determine intent. This could be used to refine smaller tap targets, improve one-handed usage, fine-tune precision input, and more. Exciting stuff.

Alan Kay AMA

June 23rd 2016

The start of a better way is similar to the entry point of science "The world is not as it seems". Here, it's "As a human being I'm a collection of traits and behaviors, many of which are atavistic and even detrimental to my progress". Getting aware of how useful cravings for salt, fat, sugar, caffeine, etc., turn into a problem when these are abundant and consumer companies can load foods with them....

Seriously, seriously fascinating AMA with Alan Kay. The topics are incredibly varied and insightful, expanding far beyond computer science into areas like information, entertainment, human development, and the future. I had a blast reading this – I think there's a topic in these conversations for everyone.

The 7 biggest problems facing science

July 21st 2016

Today, scientists' success often isn't measured by the quality of their questions or the rigor of their methods. It's instead measured by how much grant money they win, the number of studies they publish, and how they spin their findings to appeal to the public.

A fascinating piece exploring the state of the sciences and some of the biggest challenges the field is facing today. The study is overly-broad, and perhaps not scientific itself, yet it offers an interesting exposition of the affects an incentive structure can have on an entire community. The piece raises murky questions in my mind about what kinds of parallels we might look for in the design (or broader tech) industry.

Lately I've been trying to understand the incentive structures (explicit and implicit) that shape our behavior every day, as well as their downstream effects on our output and decision-making process. In doing so I realized how little I know about why we do the things we do as it relates to incentives and the implicit agreements we make every single time we show up at our desks. I'll be reading up on some contract theory for now – if you have any book suggestions I'd love to hear.

Fan.tasia

July 25th 2016

It's special when something like this comes out – I can't begin to imagine how much work went into cutting each of these transitions. Unreal.

Employee #1: Tumblr

August 16th 2016

Life is really about trying to make the most of the luck that you have. And I think startups are that way, too.

This series of interviews with first employees has been fun to follow. In this case, Marc LaFountain became the first employee at Tumblr after sending a cold email to David Karp. Talk about good timing.

A few things stand out about this particular interview: the importance of support and non-technical roles, working with the tension that exists between technical roles and support, and – importantly – setting personal limits while working at a startup.

When I worked at Buffer we set up a weekly practice of having every employee doing at least one hour of customer support. I remember missing a lot of weeks (shame on me), but the times that I did jump into the inbox were enlightening and one of the best exercises in customer empathy I can imagine.

April 6th 2016

We do so through the digital footprints left behind on Facebook and Twitter, the photos on our smartphones, and all the morsels scooped up by search engines. Technology allows us to connect.

The Borderlands

May 13th 2016

These borderlands are the best place for a designer like me, and maybe like you, because the borderlands are where things connect. If you’re in the borderlands, your different tongues, your scattered thoughts, your lack of identification with a group, and all the things that used to be thought of as drawbacks in a specialist enclave become the hardened armor of a shrewd generalist in the borderlands.

Things Not to Say On Stage at a Tech Event

July 6th 2016

Granted, most of us grew up in safe environments and were lucky enough to have free schooling. But there are a lot of people in our midst who came from nowhere or at least nowhere near computer science. And they do great work. I’d go so far as to say that the diversity of backgrounds made the web what it is now: a beautiful mess that keeps evolving into who knows what.

These types of articles are my favorite: specifically targeted at engineers and programmers, but are 100% applicable to designers. In this case, the post talks about the times our words may sounds inspiring and helpful, but in fact have the opposite effect on an audience.

If you're about to / have previously given a conference talk, this one is worth a read.

Stop the overuse of overflow menus

July 25th 2016

Admitting you have a problem is the first step to solving it. Many teams don’t acknowledge that using an overflow is a crutch, a way to avoid making a tough choice.

An impassioned piece from Daniel Burka asking us to think harder about the crutches we rely upon while designing complex software.

The Squeeze

August 29th 2016

After last week's post on overwork and burnout, several people reached out expressing similar struggles. Some felt relief that they weren't the only ones feeling a pressure to always be producing.

For the last few years I've had a loose mental model of a way to help myself deal with highs and lows. I'm sure I've read it somewhere before, or someone helped me create this model, but unfortunately I can't remember. So I take no credit here, but just share it to hopefully kick off more discussions.

Alright, let's get hypothetical for a bit.

Suppose this is a made-up person's happiness. This person doesn't have highs or lows, and we might call them perfectly content:

This horizontal line represents baseline happiness. It represents being neither joyful nor upset. It represents things going well, things feeling steady and being generally predictable.

Of course, this person doesn't exist. This figure is a more realistic representation of an average person's happiness over time:

I can look back on times in my life where I was intensely happy, or maybe not doing so great, and moving between those extremes every few months as external conditions changed. Maybe it was a crappy project at work, or something happening with a relationship – for many reasons, I experienced extreme fluctuations above and below a baseline of happiness.

Note: My x-axis is on the scale of months. Daily high/low fluctuations might be signs of other things going on mentally, which I can't speak to.

A few years ago someone taught me about a new mental model that aims to reduce the height of the peaks and the valleys of the lows. Extreme fluctuations over time are unpredictable, indicate a reliance on external feedback mechanisms, and don't feel healthy. The lack of consistency and predictability can make life feel chaotic or unfair.

Enter a model which, for lack of a better name, I'm calling The Squeeze™. The Squeeze is about using internal feedback mechanisms (aka self-awareness) to move yourself closer to baseline. It's about recognizing that long-term sustainability can be improved by increasing the predictability of your life.

It looks something like this:

After the squeeze, your happiness over the course of a year might look closer to this:

Notice that we're not eliminating highs and lows, peaks and valleys. We're not trying to lift all the valleys upwards and extend the peaks. No, we're trying to move closer to the middle, the baseline where things are predictable and driven by internal narratives.

Implementing The Squeeze is hard. It takes self-awareness, and it's easy to forget when you're at the most extreme ends of a peak or valley in your life.

The thing I like about The Squeeze is that it applies to way more areas of my life than an ambiguous happiness level. It applies to the way I think about work and relationships, exercise and discipline. It accepts imperfection, but strives for consistency.

Here's exercise. The gray line represents consistent growth and action over time. In my world that would be 4 days of exercise, one hour each day, every single week. I remember in high school and college I would go through the most extreme peaks and valleys of an exercise routine. For 3 months I'd be on-point, exercising nearly daily, taking care of my diet, and feeling great. Then I'd burn out, take 3 months off and lose everything I'd worked for.

It was exhausting. I remember being so frustrated that I could never see long-term results. There were only short-term gains in those 3 month sprints. I'd be riding a high, feeling good, getting stronger, only to suddenly tip and fall into a valley where ice cream for dinner was an acceptable cheat meal.

Thinking about exercise within the scope of The Squeeze looks more like this:

I'm always aiming for baseline. That consistency is an ideal. But I understand that life isn't consistent, so I embrace it but remain mindful of whether I'm above or below that baseline. Success is squeezing towards the center as much as my mind will allow, fighting for consistency and growth. But to miss a week, or even a day, doesn't cause me to tip and quit completely.

I like The Squeeze because the model helps me to deal with productivity:

And relationships:

And almost anything else that is impacted by time as a variable.

The Squeeze isn't a one-time thing either. You don't just do it and then feel better. It's a constant effort and practice of introspection to find consistency and balance. It takes discipline to not become overjoyed by external factors, and inversely to become depressed when things aren't going well.

Here's a more ideal world, for me:

I'll quickly talk about some arguments and questions about this model, and how I've wrestled with them:

  1. The Squeeze would make life boring

  2. Why should I Squeeze towards the center, instead of just pushing up from the valleys?

  3. Why would I want to dampen the peaks of happiness/productivity/x in my life?
Hacks on hacks

September 13th 2016

Put these three stooges together and you get where we are today. Rewriting the same damn app every year in another framework in what can only be described as some sort of high paying purgatory.

I still love the web. It's what I grew up learning, and I've had fun over the last few years digging into new frameworks, building understanding in Javascript, and trying to wrap my mind around new concepts like CSS modules and JS-powered stylesheets.

But the key thing is that most of my web dev knowledge has been acquired through solo projects, or in the worst-case scenario, with two to three collaborators. The comments in this HN thread revolve around this same situation (albeit more cynically): web development isn't inherently broken. However, as a system for collaboration, things become incredibly messy in no time at all.

For the past few months I've turned to the web as a prototyping tool, and one that's incredibly fast to ramp up and demonstrate proofs-of-concept. Want to declaratively build a UI from a JSON tree? Maps to the rescue. Need to build a dozen components and understand how they function under the constraints of different operating systems and screen sizes? A quick CSS class, or dynamic inline-styles, takes only a few minutes to wire up.

React has been a massive level up as well, and with all the tools the community has built in the last year, it feels like we're on the right track.

Of course, this strays from the original point of the HN thread, which is mostly about building full-scale web apps. But I still encourage everyone to learn HTML/CSS/JS – I've found this knowledge to be incredibly rewarding, and has now become one of my best friends in prototyping.

Copyright © 2016
TwitterDribbbleInstagram