My eyes are definitely bigger than my stomach.


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

 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 prototype but was a pain to scroll with 60+ venues

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 overhaul

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

Same content, different views

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! 

Making Sandwiches

I do admit that I get to work on some fun stuff at Serious Eats. The process for building the sandwich page was a great example of a successful collaboration between editorial and the design/dev team. It was a quick process - Kenji came to me and Paul with the idea on Monday afternoon and we had launched it on Friday. Over the past six months we've modularized a lot of our code so it's pretty easy to drop components in without having to worry if they work or not. 

Kenji showed us an idea he had for a sandwich graphic - he wanted it to be more interactive and possibly with some animation. 

Kenji's concept sketch for the sandwich page

Talking through, it seemed like it was a bit more straightforward than the maps we've done in the past, plus we had some code that we had already written that could be reused for this project. 

First I created quick and dirty comps in Illustrator to establish a clear look and feel. I've switched to Illustrator recently after having been a die-hard Photoshop nerd when it comes to comps - I love the multiple artboard aspect, it's perfect for working on proposed interactions at various screen sizes. I wanted the sandwich layers to pop off the page, but have a more refined sense of typography that I've been trying to work into some of the seasonal pages and maps. I focused on organizing the layout in a way that would make responsive aspects easier since we knew we had a tight deadline. 

Illustrator comp for sandwich page

Kenji had also prepped all of the photography ahead of time into transparent layers, so it saved me an enormous amount of time when it came to prepping the artwork for use in the page. I exported each layer of the composite Photoshop file into a png so that we could wrap the img tag with a div, assign a unique class name, and independently manipulate each layer with javascript.

Paul looked at a number of animation libraries and he chose animate.css. It's lightweight and comes with a number of nice CSS transitions. CSS transitions seemed the way to go for animations since they're supported in modern browsers. The content was collected in a google doc spreadsheet. That way Kenji could make a custom data structure, add and change content as he went, and have other editors review. All Paul had to do was match the data structure on the front end, export the sheet as JSON and drop it onto our static server. This is a piece we'd like to automate a bit more at some point though. 

This was the perfect project to take advantage of the programmatic aspects of LESS to make the CSS writing faster and trivial to update. Each layer of each sandwich has a slightly longer delay than the next, so it was pretty straightforward to write a loop in LESS to output a series of numbered classes. I could also reuse the LESS mixin to make another set of classes for each sandwich. [Check out these sweet gists of the LESS mixins and the compiled CSS!]

 By mid day Wednesday we had a working prototype and we got some feedback from Kenji - there was additional content I hadn't accounted for. The next day or so we worked on incorporating the feedback, making the page responsive and squashing bugs. Surprisingly we had very few browser bugs, it was certainly more about getting it to look great across the range of device widths. Getting the breakpoints right is still a bit tricky, but this page was simple enough that I could adjust the breakpoints on the fly, directly in the CSS, rather than having to go back and do more refining in Illustrator.

The sandwich page at multiple screen widths.

And voila, Friday we launched! 

The feedback we received was enormously positive and we're hoping to do more and more of these collaborations in the future. 

I Want a Better Writing App

