Back to School

View of the Groote Kerk in Dordrecht from the River MaasAelbert Cuyp (Dutch, Dordrecht 1620–1691 Dordrecht) From the collection of the Met

Did you get a whiff of autumn in the air the other day? I certainly did, and memories of going back to school came flooding back to me. It's especially poignant because I'm going to be on the other side of the lectern this year teaching an evening undergrad class — Interaction and Communication — at the School of Visual Arts.


Why teach, and why now? I'll admit that for years I've considered teaching but I've often lacked the confidence and motivation to do it. As an introvert it was a scary prospect to have to stand in front of a group of people and capture their attention for hours at a time expounding on a topic. I always felt like I needed to be more of an expert...well, at basically everything. I've come to the conclusion that the feeling will never go away and it's better to interpret it as a desire to learn. Having to be responsible for someone's educational experience seemed like a huge burden that I wasn't ready to take on.

 And that's exactly why this moment feels like the right time to teach. Given that many of these students will end up in the tech industry, what questions are they asking about what they're designing? These are the students that will one day be shaping the experiences of millions (if not billions) of people. Will they be asking the "for whom" and "why" questions, the really hard ones? Design shouldn't just be paying lip service to empathy. If designers are supposed to be user advocates, we need to do a better job as a discipline to consider those questions and be prepared to persuade our colleagues to stand behind them. Asking these questions from the beginning means we're making products, services and systems more humane - in the sense that we're making them for all humans, not just a small privileged subset of them. 

And this starts at the foundation. Students need to get comfortable asking "for whom" and "why" from the beginning; of course the "how" is important, but the most beautiful app that has really clever interactions is abhorrent if it supports and enables harassment or discrimination. It's so important to understand how to critically think about the existing structures and systems around us and imagine different experiences and outcomes. 

 So yea basically I needed to get over my fears because this is so much bigger than me.


At SVA there's complete freedom to build the course curriculum and set grading policies, and they believe that the most effective teachers are active practitioners in the field. On one hand that's awesome, the curriculum can emphasize what I believe are the essential principles in approaching design and I can choose exactly how to structure the course. It's also incredibly daunting to write a course from scratch - the first thing a friend of mine who's taught undergrad said to me is "don't write your own curriculum from scratch the first semester you teach, I really regretted that." Sooo what am I doing? Ignoring that advice. (Mainly because there *is* no standard course to base anything off of, every section is unique to the instructor.) 

Derrick and I have been shaping the syllabus over the course of the summer and it reminds me a little bit of the process of doing a perspective drawing. Find the measure, mark off the drawing surface with the measure, and roughly lay out the structure. Then go back in and layer on details with increasing fidelity while keeping the whole drawing in mind - you never focus too much on one spot or it'll become unbalanced. But it's ok to not work up the entire drawing in excruciating detail, it's finding the right places to add that detail. You have to periodically fuzz your eyes out a little bit to see the big picture. 

 I've been considering the flow of each session but also how each session has to flow across the entire course. Does it all connect? Do the concepts in one build to the next? Where do the outlier topics go in the sequence? They're important enough to cover but stop the flow in some way. How early in the semester can I introduce a concept? Is that concept better conveyed through a lecture, discussion or exercise? Is this too ambitious for a semester? Rather than trying to answer those questions right away, we started with a rough outline of the semester and we've been moving, tweaking and refining the structure as we add a little detail to each session. 

It feels very meta in that I want to do some user research on students before even writing this syllabus because creating a course *is* a design project. What level of knowledge can I expect? What are their work habits and attention spans like? What assumptions am I making about how they work? Leaning on educators for anecdotal evidence is what will have to suffice, for now. We'll iterate as we learn more about our students, so I suppose the syllabus in its current state is our MVP. I've also started questioning what my pedagogical beliefs are and that I don't really have a great perspective on that! So I've given myself some homework so I can feel a little more grounded in the why's and how's of teaching. 

 If anything this is forcing me to brush up on things I thought I knew, but from the perspective of explaining it to someone who has no knowledge or experience of the thing you're talking about. It's given me fresh eyes as I've been flipping through reference books and reading articles I saved forever ago. I've been considering what got me excited about being a designer and figuring out how to convey that excitement. I want them to walk away from this class feeling like they've only touched the surface and that there is so much possibility for helping shape the world around us in meaningful ways. 

