Forget what you know about the lonely researcher toiling away in isolation. In design and medicine, good research takes teamwork.
I recently came across a story on NPR about the increased role of medical scribes during doctor-patient visits. They do data entry in real-time, taking detailed notes directly into a patient’s file for the doctor to sign off on later. The approach came about as a response to the government’s mandate for electronic medical records by 2015, and the partnership frees the doctor up to listen to the patient and eliminates the double-work of taking notes by hand and logging them after the fact.
As a design researcher, I can’t imagine doing interviews any other way. At Mule, we always conduct design research interviews in tandem. I lead the conversation, while my partner takes notes, though there’s much more to the role than that. Similar to the medical scribe, my interview partner allows me to focus on what the subject is saying (or not saying) and to let the conversation flow naturally, rather than running through a list of questions, half-typing, half-listening. And without that focus, I am likely to miss out on some really valuable stuff.
What kind of valuable stuff? For example, if an interviewee hesitates, laughs, looks down, cuts themselves off, or starts to editorialize, this points to something deeper, potentially the real gold of an interview. When I’m completely focused on listening—not staring at my screen or scribbling in my notebook—I have the ability to pick up on these hints, and my scribe will, too.
One of the most important benefits of having a scribe is the shared knowledge and what we at Mule do with that knowledge. The scribe—content strategist, designer, developer, project manager—isn’t just taking notes to help me in the moment. They internalize these conversations and contribute to a shared knowledge base that creates a fuller, more nuanced, understanding of the stakeholder and user needs.
I learn a lot from my teammates. Throughout the discovery process—and sometimes during an interview—they’ll have questions for the subject that hadn’t occurred to me, or an angle I hadn’t considered. Right after the interview, we might spend a few minutes sharing things we found interesting, e.g., a turn in the conversation, a surprising revelation, etc. And if there’s a question that isn’t working how we’d hoped, we’ll talk through it and find another way to get what we’re after.
Once we’ve had some time to dig into the interview notes and transcripts, the entire project team meets to share our findings, raise perplexing questions, and start constructing our strategy. The key here is that this knowledge doesn’t reside solely with the researcher. By taking part in the discovery process together, we’re all researchers, contributing to a shared understanding that is championed through the life of the project.
In the medical profession, missing a detail from an interview can lead to an incorrect diagnosis and potentially devastating consequences, so having that extra assistance can be crucial. Designers also diagnose and treat problems. As design expands to include solutions that we depend on for both our physical and mental well-being, the repercussions of our mistakes expand as well. We have a responsibility to the people we’re designing for, and this starts with asking about their habits and needs. Then really listening, together.
The Healthcare.gov rollout was a big setback for client services in both execution and perception. The site tanked, and the end result, for hundreds of thousands of site visitors, has been error messages, slow response times, the inability to log in or create accounts, and an overall unpleasant user experience. Every designer’s, developer’s, and client’s worst nightmare.
Why did this happen? Part of it stretches all the way back to the process of selecting the firms that participated in the project. Prescriptive RFPs and exhaustive procurement processes have created barriers to entry on government projects that many top design firms are unable, or unwilling, to deal with. And these unfortunate circumstances are not unique to government work. Many organizations believe that an orderly RFP process can help them find the right design partner, when many times, it simply proves that they can successfully execute an RFP process and that design studios can follow directions, the right fit be damned!
If you’re not required to write an RFP, don’t. A concise project summary and some conversations should be enough for prospective agencies to scope your project. But if organizational regulations force you to turn to the dark side, here is a list of some dos and don’ts to consider:
1) Don’t use a template
Start with a clean slate and define the problem from scratch. On the chance that you miss something, a good design partner will ask the right questions to extract any info that is missing.
2) Do keep it brief and define a purpose
Brevity is key. Define your purpose clearly and succinctly. To do this, ask your team questions like:
Why are you redesigning the site?
What does the current site do well? Where is it lacking?
What business requirements must be met?
How could user needs be better served?
Who are your audiences and what do you want them to do?
Who is your team? What will their roles be on the project? Who manages the project? Who makes decisions?
Who will maintain the new site after it launches?
How will you measure success?
What are the project risks?
What challenges have you faced in previous work with design partners?
After launching the new site, what will change for your organization? What will change for your users?
3) Don’t be prescriptive
Stick to defining the challenges and goals of the project in the RFP and avoid offering, or asking for, solutions at this stage. This allows the respondent to reply with their thinking on the best approach and strategy rather than specific solutions, which should only come after adequate research.
4) Do ask for references
There’s nothing better than talking to the people who’ve been in your shoes. Talking with reference contacts from previous projects is a great way to get unfiltered thoughts on working with a design firm.
And don’t put it off until the end as a formality. As soon as you begin to feel that an agency may be a good fit for you, gather some reference feedback and use it to inform your discussions with the design agency.
5) Don’t ask for spec work
Design is a solution to a problem within a set of constraints. It serves to support the content on a site and help the users complete the desired tasks. A good design process begins with a Discovery phase to define the problem, audiences, etc. Layout or design created without this is simply decoration.
6) Do allow for questions and conversations
Keep the Q&A process open and be available on an as-needed basis. Many times, a key question may not come up until the final stages of an estimate or proposal prep, sometimes right before the response deadline. If you want the best proposals, you’ll want to provide potential partners with the freedom and flexibility to ask questions at any point in the process. RFPs that define a strict cut-off point for questions make me think that the client cares more about the RFP rules being followed (the checklist approach) than finding the right design partner for the project (the best fit approach).
A good team fit is an essential criterion for a successful project, and that is best evaluated through conversations or in-person meetings. You’re going to be working with these folks on a daily basis for months. You should enjoy each other’s company, be able to have fun, and be able to argue. We never take clients we can’t argue with.
7) Don’t invite the whole world
Do some research and ask some people who you trust for referrals. Find sites you like and track down who made them, or pick out some firms that you’ve always wanted to work with. If you decide to invite multiple agencies to reply, keep it to five or less.
8) Do share your budget
Knowing the budget helps us guide you toward solutions in your price range. There are a lot of moving parts that come together to determine the final cost of a project: scope, features, project activities, etc. We’re always open to discussing money and fitting our approach to a budget threshold or range.
9) Don’t define the project timeline
Definitely include target milestone dates or deadlines, but don’t lay out a complete timeline for the project, with deliverable due dates, etc. Let the agency build their process and timeline around your targets.
10) Do define the RFP process timeline
Set clear expectations of when things are due. Allowing a few weeks for the distribution, Q&A, response, meeting, and selection process should suffice, but it’s somewhat dependent on the scale of the project, how many firms you invite to respond, and the formality of the process. You want to make sure that your team has enough time to field and respond to questions (through calls or email) alongside their other job responsibilities. So, if you are inviting five firms or less, four weeks should be enough time for the entirety of the process. If it’s 10, you may want to push it to six weeks.
So, before you issue an RFP for your next design project, consider these guidelines. Think about what’s best for you, your organization, and your users. Ask yourself what approach will help you find the best design partner for the project. Because an RFP can be like a mammothly expensive website that throws error messages, has slow response times, and doesn’t allow users to log in. It’s fancy and follows the rules, but if you can’t get what you need out of it, then it’s a waste of everyone’s time—and money.
A few months ago, we started using the Sass preprocessor to help make our projects easier to manage. I wish we’d had Dan Cederholm’s excellent, just released Sass for Web Designers before we did. (Quick note: the good people at A Book Apart sent us a copy last week so, yes, we’ve had a chance to actually read it).
Sass for Web Designers, the 10th in A Book Apart’s series for web professionals, continues the tradition of being the Seal Team 6 of technical books. It gets you in, gets the job done, and gets you out, without anyone knowing you were even there (stealth helicopter not included). It’s a quick, approachable read and Dan makes what could be a thorny, dense topic easy to understand.
The book starts with a chapter asking “Why Sass?”, which you may be tempted to skip if you’re already excited about CSS preprocessing (I mean, who isn’t!). Resist this urge because even if you know why Sass is great, you’ll likely need to convince a client or someone else on your team, and Dan makes a great argument for you. Borrow from it liberally.
Because Sass involves a bit of one-time setup before you can get started, there’s a chapter dedicated to setup and workflow. For designers not accustomed to the command line, this is essential reading and Dan makes it simple, for both Mac and Windows. He also details several desktop apps that will make setting up Sass even easier, though he left out my personal favorite, Hammer for Mac, probably because Hammer does more than just compile Sass files.
Next, Dan gives an overview of actually using Sass, which will be the chapter you return to the most. Instead of getting into the minutiae of every single feature of Sass, Dan provides a detailed look at the parts you’ll likely use most: nesting, variables, mixins, import, and extend. It’s an excellent overview and covers everything you’ll need to really make effective use of Sass in your projects. Keep in mind that Sass has a lot of advanced, programming-like functionality (if statements, loops, functions, etc.) that Dan (wisely, I believe) chooses not to cover for the sake of keeping the scope of the book compact. Fortunately, the Sass documentation is quite good.
The final chapter is dedicated to using Sass for responsive design, specifically media queries. This chapter alone is worth the price of the book. At Mule, we’ve been using a similar approach in order to make our stylesheets more modular and it has made our work much easier to build, maintain, and, dare I say, more fun.
I can’t recommend this book more highly to anyone who’s interested in writing better, easier-to-maintain CSS. If you’ve been reluctant to use a preprocessor, Sass for Web Designers will set you along the right path.
XOXO 2013 wasn’t so much a conference as a pep rally. It brought together 500 people for two days in Portland to talk, learn, and share about the process of making and to have a good time together. The organizers promised focused sessions and great fellow attendees, and they delivered. It was more fun than any conference than I can remember going to and the quality of the speakers was high across the board. But even by that yardstick, two really stuck out for me.
Max Temkin is one of the creators of Cards Against Humanity, which has achieved the fairly astonishing feat of being both completely free to download and one of the best-selling games on Amazon (if you count the expansion packs, it qualifies as four of the best-selling games on Amazon). I wasn’t sure what to expect from Max. I have never played Cards Against Humanity (I’m not much of a game player) and really only knew about it as a phenomenon. But he was great! He told the story of how he and his friends started making games in college, had some success, and after seeing how much people liked their downloadable “party game for horrible people” decided to see if people would pay for nicely-made, boxed sets. In the two and a half years since that project was successfully funded, the game has generated millions of dollars in sales.
Max talked about how he and his friends have managed to keep their heads during all of this. His advice was to make sure you know your values before you start the project, or at least understand the values that will inform the project. Let those values guide your strategy, and then figure out your tactics from there. Writing it down now, it seems so simple—like something you’ve heard over and over from other people. But this is thing about XOXO. If you know these people’s backstories, very few of them will surprise you. But when you have engaging speaker after engaging speaker telling you that they succeeded by doing these things, it starts soaking in. You start to actively think about the values that you bring to your projects. Are they values you have in other parts of your life? Do they make sense for this project? Can you stand behind them?
Jay Smooth was the other speaker that really resonated for me. Jay is the host of the longest-running hip-hop radio show in New York, and posts social commentary at illdoctrine.com. Jay and I have very different backgrounds and very different lives, but we have some common ground in how important outsider music was to us in our younger days. I came of age just as American punk rock reached a peak, and it was in that network of underground communities that I became an adult, and the spirit and attitude I learned there has stayed with me, even as the idea of punk as I knew it has transformed into something else. Jay grew up in New York City in the middle of the invention of hip-hop. He became a part of that and has stayed a part it. He’s been doing a lot of thinking about what it means to be an adult rooted in an art form that has maybe not aged all that well. As you might imagine, that train of thought spoke to me.
Jay told a few different stories. One was about reaching out to some acquaintances in the NYC Asian hip-hop community to mobilize people in response to ongoing racist humor by some radio DJs and how some good friendships came from that. Another was about playing some old ‘70s funk for a record producer who then sampled it on a Jay Z record, and how that helped the original composer of the source material—who had just turned 88 and fallen on hard times—pay off his house and help a few other people. His point was that you can’t always tell which actions in your life are going to have lasting effects, and that it pays to always act with intention and integrity. Again, this is not an earth-shaking revelation. But again, sitting there in that environment, it was a good “Yeah!”, fist pumping moment.
Jay also addressed one of two major problematic issues with XOXO: diversity. It was a largely white, largely male audience and the speakers where largely white and male, too. Not exclusively, mind you, and it was great to see groups outside those two represented on both sides of the stage. But when you go out of your way to set yourself apart from other conferences, you set some expectations. It was a topic of conversation among the attendees and was acknowledged by the organizers, and I’m confident that if they decide to put on XOXO again next year, we’ll see some efforts made in both speaker and audience diversity.
The other major issue is how that audience got there. The filter/screener/application that people had to fill out before getting put on the list to buy a pass has received a lot of attention. Both of the organizers have written about how they decided to try this approach: Andy Baio and Andy McMillan. In a nutshell, they wanted to ensure that people coming to the purposely-small gathering (only 500 attendees) were there because they were excited about making things, and specifically not just about marketing to the other attendees. I think that’s great and in the end, their approach worked. However, there were two things that I hope are improved if there is another one.
First, they have to communicate the intention of that kind of screener much more clearly. It was way too easy to skip over it. I did, and I know several other people who did. This is not entirely their fault. It’s not like they hid it. But getting these passes had developed a little bit of a land-rush feel, partially because 2012 was so highly regarded and reported and partially because of the trickle of information coming out from XOXO HQ. So when people (myself included) plowed through that form to get that pass before they all disappeared and ended up with a “Thanks, we’ll be in touch” message instead of a field for their credit card number, it was a confusing letdown, which was made worse the multi-day wait to hear whether you would get to go. To be clear: those of us who did not read carefully are responsible for not having read carefully. But there is also a design problem here for the organizers to solve next time. If they go with the same filtering mechanism, I believe they will handle it a little differently.
Second, the one-ticket-per-person rule has to be addressed somehow. At least four of us in the Mule office wanted to bring someone who we thought would benefit from the conference, people who for various reasons likely wouldn’t have gotten through the filter. Because of the risk of one person being accepted and one not, three people at Mule decided the conference wasn’t right for them. I ultimately decided to go, and I’m glad I did. But I also think my wife would have gotten a lot out of attending even part of it. I think it would make XOXO an even better event if it could help put more people on the maker path, not only to serve those already on it.
I’ll close with some ways that I would like to see XOXO grow.
Have I mentioned that I liked it? I really did. I have two different projects that I’ve been working on for several months that I’ve been hemming and hawing about taking up a level (my podcast, It Might Get Personal and my band). This kind of enthusiastic and upbeat group of people was just what I needed to feel like my projects are worth putting the effort into, and helping me figure out where to focus my energy to make that happen.
But after two days of pep rally I wanted a little bit more scrimmage, or at least some discussion of the play book. The single track of speakers is great, but I would really, really love to see some kind of option for attendees to get practical advice. Maybe from the same people speaking, maybe from a different set. Some kind of smaller sessions, whether running in parallel with either the speakers on Saturday and Sunday or the social events on Thursday and Friday, or changing the format to one day of inspiration and one day of perspiration.
Andy and Andy have created something good and special. I hope they decide to see if they can make it even better next year. I left Portland charged and excited, with dozens of ideas competing for my attention, and I’ve already acted on some of them. If everything goes according to plan, I’ll be telling you about them from the stage of the next XOXO.
Today on Twitter I asked for examples of all-too-common or uncommonly pathetic reasons for skipping research on a design/development project. We’ve all heard some variation of these before, but I am always amazed. Many were some variation of “not enough time and money”, as though research comes in standard units of $100k/month. Apparently, a manager who won’t try a new sandwich place without scouring Yelp for hours will happily plow forward investing major resources in unexamined assumptions.
This is how people make business decisions?
I thought I’d quickly share some of the responses here as a virtual wall of shame—something you can print out and tack to your office refrigerator. In a future post, I’ll get into strategies for overcoming these objections, starting with considering research as a set of activities you can do quickly, inexpensively, and incrementally.
The cargo cult:
The research was finding a profitable business model in a case study and stealing their website via screenshots.
— carolinecblaker (@carolinecblaker) September 20, 2013
The split-test bake-off:
— Stephen R. Fox (@F6x) September 20, 2013
Thinking is hard:
@mulegirl “Can’t you just use best practices?”
— Derek A Rosenstrauch (@derklbot) September 20, 2013
Unclear on the concept:
@mulegirl “we want to wait until we have more content on the site” <- seriously!?
— Crispin Bailey (@cspin) September 20, 2013
Next you’ll ask for champagne in the break room (wait, some startups probably have that):
— Clay Fenlason (@khomotso) September 20, 2013
Shut up and keep paddling:
@mulegirl “We didn’t allocate time in the project schedule.” “We’ll miss our launch date.” “Everyone just knows.” All on the same project.
— Kaleem (@kaleemux) September 20, 2013
Odd use of the word “target”:
— luísbatista (@fr3aky) September 20, 2013
The winner, for pure fatalism:
@mulegirl *Knowing, sympathetic glances around the table and a gentle laugh* “That’s not how things work around here. You’ll learn.”
— Den McHenry (@DenMcH) September 20, 2013
And, of course, geniuses don’t ask questions:
@mulegirl “Steve Jobs never did research.”
— Jean MacDonald (@macgenie) September 20, 2013
In response to this last one, I highly recommend watching even the first three minutes of this internal NeXT video of Steve Jobs talking product strategy.
Are there other excuses you’ve heard and would like to demolish? Leave them in the comments.
@mulegirl HOW DOES THAT ARTICLE NOT CONTAIN A LINK TO YOUR BOOK? MARKET GODAMMIT!!
— Mike Monteiro (@Mike_FTW) September 20, 2013
Buy Just Enough Research today and you’ll be defeating these weak arguments in minutes.
All of the hype lately about “designer-founders” makes me really itchy, even more than all the other hype. Just because a few people in khaki pants suddenly noticed someone in a black turtleneck cashing big checks, “thinking like a designer” is not new, nor is it a secret weapon. Of all the things the intensely secretive Apple has done to become outrageously successful over the past decade, their emphasis on design is absolutely the least secret. That said, what is considered good design isn’t necessarily always a business advantage.
Reading Khoi Vinh’s recent post about his experience as the designer-founder of Mixel brought this to mind again. As usual, he writes with a tremendous clarity and transparency:
Building a great UI, while almost always important to a technology startup, might not always deserve to be the central focus of the business itself. Because startups always have extremely limited time and resources, prioritizing the UI comes at an enormous cost to the company. Sometimes it’s the right thing to do, but when it’s not, when it gets top priority because it’s the challenge that the designer founder might be most comfortable with, or simply the one that he or she prefers the most, that can be disastrous.
This passage contains two very important ideas.
In my experience working with early stage companies, these are generally true and applicable regardless of the professional background of the founders—engineering, business, design, snake milking*, whatever.
Prioritizing the user experience is expensive, both in terms of cash money and opportunity cost. This does not mean startups should blow off the front end. It does mean that a startup (or any business for that matter) should invest in the interface design at the time and to the extent that interface design matters to the business. This point is different for every single company, product, or service. The right time depends on the business model, the audience, the competition, and the context of use.
To make a gross generalization, engineer-founders overvalue UI design when they’ve been led to believe it’s magical. Designer-founders do, because, as Khoi pointed out, it’s a familiar and pleasant challenge.
Over the course of a few painfully educational projects, we’ve learned when and how to talk startups out of hiring us because they won’t benefit from the type of strategy and design work we offer.
The second idea above applies to every single design project ever, no matter what stage the business is in. When you are creating something for use by others, you need to be outside of your comfort zone. The place you feel most comfortable may be alienating, confusing, or just plain boring to your target users. This is where I generally flog research as the most comfortable means to keep yourself productively ill-at-ease.
So, let’s try to put aside the founder-hyphenates and focus on the fact that being a founder is a damn hard journey into the unknown and we should be grateful to every one of them, like Khoi, who is willing to share their experience and allow us all to benefit from it.
* Totally a real job. I’ll take the risks of running a company over that, any day, no contest.
I love being right.
I mean really love it. Being right is the most satisfying thing in the world.
I was the kid in class whose hand shot up FIRST to have the answer to the teacher’s question. The one who always knew the precise dictionary definition of that word you were using not-quite-precisely. The one who would fact-check your joke.
Studying philosophy in college only served to weaponize this tendency. Our papers were typically graded on how well we made an argument. And the first step of making that argument was always to define the terms. Learn to do this well and you can create a bulletproof argument because you have set the conditions of the universe in which your reasoning is valid.
And then I encountered the real world. And slowly, over time, I realized (or was encouraged by others to realize) that racing to demonstrate my rightness resulted in a few undesirable effects:
It made me very annoying.
It made me a very bad listener.
It increased the chance I was actually wrong.
Being a designer (or an entrepreneur) means exercising control over a limited set of factors to create something new, and then sending your new creation out into the wider world over which you have no control. The real world doesn’t conform to any designer’s preferences, as much as we wish it did and bitch mightily when it doesn’t.
You can try to set terms, but that doesn’t necessarily work because those terms are often just assumptions. This design succeeds assuming the production team follows the required workflow. This design succeeds assuming that the people who attempt to use it understand the interface. This design succeeds assuming that the target audience is willing to switch from their current method of solving that problem. This design succeeds assuming Facebook doesn’t change their current strategy.
Unverified assumptions are simply wishes. And self-satisfied certainty is sadly not self-fulfilling. We’ve all encountered (or even had a hand in creating) products and services that held marvelous promise, but came with a set of embedded assumptions that did not sufficiently incorporate reality.
A couple years back Netflix tried to spin off their DVD-by-beloved-red-envelope service into a separate company called Qwikster. The folks in charge were confident in the rightness of their decision in the face of the emerging popularity of streaming media. But what Netflix defined as the “additional convenience” of totally separate websites and billing systems, the 12 million users with combined DVD and streaming accounts interpreted as “an assload of hassle”. In an assessment of convenience, the customer is most definitely always right. (What defines “convenient” is the key to an entire category of terrible assumptions worth studying.)
The fact that at the time of the announcement, the @qwikster Twitter account already belonged to a rowdy stoner was the icing on the failcake.
And we’ve seen products falter from the supply side as well—desirable from the user’s perspective, but completely unsustainable or onerous as a business, hence doomed. This may be worse than the simple disappointment of a bad solution when a significant number of real people have gone to the significant trouble of developing habits and attachments. And I’m not talking about business models in decline at the end of a long and glorious lifespan—pour a little for the venerable print newspaper—rather the shiny new products that demand attention, then disappear. Lately, this flavor of demise happens through acquisition and dissolution, as with the nifty Flipcam and roughly a thousand websites a week.
At the moment, the most distressing trend is the number of new online services quickly formed, funded, and launched at the wall like so many half-raw noodles, leaving a vague and messy impression in their wake. Maybe 80% of new products will always be destined to fail, but there are ways to improve the odds it won’t be yours. And these ways are what we call research.
But don’t let that scare you.
The best designed products and services are useful, delightful, profitable, and sustainable. Some of them even articulate needs previously unrecognized. And this is what we should all be striving for. Committing to create the best possible designs means exchanging short-term certainty for lifelong curiosity and cultivating a deep and genuine desire to be proven wrong.
Maybe this sounds simple and Alice-in-Wonderlandy and all, but in practice it’s excruciating. Ignoring what your target customers actually want or fudging what your existing organization can accomplish is quite simple and extremely satisfying. Often it is shockingly easy to find cheerleaders to back you up, so you (or they) don’t have to feel the gnaw of uncertainty.
Hype makes right, right? No.
We once worked with some very smart, experienced people who had built a very powerful semantic search tool with a lavishly impenetrable interface. At launch these very smart people were blindsided by the fact that many visitors who arrived at the site immediately left without even attempting to use the tool. “All of our accomplished, powerful CEO friends to whom we gave personal one-on-one demos said it was fantastic.”
It is painful to say “I don’t know.”
It is painful to think up something clever and fun and expose it to honest critique.
It is painful to admit to ourselves that each of us is small and that our success depends in large part on the whims of that wider world far beyond our control—that the answer may be out there rather than in here.
(OK, that might sound scary, but hang in there.)
Repeated exposure is the only thing that will diminish this pain:
Practice letting go and ceding control.
Practice asking and listening instead of asserting.
Embrace the opportunity to invalidate your assumptions as quickly as possible.
Your reward will be vital, often unexpected insights you can use an an input to your design process and decision-making. Paradoxically, admitting what you don’t know gives you more control over the situation.
Philosophy also offered a path out of isolated speculation—a tradition of criticism, of asking why, of focusing on the penetrating question rather than the pat answer. Even the weakest question has a longer shelf life than the most perfect answer.
These days I strive to hear “That’s a good question!” more often than “You’re right”. I try to see my responsibility as helping to find the true answers and the best solutions wherever they originate, not hoarding credit for my cleverness.
Unfortunately, I also think there is way too much ado about who has the right to ask which questions, and this dissuades many designers and developers from going there at all. You don’t need a PhD, you just need the will to think critically and a willingness to listen. (There will always be a need for design research specialists and academics. How and when to make the best use of their expertise, I’ll save for another time.)
And this is how I came to write a book about research. It’s called Just Enough Research, and I wrote it for you. This slender volume aspires to provide an easy entry point into the most immediately useful research principles and practices for everyone busy doing other things.
Just in time for your new fall wardrobe, the book comes out September 10, and I hope it raises some questions.
Friends, do us a favor, please? We are approaching our one year anniversary of the launch of Evening Edition, and it’s time for us to gather some feedback.
We launched last year, on July 16, and we began with a focus on summarizing the day’s news, written by journalists, published once a day at 5 p.m. Since then, we’ve evolved a bit and now publish four written editions – Paris, London, New York and San Francisco – plus a podcast.
Now we’d like to hear from you. What brought you to Evening Edition today? What types of stories have you most enjoyed from us? What are we doing well, and what could we do better? Meaningful feedback is essential to our growth, vitality and the future of this publication. Plus you, our loyal Evening Edition readers and podcast listeners, I promised to get to know you better. We are so grateful that you like us, so please, don’t be shy.
This won’t be your only chance to give us feedback. And of course, you can always send us messages directly through email: editor (at) evening-edition (dot) com. But we’d appreciate it if you take five minutes to respond to our survey.
Thanks for reading and contributing.
Dear Mule Design, the expanding Evening-Edition team, our loyal readers and listeners –
I am excited to be here, to be joining this incredible team as your new editor-in-chief. In fact, I have had a stupidly silly grin across my face for hours as I have been thinking about what to write.
I remember when I first came across your project last year. A friend from my news design world, Justin Ferrell, was on Northwestern campus for a few days and stopped in for a chat. He asked if I had seen this project and, ever since, I have admired you from afar. In fact, my Knight Lab colleagues and I have often spoken about, even written about, your impressive and ambitious beginning, going from an off-the-cuff Twitter exchange to proof-of-concept in about a week. Hot damn!
And now, dear team, [internal squeal] … I am so proud to tell the world that we are going to work together.
I am so looking forward to exploring the potential of this project as we go on an adventure. All new publications take some time to find their editorial voice, to find their stride, and I have enjoyed your fearless approach to the highly competitive journalism startup community. Perhaps we’ll pivot to something more locally focused. Perhaps we’ll shoot for something more dinner-party-esque. Wherever we end up, we are going to have a ton of fun getting there because we want be the ones who always have five great stories to deliver at 5 p.m.
And you, our loyal Evening-Edition readers and podcast listeners, I am looking forward to getting to know you better. We are so grateful that you like us and we would love to know more about how we have been doing so far. So please, don’t be shy. Reach out to me on Twitter, @jmm, or email us and let us know what you think.
Now, let’s get back to work.
It is with great pride that I welcome you to the workforce. I realize many of you are still preparing for finals. Getting your portfolios together. Preparing oral defenses. That sort of thing. But I’m guessing that right below the surface of those immediate and real concerns, the anxiety of what comes next may have started to take hold.
It’s cool. I am here to help you.
Read the Full Post