[Note: I wrote this a week before Writer Pro was released! And guess what! It's taken me that long to publish it!]

I write on my phone a lot. For pleasure, to get ideas out, to work things through, to produce, to share. But none of the apps I've tried actually address the process of writing. Sure, I have maybe weird requirements in that I do most of my writing on the subway so I have no internet. (This is when I am least distracted and I can just...write.) I edit things over a few days before I publish rather than being spontaneous. And I tend to do a first pass at editing on the phone and then I move to the desktop if I want to be more ruthless. (Tap/hold/drag only gets you so far.)

So many of the writing apps I've looked at are only concerned with the interface around the writing part and making it beautiful/minimal. Cool! I think y'all have gotten that done. But I need a tool that can help me refine my writing and prepare it for publishing. (I am *not* asking for a tool to actually publish!!) and I mean "publish" in a loose way. It may be for private or public consumption. Sometimes it ends up in an email, sometimes on a web page, sometimes in a (gasp!) a PDF. Sometimes I want it to go to one of my numerous Tumblrs or my personal blog or my business blog. Sometimes it just ends up being notes for myself. Products like Editorially and Draftin are great...but, no internet. So much of my writing ends up languishing in this phone's local directory. (If it's a blog post that's never published, is it a blog post?) 

I know it is not easy to design and produce an app! However, I have some suggestions to writing app developers for my weird/selfish use case:

  1. Modes: Draft/editing/to publish/archived. I have a huge directory of text files and I have no idea what is in what stage. Tagging? Toggle? Some way of organizing. 
  2. Also the ability to associate more metadata please. 
  3.  Time shifting! Auto sync: queue my text file for syncing to my chosen publishing tool for that particular piece of text the next time there is a connection. Not just Dropbox. Bywords has a feature that is similar but I don't use any of those services. Make a service-agnostic option (JSON...? Hell, Markdown). Harder said than done, obvs.
  4. Saving to Dropbox/"the cloud" without creating an error when I don't have an internet connection (I'm looking at you, Writing Kit). I've had to resort to emailing unfinished text files to myself with my current writing app and the lack of versioning is driving me up a wall. 
  5. Nag/nudge notifications: it be GREAT if my phone gently reminded me of something that's in draft mode. "Hey, looks like you haven't worked on that in a few days. Wanna take a another look? Or have more ideas?" Sometimes I just need a few days to think something over and let it percolate, but sometimes I just...forget. And then I look in the app a month later and I'm like, WHY DID I NOT FINISH THAT. 
  6. Personality: following up on the previous item, give the app some personality. (You don't need to go all Clippy the Paperclip though). I'm not a professional writer by any means, but I enjoy writing and will take all the encouragement I can get. 
  7. Bonus: Associating photos: Nothing fancy. But hey - I've got this photo of a prototype I was working on that would be perfect for the post. Associate it with the writing please! 
  8. That said, please make it focused. I don't need to be presented with 500 options all at once. Step me through the tasks - writing/editing/publishing - in a way that makes it easy to understand. 
  9. Lastly, yes I would pay good money for this and think others would too. 

Experience Isn't a Dirty Word

Observational Sketch, Süleymaniye CamiiJuly 2010, Istanbul

A piece that I read on Medium recently called "Experience Slows You Down" kind of bothered me for a while. I agreed to some extent that experience doesn't automatically make you an expert. However, the author misses the point that experience is valuable when it's done with intention and attention. I'm reminded of two principles in karate that I return to often - shoshin, beginners' mind, and renma, the act of polishing.

Shoshin is akin to what the author described in his piece. I try to approach every project as if I've never done it before. It doesn't matter if I'm doing kata - a series of predefined moves - or working on a site design, or planting a garden. The worst thing that I can do is to say to myself, "oh hey I know this already so it's all good." I run the danger of making the same mistakes, doing things by rote and not actually solving the problem at hand. Maintaining my awareness is what's crucial, not that I've never done it before.

For the month leading up to earning a black belt, you're asked to switch back to a white belt and attend white belt class to remind oneself of what it felt like when one started and had no preconceptions. When I start with beginners' mind, I'm often led to insights that I would have missed otherwise. I try to keep curiosity and playfulness at the forefront and realize that the more I know, the more I find out that I don't know.

Experience becomes valuable through the concept of renma, or constant polishing of technique. Take whatever the essential building block of the medium is - a punch, sketching from observation, setting type, practicing scales - and do it ad infinitum. A deeper understanding and skill level gradually develops through repetition. Since last year I've hand-rolled thousands of tortillas. To some it may appear to be drudgery. But through doing it with attention, I now know exactly how hot the grill needs to be, what the optimal temperature the dough should be for rolling, and how long it takes for the dough to puff up to fluffy perfection. I wouldn't have been able to acquire this information any other way as it's a long process of trial and error. But now I can be confident in our choices for a permanent set up that will give us tortillas of the same consistency, taste and quality. In doing things like this, I aspire to even a thousandth of the skillfulness of a chicken yakitori master we had encountered in our travels in Tokyo - a man, well into his 60s, who effortlessly and gracefully rotated skewers with the flick of his wrist until each piece of chicken was charred to perfection.

John Singer Sargent: White Ships 1908, Watercolor

The great artists and designers that have left a cultural legacy understood these principles. They weren't geniuses who were born fully formed, they worked extremely hard at their craft and had the ability to have an open mind that enabled them to come up with interesting, insightful ways to communicate. I was just reminded of this with some of the watercolors that were on display at the JS Sargent show at the Brooklyn Museum - you can see a huge difference in the mastery between an earlier, tentative piece and the Carrara quarry paintings a decade or two later. I'm inspired all over again to put these principles into practice. 

It's the intersection of beginners' mind and polishing technique that I believe one has the ability to achieve a deeper understanding and that creative solutions come about. And by no means do I think this is easy to achieve! It's something I strive for every day but I know that my attention wanders. Often.

Mapping Burgers

I've been really excited about the projects that I've been working on at Serious Eats, and the burger map that we published yesterday is a great example of how the design and development team has been working closely with editorial to rapidly produce new areas of the site to showcase Serious Eats content. One of the things that I love about Serious Eats is the deep archive of writing about all things food, but it's always been hard to find and surface (for a number of reasons which I won't get into here).  

