Full Width [alt+shift+f] Shortcuts [alt+shift+k]
Sign Up [alt+shift+s] Log In [alt+shift+l]
1

Product Design Sprints - QCon 2014

from Alex Baldwin [alt+shift+b] in design

When I started at thoughtbot a year and a half ago, my first project was given to me within an hour of getting my laptop’s dev environment set up. We kicked off a green field project for a non-profit in the education space. They wanted to raise funds digitally for public schools. From our armchairs we talked everything out and drew up the blueprints for a sensible solution. We even clearly defined what success should look like, a working app that could take money and specify what school it should go to. But at the end of the engagement with our working app and success met, if someone asked me if I thought it was going to be a successful endeavor, I would have responded with a greatly exaggerated shrug. The goal of Product Design Sprints is to get from zero to a high confidence ratio in a really quick and collaborative manner. Making a golf analogy, this is hitting off the tee with a driver. You’re doing the bulk of the work in a single stroke and need to aim yourself in alignment with the core problem. Product Design Sprints as we know them, are an invention of Google Ventures’ design team. Their intention is to improve the chances of making something people want, reliably. We want to go from shrug to smug. A formal Product Design Sprint is a five-phase exercise which uses design thinking to reduce the total level of risk in a project by thinking about it holistically and attacking it in a linear fashion. We started doing product design sprints at thoughtbot last year and it’s become integral to our design process. They’ve been so successful, that we started requiring them for green field projects and the exercises used in the sprints have started creeping into the rest of our workflows. Participating in a Design Sprint orients the entire team and aims their efforts at hitting a clearly defined goal. Sprints are useful starting points when kicking off a new feature, workflow, product, business or solving problems within an existing product. Integrating design...
11th Jun 2014

Stay updated

Get a weekly newsletter with the top 5 articles worth reading every week.

More from Alex Baldwin

Artisanal outbound with Clearbit Connect

For press releases, advertiser requests, or similar sales campaigns you’re sending a small batch of, usually cold, emails out with a specific ask. Finding potential recipients, writing an email that’s helpful, and tracking the results doesn’t need to take all day or be painful. I’ve watched my fellow product people struggle with the pitfalls of outbound; spend all day trying to find emails, copy and pasting boring boilerplate copy, and then never following up. By stringing together Clearbit Connect, Google Sheets, and Streak, you can knock out these outbound projects super quickly, personalize them, and track progress through a funnel. I’ll walk you through exactly how it works using my most recent campaign, a sponsorship request for Hack Design. Researching for the right audience First up, you’re looking for the most likely people to be interested. For a press launch, that may be who frequently cover products in that space. In our example, Hack Design’s sponsor list, I was quickly able to look at who else was sponsoring comparable websites. For me, that meant researching the advertisers on Offscreen, Sidebar, Dribbble, recent design conferences and podcasts. It’s super simple to save your research and move on to finding the right people at those companies. Add companies to your list Start a Google Sheet with the column name Company. Research the companies most relevant to your outbound campaign. Great places to look are Angel List, Product Hunt, job boards (to see who is hiring in a space), Crunchbase, etc. Anywhere that let’s your group and filter through relevant companies. Add the company name to your list. Finding anyone’s email in seconds Now that you have a list of potential companies, let’s find the emails for the best people to talk to there. For my Hack Design list, I was lucky and had about a dozen sponsors from previous years. However, since we haven’t accepted sponsorship in over a year, a lot of my contacts at those companies were out of date. This process made it trivial to find the new people in those roles and be able to reach out. Get the right contacts from Clearbit Connect Add the column names Email and Full Name to your Google Sheet. Install Clearbit Connect if you haven’t already. This is the secret sauce that will allow you to find anyone’s email, for free. Connect does have a limit but for small batches, you shouldn’t have any problems. Disclosure: I’m a small-time investor in Clearbit. In Gmail, hit the Clearbit button in the top nav and then press Find email. Yep, it’s really that easy. You must start with the company and then narrow down by name or title. Copy and paste that into your Google Sheet. More coming soon Next up we’ll write our email and learn how to quickly customize every single one of them. This article is part one of a three part series, released weekly. Subscribe to get access first.