Ideas? Tips? Send them my way!

Thanks to my co-instructor Derrick Schultz who asked me if I wanted to teach this course with him and gave me the kick in the butt to say yes. I'm so grateful to all my friends and colleagues who have been involved in education that have put up with my pestering to give me tips and advice. 

Daily Routine

Once in a while I review this “Daily Routine” list I made ages ago in a to-do app. I’ve never checked anything off of the list because they’re always in a state of “to do”. Doing items on this list help me stay grounded.
  • Push-ups
  • Karate or running
  • Cook something
  • Write something
  • Water plants
  • Draw/paint/sketch 
  • Read something thought provoking or inspiring 
  • Make space 
  • Drink enough water 
  • Eat vegetables 
  • Get rid of something unneccesary
More than ever, I need this list. Too often I get sucked into the spiral of social media that feeds my sense of helplessness and, now, fear. I refuse to be paralyzed with fear. I refuse this helplessness. 

What I *will* do is create and engage. 

Shortbread: The Best Cookie

Lemon Thyme Shortbread Cookies

I’m a secret cookie hater. Ok, not cookie hater. It’s that I prefer cookies where you can actually taste something besides sugar. I'm also not big on the fancy icing and decorations, they always seem to be taste better than they look. So this year, for the annual Serious Eats cookie swap, I decided to make a shortbread that veers a little towards the savory and aromatic side. I couldn’t seem to find a definitive shortbread recipe that fit my ideal criteria - a little crumbly and not overly sweet - but came away with a few tips:

  • Using a finer-grained sugar like caster or confectioner’s produces a smoother texture.
  • I noticed that some shortbread recipes call for egg, but I decided it against it. I was afraid that I’d lose the crumbly texture and veer more towards a chewy cookie.
  • Adding a ton of lemon zest won’t hurt.
  • Try to find the best/highest quality butter you can. Wayne scored some kind of grassfed organic butter from Organic Valley with a high butterfat content that had that strong buttery smell when you open up the wrapper. I'd go for Kerrygold or Plugras as well. Since shortbread is made mostly from butter that’ll make a big difference in the end.
  • Use salted butter instead of unsalted to avoid the overly grainy texture. 
  • Creaming the sugar is important, don’t skip that!

Lemon Thyme Shortbread

Yield: 72 1/2 inch rounds
Adapted from this recipe


  • 1.5 cups salted butter 
  • 1 cup powdered sugar 
  • 1/2 teaspoon kosher salt 
  • lemon zest from 2 large lemons 
  • 2 teaspoons lemon juice 
  • 2 teaspoons fresh thyme, stems removed 
  • 3 cups flour


  1. Mash the salt and fresh thyme with a mortar and pestle. The goal is to release the oils from the thyme leaves and to break down the kosher salt crystals. 
  2. Cream the butter and powdered sugar together. I used a KitchenAid stand mixer with the paddle attachment, but whatever floats your boat. 
  3. Add the salt-thyme mixture, two teaspoons of the lemon zest and lemon juice and turn the mixer back on low until these ingredients are incorporated evenly. Reserve the additional lemon zest for later.
  4.  Add the flour and turn the mixer on low to medium. It’s done when the mixture pulls up from the sides of the bowl and clumps on the paddle. 
  5. Wad the dough up into two equally sized flat discs. Wrap with plastic wrap and refrigerate for at least an hour. 6. Preheat the oven to 350 degrees. 
  6. Place the dough on a floured surface. Sprinkle some lemon zest on evenly as you roll the dough out to a 1/4 inch thickness. The rolling action will incorporate the lemon zest into the dough. Remember to use half the zest on the first piece of dough. 
  7. Cut out pieces at your desired shape and size and place on a baking sheet. Bake for 15 minutes, but be sure to check at the 10 minute mark. The edges should be golden brown. 
  8. Remove from oven and place baking sheet on a cooling rack. You can optionally sprinkle with a little kosher salt as soon as they come out of the oven for a salty kick.
  9. Enjoy!

Editorial Design is a Team Sport

Where to Eat Chinese Food in NYCscreenshot of the final project

Editorial design on the web tends to manifest in two extremes: a one-size fits all “here’s a container, fill it with content” template and gorgeous one off custom projects (you’re probably thinking Snowfall right now, but there are some great ones here). The ability for a publisher to execute projects like that is affected by so many factors: available resources, dealing with the limitations of legacy CMS’s, the relentless pace of publishing. I admit that I’ve felt pangs of jealousy when I see great editorial projects (and admiration, of course)!