Kenji and the editorial team came to us at the beginning of June with an idea for a burger map for the Fourth of July; they'd choose 50 burgers and gather links and photos to previous recipes and reviews. They had a vague idea that it should be clickable but beyond that it was up to us. We told the editors to gather their data in a Google spreadsheet for now, since they're used to that workflow already, and I dove into design. 

Two early conceptual sketches in Photoshop

These days I'm using Photoshop just for rough sketching rather than fully fleshing out the entire design, which has been a major sense of relief for me. The aim is to convey overall look and feel in the vein of style tiles rather than making specific layout choices or details. For those that argue that jumping right into CSS kills creativity, I would counter that it provides a set of constraints that one must be creative within. I know what's possible and where I can push the limits. It frees me from doing theoretical finished comps in Photoshop that would never work in the real world; so many of the issues that need to be solved with a responsive design only come to light as you interact with the page, and there is no way you can see that with flat comps. And we didn't have much finished content to work with since we were working in parallel with the editors. 

Development-wise we had recently built NearMe as a way to explore and organize location-based content, but this wasn't quite the right tool for this project. However, the templating system that 29th Street Publishing had put into place was exactly what we needed. On top of that, we found a script for exporting a Google spreadsheet to JSON and an svg library called Raphael.js for the map. The script enabled the editors to continue their workflow undisturbed and we didn't need to build anything custom to store the data; maybe it won't scale if we're doing many maps a week, but we just needed to ship it quickly. 

Now we've got a reusable base of design and code that we can spin off into other projects and a better idea of where we can take things. I definitely want to explore more mapping possibilities with MapBoxLeaflet, and OpenStreetMap (this is a really inspiring example!), as I think it's an effective way to group content to tell a larger story. And I finally feel like I'm getting comfortable with the process that responsive design requires to tackle some larger changes on Serious Eats. 

Ever forward!

Prototyping and Lonestar Taco

Back in April I attended the TYPOSF conference (which I highly recommend) and one theme that ran through a lot of the talks was the move towards a rapid, incremental prototyping process with a collaborative team. Developing and running Lonestar Taco has been a very similar process. I'm mostly used to designing in the medium of the web, so it's been an interesting change of pace to work on systems in a more physical realm.

The same principles apply regardless - gathering and defining requirements, designing solutions, implementing, gathering feedback, iterating. This time though it's entirely our vision, and it feels a little funny to be in the client chair at the same time as the designer role. It's definitely harder to get perspective, so it's even more important to listen to our customers. 

Menu board over timeLonestar Taco menu over six Sundays at New Amsterdam in 2012

New Amsterdam Market gave us a chance to roll out our prototype, from the menu, the organization of the ordering line, food prep and cooking logistics, pricing, sourcing, even our social media. Every week we assessed how things went and took note of what we could improve. Sometimes it was something as simple as positioning the cooler parallel to the grill rather than perpendicular. Other times, it was realizing that propane tanks don't do so well in really cold weather and figuring out how we could adapt. We ended up creating a line of retail products that didn't require on-site cooking and selling tamales that could be kept hot on an electric induction burner. 

"Ghost of Christmas Past" Chili Marmaladeexperimenting with retail products. This one sold out in two hours!