11th Sep 2017 • 1 votes
One line of CSS to add hanging quotes

The hanging-punctuation property aims at giving web web designers a finer grained control over typography on the web. The idea behind hanging punctuation is to put some punctuation characters from start (or to a lesser extend at the end) of text elements “outside” of the box in order to preserve the reading flow. blockquote p { hanging-punctuation: first; } Since it only applies to quote marks, you can avoid single purpose classes and trust that your quotes will hang everywhere. Chrome hasn’t yet implemented the hanging-punctuation property, but it works perfectly in Safari. Typeset.js is an HTML pre-processor that adds a lot more functionality and will allow you to get cross browser compatibility.

10th Nov 2016 • 1 votes
IAM FINE Mix

While in Korea, I used Shazam to record all the songs played in coffee shops. Here’s a mix I put together of all the discovered tracks.

18th Sep 2015 • 1 votes
See, Think, Design, Produce

Jonathan Corum, New York Times See Practice until your eyes can see it See what others have done See what’s possible Look at more than you can use Think Find a clear thought and get it on paper Sketching is visual problem solving Sketches are not commitments What are you trying to do? Set the pattern, then show the variations Ugly is fine Sketch with data Sketch in the browser Find something your brain recognizes Remember that aha! moment Communicate that understanding Design Good design is clear thinking made visible. - Edward Tufte Design for someone else Don’t be your own audience If you’re talking to yourself, you’re not communicating Remember what it’s like not to understand If I could have gone back in time, what would help me get to understanding. Explain overview + relevant detail In order to get anything out of this [research paper], it’s going to be a translation project. Show change Don’t collect trivia There’s a reason that I’m collecting that and then presenting it. Collections should add up to something Visualization ≠ counting Find and show meaningful patterns Avoid the language of infographics Avoid the facade of communication. Don’t introduce false patterns Is this pattern a true pattern or an artifact of how I arranged the data? Visualization ≠ explanation Don’t count diapers! Be skeptical of vanity data Compared to what? Produce When your idea hits the real world. Embrace limitations Point and annotate Put the text where it’s relevant. Combine art + label Anticipate confusion It doesn’t say here’s some lines, now you figure it out. Help the reader through Keep honing your ideas We are not designers! - Matthew Ericson Ruthlessly apply common sense Brute force works but tools can help Understand every step in the process Understand what you can control: accuracy, clarity, legibility, empathy, and simplicity What might emerge? Understanding, elegance, and beauty. What if I am tricked? What if I believe in this just because it is beautiful? - Andre Lim See & think = understand Design & product = explain Understand then explain Respect the reader Bret Victor, worrydream Links to examples Static displays Dynamic displays Dynamic data Dynamic Displays Summary and detail graphics - Two levels of questions for different readers. In the example it’s “what are the main contributing pollutants to global warming”, with the follow up being “what are the causes of each pollutant”. Slice and filter - Every decision is put within context. Where you see information, you can interact to filter by that aspect. Narrative context - While going through the data, you’re going through a story. These real world events are tied to the chart. Emotion - Switching between datasets that can tell a story from different perspectives. Don’t let readers sleepwalk through the graphic. When you have the interactive medium you can design a learning curve, similar to game design. Starting a reader off with a basic task and then after awhile let actions grow in complexity. Dynamic Data Black box explanations - you don’t care about what’s going on under the hood, you just want the output. Elements you can adjust and see the consequences of those adjustments. Open box explanations - what’s under the hood is exactly what you care about. Explaining how an algorithm works. Nouns are data objects, verbs are the transitions. Series of interactive graphics explaining each step of the process. Making a graphic is not about putting a large spreadsheet in the middle of the page with the data. It’s much more so like show and tell. Each cell telling a piece of the story, much like a comic strip. Representations for systems design - Show comparisons between original and intended change. Show the state of the individual steps in a system. Come up with a design language and then show the steps through the system. Ladder of Abstraction The graphics we make for displays must be better than their paper counterparts. By showing an animation, you take away the control that interaction allows. Animations are the pie charts of interactive graphics. First, give readers control over time. Let them move at their own pace and answer their own questions as they arise. Second, give control over each of the parameters while abstracting time. When you control a parameter, you need to be able to see the result. Be able to see the entire behavior over time. Third, give control back by letting the reader control time and variable by marrying them together. See also — Steven Wittens, Amit Patel Mike Bostock, New York Times If one of the best designers of all time doesn’t know if what he makes is good, how can anyone else expect to? Good design is as little design as possible. - Dieter Rams Fitt’s law, it’s easier to click on targets that are closer and bigger. Two phases: create and edit. Get fresh eyes frequently; invite criticism. New York Times Preview tool, displays all of the ongoing work. Can switch between each branch and interact with works in progress. Takes a snapshot of each commit on each branch. Prototypes should emphasize speed over polish. Transition from exploring to refining near deadline. Delete code as you go. Be ruthless. Make your process reproducible. Try bad ideas deliberately. Don’t be afraid to fail. Let’s make a bubble map. pbpaste allows terminal to access system clipboard. Edward Tufte, Author The Thinking Eye Code is now design and design is code. What was observed by us in the third place is the nature or matter of the Milky Way itself, which, with the aid of the spyglass, may be observed so well that all the disputes that for so many generations have vexed philosophers are destroyed by visible certainty, and we are liberated from wordy arguments. - Galileo Galilei Organizations which design systems… are constrained to produce designs which are copies of the communication structures of these organizations - Melvin E. Conway Seek verbs and actions. See now, words later. A sense of the relevant. Seek forever knowledge with a taste for excellence. Understanding the difference between evidence and inference. Only two industries refer to customers as users; software and the drug industry. Silence sharpens and deepens seeing. Most of social science studies are false. Social science is harder than rocket science. It does not have the fundamental truths of nature’s laws. Image quilts. Distribution of excellence is extremely logarithmic. A hard look at the practice and results of conventional asymptotic theory easily leads one to three points: We ought not to expect it to be widely useful (since it refers to the ultimate oversimplification). Rather often it has been useful (surprise!) We have developed no basis for telling when it is likely to help and when it is not….. 123 - John W. Tukey Standards of graphical excellence: Google Maps and Swiss Mountain maps. Future is maps moving in time. How do you know that? How does what I see come to be seen by me? Real science has it easy because they have forever laws. Begin with a question, a problem, then measure. You can have your own point of view, but not your own facts. - Daniel Patrick Moynihan