Often I look at our tiny Product team of two and think, how can we possibly achieve that level of quality and to make it useful more than once? (Haha try to justify the resources for a Snowfall-esque piece gives me anxiety) A voice in my head says don’t even try to go there. 

 Over time, though, I’ve realized that it’s not about having a huge team or a pile of money to pull it off. The secret ingredient to great editorial design is the effort that designers put into fostering a collaborative environment across disciplines. 

 1. Talk It Out 

Every step in the process should facilitate communication. If you notice it doesn’t, throw it out, modify it or find a better way; there’s no excuse to say “that’s always the way we did it”. Designers, sorry to break it to you but the era of the “big reveal” is over. Slack (I know people go ON about it but it’s still worth saying) has become a key part of our process because we can quickly iterate on the idea by throwing ideas back and forth, there’s no need to wait for a formal meeting to get feedback. Constantly ask “How can we make this better? How can we make this more useful?” By working on everything in parallel — written content, illustrations, photos, design, code — the team is encouraged to communicate and make incremental improvements together. 

Desktop PrototypePresenting different ideas for integrating the map in the desktop view [link]

 Choose the design tools that best help convey your ideas. I recently picked up Sketch — not because it’s new and shiny — but because it’s trivial to create storyboards to demonstrate variations on interactions. When reviewing with the rest of the team, I could see a lightbulb go on in their heads that doesn’t happen with Photoshop comps. They asked more questions, pointed out holes in the interactions and started thinking about how their own pieces fit into the puzzle. Design work improves the more feedback we can elicit from our fellow team members. Constantly evaluate your toolset and choose the ones that are most appropriate for the task. Sometimes it’s a paper prototype and other times it can be a mockup in framer.js. Sure, it takes time to learn how to use new tools and methods, but the investment is worth it if it means your team more clearly understands what you’re trying to convey. And you need to meet your team halfway when asking for feedback; be specific about what you’re looking for and lean on their expertise. 

 2. Content is King! Or, Content Early, Content Often

That said, I’ve found that I can design theoretically in a tool like Sketch or Photoshop until the cows come home but I won’t know if it works until there’s real content paired with interactions. Designers need to push to get content into context as early on in the project as possible. Lorem ipsum is not your friend, your team is! New ideas and suggestions for improvements happen much more quickly when the whole team can see working interactions, so design in the browser as soon as the team’s agreed on a general direction. Set expectations with editors and writers to deliver at least a draft while you’re still exploring ideas.  

Mobile PrototypeContent looked alright in the Sketch prototype but was a pain to scroll with 60+ venues [link]

And don’t assume that this guideline only applies to written content. This is critical for visual assets too, especially when responsiveness is a requirement. We had the luxury of hiring an illustrator for this project, but we hadn’t nailed down exactly how the illustrations were going to be used. We had the illustrator start a month ahead of time and requested files that would give us the most flexibility: largest file size possible, layered files, transparent background. That way we weren’t boxed in when it came to figuring out how best to integrate the illustrations with text across all screens. 

3. Reduce, Reuse, Recycle  

Editorial design often falls to internal teams to execute, and I see that as a huge advantage. Rather than having to start over from scratch on every project like an outside consultant would have to do, the team works towards building institutional knowledge and skills. It gives designers an opportunity to solve problems that are very specific to the workflow and content needs of both editors and readers over a much longer period of time. Smaller, incremental iterations help reduce risk and — perhaps counterintuitively — allow for greater experimentation. 

 Over time we’ve built up a library of custom tools, styles and code through projects like the United States of Burgersbeer mapgift guide and collections. Although at first glance they seem like one-off projects, we’re always thinking about reuse; everything the Product team builds is a springboard for future features and the most successful components can be rolled back into the main site. With a consistent feedback loop, the whole team can decide what looks like success and think creatively about what can be recycled. 

4. Understand Your Limitations and Work It 