As in all prototyping, we gathered as much customer and team feedback as possible. We had many variables to take into account - how much was rain responsible for variation in sales? How could we increase our capacity while decrease wait time but not sacrifice quality? And how could we ensure that we were meeting our bottom line? What items were the most popular and did we price them right? There's very thin line between customers feeling like they received value for their money and being perceived as too expensive. We also made sure to talk through feedback from our team, and they always had insightful suggestions that allowed us to make incremental improvements every day. 

Although we've always been clear about our overall vision for Lonestar, it hasn't always been easy to figure out the immediate form that it should take. After last season, we collected a ton of information that is helping us with the next iteration. We're altering the design of the menu and offerings to make it easier for customers to make decisions and to streamline our service. We're focused on securing a permanent kitchen for ourselves - although the initial outlay will be larger than last season, the gains in our ability to produce food, hire staff and making our products more readily available to our customers will enable us to be a sustainable and profitable business. 

Another point from the TYPO conference that resonated with me was the fact that nothing is ever "done", you always have opportunities to improve. And that has been so true with Lonestar Taco. Of course we all have days where we felt like we fell short but it was most important to get our idea out there to give people a chance to kick the tires. I'm excited that we're returning to New Amsterdam Market this Sunday to put some of our improvements to the test and to see all of our regulars.

Why I'm a Designer

Whenever I tell people who know me as a designer that I'm working on a restaurant, I get some puzzled looks. "Don't you make web sites or you're in tech or something?", their expressions seem to say. Yes, and the web is simply a medium. What I'm fundamentally interested in as a designer is the experience that people have when interacting with one another and how the intermediary systems can help or hinder those interactions. 

Restaurants and the web are more similar than you'd initially think. Paul Ford pointed out that the web is a customer service medium - so is a restaurant. Everyone has their opinion and certainly doesn't hold back. (see Yelp and every food blog ever.) It's not called the hospitality industry for nothing! Ultimately you are accountable to your users/customers, because they will certainly vote with their feet if they don't like what you're doing. 

 The same questions arise in both mediums. What happens when someone uses an interface I've designed? How does the person on the receiving end interpret it? Was the message communicated successfully? The design process provides a set of tools to gauge success and come up with solutions to make improvements. 

For instance, we want to offer counter service in the morning and afternoon and then switch to table service in the evening. This decision came about after observing that our potential customers modify their eating habits depending on the time of day. In the morning and for lunch it's mostly people on the run, in between activities or on their way to work. In the evening, people are unwinding and socializing, they certainly don't want to stand in line. However, switching service modes is unusual for most restaurants and there isn't a shorthand way to convey that. 

How can we design the space and signage to be flexible enough to switch between the two modes of service and to make it clear upon a glance what to do when you enter the space at any given time? I constantly have to examine the interface and imagine the experience from the other side. Honing my sense of empathy is an essential part of being a designer and part of why I was attracted to the discipline in the first place. 

 When I think about a restaurant as a number of interlocking systems, I get ridiculously excited. A menu seems simple but it's not at all! It's not just the visual design of the menu, it's how the items on the menu are broken down into their components, how the prep kitchen organizes the production of those components, where the components are sourced from, if those items are even seasonally available, how to price the menu item, how the item is described on the menu, if customers understand what the item is, and the placement of the item on the menu. All of these things can be implicitly or explicitly communicated to customers and will color the overall experience. And tweaking any of these variables could drastically affect how well any given item sells, and making decisions based on collecting data and feedback can make or break the business. 

 Without a doubt I love that the design process fosters a spirit of collaboration. A tight-knit team that has good lines of communication is required for all of these projects regardless if it's a web site or a restaurant. The best projects happen when everyone feels empowered to make a significant contribution, and the systems you've designed are nothing without a team behind it. Design brings observation, empathy, and collaboration into a single process where we can put something worthwhile into the world. In the end, the form isn't as important as the relationships that these systems help build.

Friends of Bob Newman

Recently I had the honor and pleasure of working with Bob Newman on a redesign of his web site and had helped him launch it in the beginning of March. I recently found out that Bob had suffered severe head trauma and has been in the hospital for more than a month and is still in the process of recovering. I was upset when I heard about what had happened, but the outpouring of support from the design community has been heartening. His hospital bills have been mounting, so a number of his friends and colleagues have put together a donation campaign to help support him. Magculture is also doing a project called "My Favorite Magazine" in which all the profit goes straight to Bob. Please spare a moment to spread the word or help out in any way you can.