7th May 2014 • 1 votes

More in design

You are the best artist
9 hours ago • 1 votes
Code review was never about the code

If you work in software (as a designer, developer, PM, or any adjacent role), you’re probably aware of just how much AI has changed the way code is created. And if you’re an engineer, you’re definitely feeling the downstream impacts of AI’s speed. Way, way more code is being written. But the way we review code hasn’t changed that much. But if you’re not familiar, code review is a step in the software development process where developers look at code before it gets shipped. It’s been a cornerstone of engineering teams’ workflows for almost as long as there have been engineering teams. AI coding has turned code review into a bottleneck; a human can only look at so much code, so reviews have started taking longer, and each engineer’s review backlog is growing exponentially.1 AI code review tools have stepped into the breach, eliciting an earnest grumble from developers: AI reviewing AI-written code is like a student grading their own test. Execs don’t have much sympathy, though. We can move faster, so we should. So teams are stuck in a traffic jam, trying to figure out how to review code faster, without sacrificing quality. I’d like to argue that the source of this problem is more fundamental than speed vs. quality. We’re in this situation because somewhere along the way we swapped one question for another. Code review was always meant as a verification step: does the code produce the outcome we want? But it’s a hard question to answer, so we started asking an easier one instead: is this good code? Let’s go back to the original question. Code review should get better at verifying outcomes — faster, yes, but more accurately, and for the system as a whole, not just single lines of code. What is code worth? The premise of code review is that code can be good or bad, and that bad code can be turned into good code, and that good code is important. This is a sound premise. Bugs are obviously bad for business. But we’ve made an attribute substitution: we decide whether code looks good as a stand-in for whether the software works. Engineers use mental shortcuts to determine the goodness or badness of code. They range from very well-documented patterns (use guard clauses to return early, use pure functions where possible) to vibe-based ‘code smells’ (magic numbers, deep nesting). But these aren’t written in stone. They are debated and re-evaluated constantly. Even if there are inviolable definitions of good code, writing good code isn’t guaranteed to result in valuable software products. Sometimes, it works out that way; before Facebook bought it, WhatsApp kept its codebase lean enough that 35 engineers could serve 450 million users.2 But there are far, far more examples of software succeeding despite being written poorly: Undertale would never have passed a single code review (almost all of its dialog was one giant switch statement), but became one of the most beloved games of the past decade. Good code does not strictly equal good software. Code itself has no intrinsic value. So what are we actually reviewing when we review code? Verifying There’s just no substitute for actually running the code and verifying that it does its job well. I don’t mean unit tests, or even integration tests, but running the code in total, a full end-to-end test. Doing this at scale for large applications is difficult. At an org with hundreds of AI-enabled engineers, you likely have thousands of pull requests a day. Spinning up and breaking down complete copies of your entire application (likely, application cluster) is time- and resource-intensive. Even if you do manage it, verifying under realistic conditions may be completely infeasible (imagine simulating the activity that Stripe handles — 1.75% of global GDP). Which is to say that you won’t know if your code works or not until it’s in users’ hands. Traditional code review has two outcomes: You are confident enough that the code works well enough to ship it You are not confident enough that the code works well enough to ship it Verifying your code under the most realistic scenario possible (i.e., yolo, straight to production) has three: You are sure the code works, and it’s already shipped. Good job! You are sure the code doesn’t work, so you improve the code until it works You don’t know because the system failed in an interesting way. Instead of confidence, you have information, and can use it to improve the system. Verifying a major change by shipping it is risky, but the closer you can get to it, the more your review is actually worth. Feature flags, canary releases, observability and CI/CD — the stuff of modern devops — have all been commoditized to the point where it’s cheap to build in the safeguards that make the yolo approach tractable (even at Stripe scale). Stop reviewing code3 You’re probably doing code review for the wrong reasons. Let AI do the work of making code better: tracing code paths, finding, and fixing obvious issues. And if it’s a student grading their own test, so what? AI can make the code better. People can check if it works. Invest in the tools to verify your code in realistic conditions, deploying it directly to users if possible. Use your own eyes and brain to see it working, or see it not working. Learn from the difference, share what you learn with your team, and build feedback loops that improve the system the more it fails. And eventually the failures will become rare and incredibly interesting. Footnotes & References GitHub saw 1 billion commits in all of 2025; by April 2026 it was seeing 275 million a week. ↩︎ Cade Metz, “Why WhatsApp Only Needs 50 Engineers for Its 900M Users,” Wired, September 15, 2015. ↩︎ Of course, there are situations where safety means protecting human lives or massive economic outcomes, and reviewing code is the only safe option. The IRS shouldn’t ship updates to the code it uses to disburse tax refunds without reviewing the code. Waymo shouldn’t ship updates to its self-driving cars’ algorithms without reviewing the code. But you probably aren’t working for the IRS or Waymo. And if you are, get in touch ;) ↩︎

3 days ago • 1 votes
The new age of software

If you think about it, there is *a lot* of software that hasn’t been built across hundreds of industries because our best paid designers and engineers were occupied with building social networks and ad networks. "The best minds of my generation are thinking about how to make

2 weeks ago • 2 votes
Prompting as self-portrait

Weekly curated resources for designers — thinkers and makers.

3 weeks ago • 1 votes
Another Saturday, Another Song.

“Side Two” LP in progress. At 14 songs, it is nearly complete. I expect to release it before the year’s end. The post Another Saturday, Another Song. appeared first on Jeffrey Zeldman Presents.

3 weeks ago • 1 votes
📚 BoredReading

You seem to be enjoying this.

Join free to unlock everything.

Create free account

Already have an account? Sign in