Limited resources and a deadline can actually work in the project’s favor. It enforces discipline and a laser focus on the whole team, and goes hand in hand with principle #3. If the team’s been working together for a while it’s much easier to estimate scope. Strip everything down to the most essential (without cutting corners) and prioritize the features you’re going to release (or not). Reuse and steal like crazy from previous projects. And ask “Is this truly useful or are we being overly ‘creative’”? 

 Within these limitations, the product designer still needs to evoke empathy for the user in everyone on the project. As the intermediary you’re helping to negotiate the balance between the two. Give the Editorial team choices and consequences — “we can do this and this will be the effect, or we can focus on this and it would provide XYZ.” Too often, with no deadline and lots of resources, you can end up spinning your wheels with lots of experiments but nothing gets decided and consequently released. Use the limitations to help launch. The project will be that much stronger by empowering everyone to make the decision together. 

5. Tear Down the Walls 

Paul Ford’s recent post about the dress and Buzzfeed reinforced my belief that the first four points are worth nothing without establishing a strong culture, because honest communication can’t happen without building a level of trust. 

 One of the easiest ways of doing this is actually spending “non-work” time together. Parents — don’t worry, I’m not talking about spending all the free time you don’t have with your colleagues. Coffee or tea or a meal together away from desks during working hours can spark discussion. (Yes, this is Work with a capital W.) This is critical, I’m not joking : the more time you spend building relationships across teams so you can be honest with one another, the better it is for communication and thus the projects you’re working on. The team develops a shorthand for communicating that can only be built up over time, it’s not something that happens over night. It’s also about getting everyone excited about the aspect of the project they’re working on, and when you can see how your piece fits into the puzzle, everything clicks and you can move together towards the same goal. This should be taken as a team wide responsibility and not just the designer’s. Break down the walls between editorial and product! Change the culture! 

Great editorial design is an artifact of Editorial and Product teams collaborating across disciplines and not based on resources alone. Designers are uniquely positioned to act as the glue across those teams. It’s a part of our responsibility to do this; in the end, isn’t our job ultimately about facilitating communication? We have to stop seeing our role as only addressing the needs of the “end user”, we also must invest our time into improving our working relationships to enable everyone on the team to produce our best work. 

Thanks to the kickass team who I worked with on the Best Chinese Food in NYC project and served as inspiration for this: MaxPaul, and Vicky!

Thanksgiving 2.0

Thanksgiving overhaulSeasonal content always gives us an opportunity to improve the design and functionality of the site. (Compare to the Topics page design from the year before.) [link]

Last year the product team focused on just getting *something* together for Thanksgiving on a tight deadline, but this time we had the luxury of an existing code base to work with, a year's worth of experience making these pages, and a much longer lead time. One of the things that I really enjoy about working on a site with lots of evergreen, seasonal content is that I have the opportunity to revisit ideas, put gained knowledge into practice and make improvements. We decided to focus on integrating a new visual design language, refactoring the existing code and improving the editorial workflow.

Over the summer we worked with a design firm on a new visual design for the site. Updating the Thanksgiving section was the perfect time to execute the new look and feel and build our stylesheets from the ground up because it's mostly self contained. The current site relies on Bootstrap, but it's been feeling too kitchen sink-y and I often find myself overriding many default styles that I didn't need in the first place. I chose Bourbon after evaluating other frameworks like Pure and Foundation as it seemed the least obtrusive and most flexible. Although there was a bit of an adjustment going from LESS to Sass, I'm happy that I made the switch. Bourbon (and its related packages) has a tiny footprint compared to Bootstrap and the extends and syntax help keep the project more organized. Semantic naming for layout and columns is supported and the responsive grid is easy to modify. I set up naming conventions based on SMACSS principles, which should allow us to scale the stylesheet more easily and enable others to jump in and contribute with more consistency. Moving towards packages managed on the command line will enable us to keep the framework at the most up to date version.

We also refactored the template code with what we've learned over the past year by chunking out blocks of functionality for reuse in other areas. Just as we're approaching the visual design in a more modular way, we've been creating patterns with context based rules.

Lastly, we set up a new way of collecting questions from readers. Rather than just soliciting questions in comments or Twitter, we set up a form on the Thanksgiving landing page It was important to build a solution that fit into the existing editorial workflow, as the editors would be more likely to use it since it's less cognitive time spent on learning something new. Considering the size of the Product team (two!!) it was also imperative that we follow the path of least resistance and quickest implementation. 

When a reader submits a question, Formstack syncs the submission to a Google sheet. An editor reviews and copies approved questions into the master spreadsheet, and a script exports the data as a JSON file on the server. Google spreadsheets are already a part of the daily workflow and the data can be easily updated with a single command. We had used this technique in previous projects inspired by this solution, but this time we made it into a reusable script customized for our environment and data. (And we were heartened to know that other publishers are using a similar technique!)  We're excited about using this for an upcoming gift guide and ideas that require more flexibility than our current CMS allows. One tradeoff of flexibility that we've run into is that the process can be prone to error; we can't lock down parts of the spreadsheet that are crucial to exporting the JSON file (column headers, anyone?), so we'd have to think about error handling to make this process scale better.

The biggest takeaway, for me, is how tightly visual design and front end development have become woven together; in fact, I don't really see much separation between the two. Projects are most successful when they're taken through an iterative process and it's especially crucial for responsive design, where I need to see it in action before I can decide whether or not it works. And overhauling a limited area of the site is much less risky and allows time for testing. It also gives us the opportunity to refine the design because we can see it in the wild and get feedback -where does it not work? How can it be improved? Where can we take chunks of design and code and make them reusable in other places? Ultimately I hope that the experience we've put together will help improve everyone's Thanksgiving game!

In Need of a Haircut

Responsive viewsExample of responsive redesign that launched in August of 2014. [link]

Last month we launched some updates to Serious Eats - the site hasn't had a major visual overhaul in a few years, and we wanted to address some immediate issues while working on a larger reorganization and redesign project in parallel. We weren't adding any new features, if anything we were focused on paring down and identifying what could we do based on what already existed.

The percentage of visitors on mobile and tablet devices has steadily increased and, although our overall traffic has been going up, the time spent on the page has slowly been decreasing. A few years ago we had experimented with a mobile site that served stripped down pages from a mobile sub domain. It became neglected as it was a completely separate set of templates, which meant double work to keep feature parity. We wanted to stop using the "mobile" templates, make the existing design responsive and have one canonical URL for any given piece of content.

Going responsive was an immediate fix, with the goal of increasing the time spent on page and more pages per session. But going responsive for a publishing company doesn't just mean adding media queries to the stylesheet. We had to consider how advertising was going to be integrated at various widths. We settled on using an asynchronous loading method so we could load the correct size depending on the screen width. And given the timeframe, we settled on a single breakpoint at 768px. To solve for the less than ideal width in portrait view on tablets, the viewport metatag is omitted to force the viewport to zoom out to display the (wider) site within the screen. It's a handy hack!

The site was also badly in need of a cleanup; over time, pages had become cluttered with unnecessary widgets, colors and scripts that were just adding visual noise and slowing the page down. There was also a proliferation of styles as various projects were launched, and we wanted to make the styling more consistent across the board. Internally we dubbed this project "the haircut". We wanted to get out of the way and let readers read!

 And finally we had to change our templating system. (Not a small task, props to Paul!) We had already built a number of projects with ChApp and we were finally ready to cut the cord with using Movable Type to render pages. MT is now set to publish JSON feeds while ChApp handles all the rendering logic. ChApp gives us more flexibility and we no longer need to rebuild the entire site, we just push the templates via git and restart the server only if settings have changed. 

But we had to do it in two stages: first recreate every template in ChApp that mirrored the old blog structure, then we worked on consolidating the templates. We now have a single template that renders stories and one that renders recipes; we previously had one story template per blog. There are still a few dynamic templates like user profiles and registration that MT handles, but for the most part we're now on a much more flexible platform where we can make changes much more quickly and easily. It cut our launch time down to about an hour - compare that to the last major update, which took four or five hours and then a site rebuild over another day or so. And it gives us the ability to make much quicker releases rather than having to wait to rebuild the site to reflect any changes. 

So the big question is: how effective has the haircut been? It's consistently more than doubled the time on page and decreased the bounce rate by about 10%, and the page load time has decreased on average by 4 seconds. Readers are thrilled that the content is optimized for reading no matter what kind of device they're on. 

For the future, we want to continually focus on performance. For instance, we want more control over displaying images so we can serve the appropriate size according to bandwidth and screen capability. We're also in the midst of a larger taxonomy project to dramatically improve the search experience, especially for recipes. And we're making a bigger effort to surface evergreen content - we started doing this with a custom-built related content widget at the bottom of posts - and will extend to bigger projects like what we've been doing with our holiday collection pages. So stay tuned!