Hacked By GeNErAL

April 7, 2016

Hacked By GeNErAL

Celebrities

April 6, 2016

Console Wars does a great job capturing Sega’s willingness to try new ideas. And a lot of the ideas involve celebrities.

It was interesting to read about them planning the Sega Star Kids Challenge and bringing celebrities to the Sonic 2sday event:

A practice session may seem trivial, but it was important to Sega that these young celebrities give the impression that they really did love videogames and weren’t just heartthrobs for hire.

Wouldn’t ever want to make them look foolish.

Blast Processing and tech specs

April 5, 2016

Again, the best parts of Console Wars are the behind-the-scenes looks at Sega’s marketing strategies. The Super Nintendo had Mode 7, which made games like Star Fox and Mario Kart possible. Now that I’m doing some image searches, I’m learning it was also used in other games for certain sequences, like every overworld map.

I like imagining a .ppt from Nintendo with a slide titled “Guidelines: fitting races into stories” with 7 bullet points underneath.

Sega didn’t have an actual thing to strike back with, so they decided to strike back with not an actual thing:

While looking through the manual, Latham found something that kind of, sort of, maybe fit the bill: Burst Mode, which in theory allowed the Genesis to process code faster than Nintendo’s chip could. Although this sounded like exactly what the marketing team wanted, Latham explained that Burst Mode actually had very little to do with the graphics, velocity, and overall performance of Sega’s games. To say that Burst Mode was the reason that Sonic could move so fast would be like saying that cheetahs were faster than elephants were because of their spots.

Burst Mode turned into Blast Processing.

I remember always checking the “Graphics” rating first when reading EGM or GamePro. But I knew that high gameplay scores went further for how much I’d enjoy the game. (There’s something about UX in there.)

The book ends in the very early stages of the 32-bit era. When our family got a Playstation, one of the first giant-jeweled-case games we got was NBA Live 96.

I remember thinking my dad would think this purchase was totally worth it if he saw the graphics. So one day I told him close your eyes okay now open them.

“Can you tell it’s not live TV?”

Protips and more

April 1, 2016

Prior to reading Console Wars, I had some perspective on video games in Japan. Actually, it’s a little unusual. My dad was in the Navy and I grew up on military bases in Japan in the 90s. I played console demos in Japanese department stores and spent plenty of time in Japanese arcades basically run by Sega. But our family and all my friends had American consoles.

And we had english TV channels, but they had weird mixes of syndicated shows. The oddest part was that instead of commercials for products, there would be commercials about military life and American history. So most of the American marketing I experienced was through video game magazines.
They talk about the impact of a particular GamePro cover where Star Fox is on the front of it. From Console Wars:

“But why?” Arakawa asked Tilden, looking at the April 1993 issue of GamePro magazine. On the cover, right there in front of them, was artwork from Nintendo’s Star Fox. Not only had this artwork been intended for Nintendo Power, but White had specifically met with Arakawa, Tilden, and Harman to discuss sharing it with outside magazines and had explicitly been told not to do so.

As long as I remember, our parents let us subscribe to at least one video gamemagazine. And any time we went to the book store I’d first look at Goosebumps for the newest release then read the game magazines.
Game Players magazine had a newsletter that, looking back, seems like weird internet before the internet became what it is today.

Something I remember is one issue where a reader wrote inn asking how the magazine makes the stitched together maps. And they said it was software that costs hundred and hundreds of dollars.

I remember picturing some kind of mega-expensive super computer. Where like they’d make the brontosaurus in Jurassic Park and then in another window they’d have Link to the Past maps. Now I realize it was probably Photoshop.

Game Players turned to Ultra Game Players then disappeared altogether. Then we switched to an EGM subscription. GamePro (of PROTIP fame) skewed younger. We had some of those but they were usually one off purchases from the book store.

Nintendo’s side project was publishing a magazine with more than a million subscribers. As far as I remember, the book store didn’t have Nintendo Power. So the only kids that had copies had subscriptions.

I remember the Star Fox cover but really had no idea it was a big deal. I was probably in 2nd grade or 3rd grade so I didn’t understand that anything was a big deal. I really had no idea that Nintendo Power was a giant monthly advertisement.

(Then one day you find out Saturday-morning cartoons were toy advertisements and the world falls apart. That’s the adult version of finding out Santa Clause isn’t real. In between those discoveries is finding out wrestling isn’t real.)

No mention of RPGs

Okay I exaggerated, Console Wars mentions RPGs exactly once:

Oshima partnered up with Yuji Naka, a brilliant hothead in the programming department who was responsible for one of Sega’s most popular series: Phantasy Star, a sci-fi role-playing game (RPG) about a resilient young female warrior bent on galactic revenge with the help of a muskrat named Myau and a wizard named Noah.

Side note: I thought Zelda was generally considered an RPG. According to my research (clicking a few links on a Google search), most people don’t consider it an RPG. And get pretty passionate about it not being an RPG. Anyway, I guess that further helps the case that Console Wars has one single mention of an RPG.

Searching the book for “Final Fantasy” returns nothing. In America, RPGs might not have had as much an impact on the 16-bit console war as, say, Mortal Kombat. But Final Fantasy III should get at least one mention. (The book ends before Chrono Trigger’s release, so there’s at least some explanation.)

RPGs make up 6 of the top 20 best selling SNES games.

Anyway, if RPGs were mentioned I would’ve had a better excuse for writing about a top–3 life achievement of mine…

I grew up in Japan on a U.S. Navy base. Which means it’s not really like growing up in Japan and not really like growing up in America, either. Families would go off-base at night or on weekends. And you’d also live off-base while you were on a waiting list for on-base housing.

On these weekend trips out, my and I would wander around the videogame section of a department store (Daikuma or Da’e) while our parents got groceries. On one of these trips, we noticed people gathered around a spinning wheel and walked over.

After watching a few times, it looked like you paid 2000 yen, spun the wheel, and got to pick from either 1, 2, or 3-game packages. Anyway, our mom let us spin and we got the 2-game choice. We picked the package with Super Smash TV and… some game with a bird on the cover. My brother had heard of the game but we were mostly in it for Smash TV.

The other game was Final Fantasy V. I was extremely bored any time I watched my brother play it. Then one day I tried it out and it didn’t make sense at all. Literally. It was in Japanese, after all.

I started out wandering aimlessly. Then I continued wandering around aimlessly. For dozens of hours. And just memorized the menu location for some useful potions (mostly just elixir and HP recoveries).

A main character blinks away, teleporting somewhere. Some girl joins the party for unknown reasons. Then I realize the guy teleported to heaven because guess what actually he died.

Dozens of hours turned to dozens and dozens of hours. Memorizing the +100HP potion became memorizing the +1000HP potion. Then I beat it.

I still have basically no idea what the story is about.

So, you know, don’t make your UX like that.

Trying to make it to shittyuiuxanalogies.tumblr.com. (For a better UX article based on Final Fantasy, check out Final Fantasy’s Guide to Onboarding.)

Mortal Kombat II behind the glass case

March 30, 2016

“Let me show you something.”

I stepped aside and an older kid—picture young John Connor—took the joystick. A few moments later Sub-Zero ripped someone’s head off with their spine attached. Awesome.

This was my first time seeing a fatality in Mortal Kombat. Apparently some parents didn’t think this was great, so the first Mortal Kombat had sweat instead of blood. Except for the kids with a Genesis.

“Some sort of blood code,” Garske explained to Kalinske. “So when you buy the game, it comes without any of that over-the-top gore and violence. But then all you have to do in order to get the game to look just like it does in the arcades is enter a code. A combination of buttons and then boom—blood everywhere.”

So on the SNES when I’d try to rip a spine out, instead I’d see this:

“As long as the shattered body parts aren’t red ice, we’re Gucci.”

I made the last quote up. My point was going to be that the SNES had watered down fatalities. But… this seems pretty brutal too. But these seemed much tamer as a kid.

I remember being really aware of how the first game had sweat. Nobody was buying the SNES version and most of my friends were Nintendo kids. And that it was a big deal that the sequel would have blood without a code.

I have cloudy memories of going to an AAFES store with my brother and our parents to get Mortal Kombat II. And it was behind this glass case with a rating on it. (Though it wasn’t one of the ESRB ratings that would eventually come out.)

Anyway we got it and then played it. A lot. I remember seeing MKII the first time at an arcade in an airport. And someone (again, an older kid) had what looked like a strategy guide but it was just a bunch of printouts.

And these printouts had all the moves and fatalities. That might have been my first exposure to anything related to the internet.

Console Wars talks about the different approaches toward violence that SEGA and Nintendo took.

Getting familiar

March 28, 2016

One of the patterns is called “Familiar Tools” talking about the tools programmers use.

Write down a list of your familiar tools. If the list has less than five items, start hunting around for tools that will fill the gaps in your toolbox. This may simply be a matter of identifying a tool you already use but don’t know well enough, or it may involve finding new tools altogether.

I’ve written some in-depth posts about learning the basics of prototyping tools like Form, Origami, and Framer. The “Familiar Tools” pattern reminded me to take a look at my current toolbox.

There are a lot of different tools out there, and if you’re just starting out it can be overwhelming to pick some out to learn. You might even be frozen by all the options.

As far as a hard-skill toolbox goes, here’s what I’d recommend to a new designer. Learn a different tool in each fidelity well.

Pen and paper for lo-fi thinking: Sometimes completely overlooked. Tools for animating microinteractions are fun to use. They’re fun to play with so it’s tempting to jump into super high fidelity and work with motion.

If you’re designing in high fidelity and not testing with actual users, it’s probably too early. Pen and paper can take you a long way when thinking through ideas on your own.

Static mocks for going through flows: Sketch. It’s become pretty standard. At least as far as the echo chamber goes.

High fidelity prototypes for mobile: A good old “it depends”. Just try them out and see which ones click for you. Framer and Origami have great communities and that goes a long way toward the usefulness of a tool. I still want to try Principle.

High fidelity prototypes for desktop: The advantage of the mobile interaction design tools is that they let you try things out without learning Swift/Objective-C or Java and learning the respective development processes.

HTML/CSS is more approachable than any toolset for native development. Right click in the browser, click “Inspect”. Tinkering around, changing values, and seeing the changes might be the best way to start learning CSS.

Get proficient with Chrome developer tools. Or the equivalent in the other browsers. Sit with a developer you work with and have them show you around the inspector and console. It’s a great investment of time.

Visual design: Here’s my biggest gap. Illustrator seems to still be the tool of choice of digital illustrators. I’d love to learn.

As far as soft skills go, they’re harder to sit down and practice. A lot of it comes through experiencing different situations firsthand. (I’d recommend actively avoiding the soft skills such as getting offended about interchanging UX/UI/interaction/product designer titles and thinking up UX analogies.)

We’re talking about practice

March 22, 2016

Apprenticeship Patterns has a pattern called “Practice, Practice, Practice”. Adewale and Dave talk about having a place where you’re comfortable making mistakes. Again, I’ll connect this apprenticeship pattern to something I read In Deep Work. A lot of the ideas in Deep Work also overlap with the idea of deliberate practice:

Its core components are usually identified as follows: (1) your attention is focused tightly on a specific skill you’re trying to improve or an idea you’re trying to master; (2) you receive feedback so you can correct your approach to keep your attention exactly where it’s most productive.

Many designers already receive plenty of feedback during the design process. (If not, check out my book notes on Discussing Design. It’s a great book by Adam Connor and Aaron Irizary about giving and receiving good critique.)

Deep Work is more about the focused-attention component. If you’re going to spend deeply focused time on something, you’ll want to make sure it’s the right thing. Apprenticeship Patterns provides some guidelines for picking exercises for practice:

Make sure that it’s just a little harder than one you know you can easily solve. You should have to struggle to solve it the first time. Solve this exercise from scratch once a week for the next four weeks, and observe how your solutions evolve. What does this tell you about your strengths and weaknesses as a programmer?

Day to day design work might not always stretch those skills. If that’s the case, sit down and identify areas you want to grow. Then find or create exercises of your own for practice.

When I started learning Framer, I learned a lot by trying to re-create animations from different apps. These exercises were usually scoped to a single interaction. I tried re-creating pull-to-refresh animations, I tried re-creating parts of the Material Design launch reel, I tried re-creating examples from the Framer docs.

The great thing about Framer is that the source code is available for a lot of things you’ll want to do. You can always attempt and then compare your approach to a working example and see where you can improve.

It’s a little different for Sketch and the other interaction design tools. It might not be as easy to find source files to learn from. This is where it’d be great to have a mentor to look at your work. You can share your approach to different things and they can explain where you can improve. I seem to always learn some sort of technique when I watch others using Sketch.

Retreating into competence

March 15, 2016

Apprenticeship Patterns talks about going deep into new subjects as a good way to learn. The risk with going in the deep end is that you’ll sometimes get in hairy situations. Competence can be the edge of the pool: something familiar that you can grab onto. They discuss applying the “Retreat into competence” pattern:

short-term fix while you gather your strength to bounce back. Set a time limit (or “timebox”) for yourself, such as “I will spend the next 10 minutes refactoring the JavaScript validation for this page before I optimize the SQL queries that provide the data.” Or “I will spend the next four hours implementing the command-line interface for this tool before I learn how to call this third-party SOAP API.” Or “I will spend the rest of today improving our test coverage before taking on the job of optimizing our code that is affected by Python’s Global Interpreter Lock.”

I tried thinking about how this could be applied by designers. A lot of the apprenticeship patterns have you looking at how you can stretch your knowledge. You look at valuable tools and techniques you’re not familiar with and deliberately practice with them.

As a side effect, you’re thinking through tools you are familiar with. These comfortable tools are the ones you can retreat to. That might mean taking a break from the latest prototyping tool to retreat into Sketch. Or taking a break from thinking through multi-screen flows to focus on some motion interaction with Framer.

Open the firehose but don’t drown in the shallows

(I’m trying to write book notes compilations one section at a time. One excerpt per day with the goal of filling one iA Writer screen up. About 350 words.)

This week, I’m focusing on Apprenticeship Patterns, by Dave Hoover and Adewale Oshineye. Dave and Adewale talk about software as a craft and give guidance on how you can improve as a craftsman. It’s targeted toward developers, but a bunch of it applies to designers. (And even beyond that.)

One of the patterns is called “Expand your bandwidth”:

Expanding your ability to take in new information is a critical, though sometimes overwhelming, step for apprentices. You must develop the discipline and techniques necessary to efficiently absorb new information, as well as to understand it, retain it, and apply it.

They discuss setting up Google Reader to consume RSS feeds. They discuss one of the pitfalls that seems all too common today:

It’s possible to become obsessed with gathering and consuming new information, particularly as it becomes easier and easier to get at up-to-the-second thoughts on the most prolific thinkers in our industry. Some people could become lost in the sea of interesting information, and never come back to actually crafting software.

The book is from 2009 and there’s no mention of Twitter for keeping up with the latest information. That said, I was a pretty heavy Reader user and was just as addicted or even more so I ever was of Twitter. Reader made a lot of full content readily available.

One day, I remember stepping back and thinking, “Do I really need to see basically the exact same news from Engadget and Gizmodo?” That started the culling and then I was able to really cut things down and then eventually accept that I don’t need to read every. single. thing.

Because there’s value in all the available information out there, it might seem like a good idea to seek out as much of it as possible. Cal Newport discusses this in his book Deep Work:

This argument, however, misses the key point that all activities, regardless of their importance, consume your same limited store of time and attention. If you service low-impact activities, therefore, you’re taking away time you could be spending on higher-impact activities. It’s a zero-sum game. And because your time returns substantially more rewards when invested in high-impact activities than when invested in low-impact activities, the more of it you shift to the latter, the lower your overall benefit.

It’s important to remember that time taken by shallow activities could be applied to more important activities. Having taken extended breaks from different social media, there’s major FOMO. It goes away once you realize enough times that you never really miss much.

Design Sprints Digest: Issue 2

March 14, 2016

Design Sprints: Issue 2

“I’ll publish every two weeks” — Me, three weeks ago

For this issue, I’ll share one link related to each stage in a design sprint.

Understand

Design Details is my favorite design podcast. Brian Lovin and Bryn Jackson talk to a lot of people whose work I admire. Design Details lets me listen in on casual conversations between designers. It’s great to hear other designers talk about their interests and approaches to different problems.

Last month’s Best Of episodes are a great place to start. Episode 92: Best of 2015 – Part 2 has an excerpt of Josh Puckett’s interview. He talks about building things:

I sort of just grew up where there wasn’t this divide for me where there’s designer, where you only did Photoshop. And engineer, where you know you’re only doing code. It was sort of like “I want to make this thing” and to do that you’d need both these things.

Dan Mall said something similar a couple episodes earlier:

We have formalized our discipline so much that no one knows how to be scrappy anymore. I remember… okay this is totally OG like “I built sites in tables”. But when I learned web design, there wasn’t such thing as a back-end developer or a front-end developer. You made the website.

That meant you designed it, you animated it, did Flash, you wrote the PHP, you wrote the Perl script. Like I remember writing CGI scripts. I didn’t know what I was doing. I was copying and pasting things from the internet. Making forms work. I didn’t know what I was doing. But I made all of it. Made the whole thing.

Now I have npm and gulp to not know what I’m doing. Dan talks more about how specialization is necessary but we’ve lost some scrappiness.

This reminded me of how I learned. I had a problem I needed to solve: A lot of Counter-Strike clans had awful websites. I wanted my Counter-Strike clan to have an awful website also.

I had made some HTML sites (insert Made with Notepad badge) but needed to know a little more for this. I learned to install a bulletin board and customize it. Editing PHP files was where I had to be careful. MySQL was where I could really break things. I now know that as back-end stuff. And still stay pretty far away from it.

In a design sprint, everyone puts different hats on you make something together. Bringing the scrappiness back, one week at a time.

Diverge

No surprise, I’m a fan of the Google Ventures design partners and am looking forward to their book, *Sprin*t. Jake Knapp wrote about designing the book cover with Jessica Hische:

To begin, we “sketched” on the computer: each person using clip art and their favorite illustration tool (that’s Sketch for Braden Kowitz and Daniel Burka, and Keynote for me). We ended up with 200+ rough sketches and variations.

It’s been cool to see the series of Co.Design articles evolve into a book. In that original overview, Jake mentions its origins:

If you think you’ve heard of this model before, well, you’re right. It’s based on the design thinking structure championed by IDEO and Stanford’s d.school. However, I’ve experimented and tweaked the process a bunch over the last few years. The version I’m going to share works especially well for startups.

Which reminds me of Julie Zhuo’s article about creative confidence. It’s a term sharing that shares roots in design thinking concepts from IDEO and Stanford’s d.School. Julie describes some ways to gain creative confidence:

Invest in your process. A rock-solid process — a series of repeatable actions — is the golden goose to building creative confidence.

The design sprint is an effective, repeatable process. There’s not always time for that, so I’m learning to use elements of design sprint stages in my process.

It’s helpful to think about what stage the current problem would fit into and how we’d work through that in a sprint. If the ideas aren’t coming, I’ll try some timed sketching. If prototyping is getting unwieldy, I’ll sketch out a quick storyboard to re-focus on the user story.

Decide

Jessica Abel wrote about idea debt. She got the term from from a guest on her podcast, Kazu Kibuishi:

Now I’m actually solving problems in the moment, and that’s so much more exciting than than trying to fill years of what I like to call my “idea debt.” That’s when you have this dream of this awesome thing for years. You think, “Oh, I’m going to do this epic adventure. It’s going to be so great.” The truth is, no matter what you do, it will never be as great as it is in your mind, and so you’re really setting yourself up for failure.

In Jessica’s post, she has a list of examples of idea debt:

You’ve read 15 free online guides to blogging, built three editorial calendars, have notes on a dozen posts, but you haven’t gone live with your blog.

A little too close to home. In everyone’s overwhelming list of ideas, there are a few that stand out but even those can’t all be pursued. I’ve written about 1-person design sprints and have found them great for getting to a stopping point. A sprint won’t get you to an MVP, but you’ll know what the next steps could be and how much effort that would require.

Prototype

A lot of people are familiar with Google Docs collaboration. Harold Kim wrote about his success using Google Drawings for collaboration:

I wanted to find something that would give us the feel of a central discussion hub, and also convey a large-scale view of a design and its components.

Another cool thing is that you can copy and paste straight from Drawings to Google Slides. Of course, as far as slideshows go, there’s also Keynote. In those 2013 design sprint articles, Jake Knapp went over how great Keynote is for prototyping:

• It’s fast.

• It’s easy to make things look pretty good…

• But it’s impossible to make things look perfect, so you don’t get too precious.

• Anybody can quickly learn to use it; not just designers.

• The slideshow format is a natural fit for story-based design.

A lot of that is true for Slides, though it doesn’t match Keynote for animation. I’ve been on a sprint that used Slides for prototyping. It was amazing to see everyone contribute and continually review the story as screens came to life.

Test

Dave Johnston designed Counter-Strike’s Dust and Dust 2. Iterating and testing has existed since the beginning of, well, creativity. And these writeups show how critical testing was for a 16-year-old mapmaker in 1999:

The problem was I’d been treating this brand-new gametype as if it was one I knew already – Capture the Flag – except in this CTF mode the flag (the bomb) started at the Terrorist spawn. But defusal wasn’t Capture the Flag. In fact, it was so utterly different that hardly a comparison could be drawn. Placing the bomb in the CT spawn hadn’t even crossed my mind. I made the change, and sent it back for playtests.

Playtesting is an important stage of any map’s development cycle. Without it, there’s little way of knowing exactly how a map will play when faced with real people; real players who haven’t the intricate knowledge of the map that you have. It’s playtests that inform you of flaws that need fixing before release – if the map is even fit to be released at all.

As a 14-year-old in 2000, I appreciated the results of this process. These maps were like second homes with giant crates to sit on and friends to defuse bombs with. Great place to visit for a quick afternoon study break then realize it’s 3am the next time you check the clock.

In the next edition…

That’s that for now. I’m slowly working toward a better system for writing this newsletter. (Spoiler: I’m starting to think that system will be called “actually sitting down and writing.”)

Over 500 quotes

February 29, 2016

I started a refresh for this site. I want to continue writing regularly. However, I don’t think it will take the form of long articles about design sprints and design tools. I started writing newsletters to experiment with shorter writing, but even those took longer than I expected each time. I still want to send something out. For the next issue, I’m going to try writing a short post each day and collecting those to send together bi-weekly.

I would write the newsletter and then re-write over and over and try to make the whole thing coherent. Sometimes things got a bit forced because links just don’t always relate. And I was finding myself putting it off because I was looking for very large chunks of time to work on it. And of course, I wasn’t finding those large chunks of time.

Writing seems similar to working out in that you’ll see improvements through consistency. You can’t work out for 8 straight hours to make up for 8 individual hour-long workouts.

I’ll share links and book quotes and share some thoughts to how they can relate to different stages of a design sprint. Sometimes. Other times I’ll share how they relate at least to design.

Thanks for bearing with me.

Last week, I read Apprenticeship Patterns by Adewale Oshineye and Dave Hoover. I picked it up after seeing Ale Muñoz (designer/developer working on Sketch) recommend it as a resource for learning how to teach in a response to Koen Bok (Framer co-founder).

It’s about improving as a developer and looking at programming as a craft. A lot of it can be applied to improving as a designer. (Not to mention a ton of other careers.) One of the patterns discusses the importance of writing down what you learn:

When Dave was Reading Constantly during his apprenticeship, he kept a text file in which he transcribed all the quotes that shaped his learning. Over the years, that file grew to contain over 500 quotes, and Dave eventually decided to upload it and share it online.

(And “Reading Constantly” is another pattern I’ve been trying to apply.) Over the years, I’d like this site to have over 500 quotes. This is one of the first.

Book Notes: Discussing Design

February 17, 2016

Communication is an important soft skill for product designers. In Discussing Design, Adam Connor and Aaron Irizary discuss the importance of critique in the design process.

A lot of communication within a design team comes in the form of critique. Adam and Aaron explain how to deliver and receive critique. (For communicating with PMs and engineering, I’ve really enjoyed another book: Articulating Design Decisions by Tom Greever.)

You can improve as a designer by delivering useful feedback to other designers. The same way teaching is a great way to solidify knowledge, delivering useful feedback requires you to think about different aspects of design and organize your thoughts.

What kind of critique is useful? Let’s take a look.

Critical thinking

I love Dribbble — it’s a positive place on the internet, and that’s a great thing. However, it’s not the best place to look for effective critique. Adam and Aaron’s three key elements to effective critique can help explain why:

“1.) It identifies a specific aspect of the idea or a decision in the design being analyzed.”

People complain that Dribbble feedback isn’t useful for finding flaws and improving design. “Good job” and “Great work!” aren’t specific at all.

“2.) It relates that aspect or decision to an objective or best practice.”

A lot of time, the work shared on Dribbble is a detail shot or some other form of a very small part of a larger project. There isn’t enough shown and sometimes there isn’t an objective at all to relate critique to.

You should be basing design decisions on objectives and best practice. When starting out, it’s good to lean on best practices to build out something that mostly works. It’s okay to stray away from best practices if your solution works better for a project objectives.

When critiquing, think about design aspects that are going against objectives or best practices. Otherwise you might simply be saying that your arbitrary choice is better than their arbitrary choice.

“3.) It describes how and why the aspect or decision work to support or not support the objective or best practice.”

Good critique requires effort on both ends. Presenting something while also explaining all the factors involved — constraints, timelines, background info — takes effort. Parsing this info and fully understanding the problem being designed for also takes effort.

Combined, this is probably why there’s not a hugely popular community for useful design feedback. If people took the time to do that on Dribbble, it wouldn’t be a light, fun place to go to. It wouldn’t be Dribbble.

Feedback that doesn’t nail these three elements might fit into another category. Let’s take a look.

Reactions and directions

Discussing Design describes three types of feedback: reaction-based, direction-based, and critique.

Reaction-based feedback includes the quick emotional responses you’ll often get when showing something for the first time. “Nope.” and “Good work!” are examples. You can tell how useful feedback is by asking the following questions:

“…are the people from whom you’ve asked for feedback reflective of your design’s actual audience? Are they looking at it the same way your potential users would? Does this reaction divulge anything specific about any of the design decisions you’ve made so far or their effectiveness?”

With reaction-based feedback, the answer to these questions is usually “no”.

If you leave a meeting with a list of changes, that’s direction-based feedback. It answers “yes” to some of the above questions, so there’s a time and place for it. But it can be an issue:

“Similar to reaction-based feedback, direction-based feedback without any explanation indicates nothing about the effectiveness of your decisions in meeting the design’s objectives. Sure, if the person giving you feedback is the one who will ultimately approve the design, she might supply you with a to-do list that you could act upon to get her approval, but getting that approval and creating an effective design are not necessarily the same things.”

Sometimes you might hit the three elements of critique and it still won’t be useful. How come? The timing might be off.

Critique Timing

Connor and Irizarry provide a good rule of thumb for when to critique solutions:

“For example, the best time to critique a solution is after it is 20 percent baked but before it’s 80 percent baked.”

When you’re in that 20%–80% sweet spot, it’s good to receive critique often. Discussing Design refers to “Dailies” done at Pixar. I went to the bookshelf (read: searched my Kindle) to check out what Edwin Catmull had to say about Pixar Dailies in Creativity Inc.:

“The first step is to teach them that everyone at Pixar shows incomplete work, and everyone is free to make suggestions. When they realize this, the embarrassment goes away—and when the embarrassment goes away, people become more creative. By making the struggles to solve the problems safe to discuss, then everyone learns from—and inspires—one another. The whole activity becomes socially rewarding and productive. To participate fully each morning requires empathy, clarity, generosity, and the ability to listen. Dailies are designed to promote everyone’s ability to be open to others, in the recognition that individual creativity is magnified by the people around you. The result: We see more clearly.”

Engineering won’t have time to incorporate design improvements after the 20%–80% sweet spot. Before the sweet spot, it’s better to continue creating without stopping for critique. How come? Each task requires a different mindset.

Mindsets: Creative vs. Analytical

Many writers write and edit separately because they require different mindsets. One mindset is creative and the other is analytical. Adam and Aaron discuss how these different mindsets apply in design and critique:

“When designing something, the brain operates as a toggle, switching between creative thinking — where individuals are generating ideas or assembling parts of ideas — and analytical thinking — where they are determining whether what they’ve designed so far is in line with what they are trying to achieve. Experienced designers, artists, engineers, and others have learned how to be deliberate in controlling when to make this toggle, periodically pausing their creative work to take a step back and critique what they have so far.”

Discussing Design lays out some techniques to facilitate effective critiques.

Design Studio

In the Google Ventures design sprint methodology, diverging and deciding are separate steps.

Teams generate as many ideas as possible with mind maps and Crazy 8s. At the end, participants select the best ideas based on the objectives.

Discussing Design describes a similar technique called Design Studio. They mention Todd Zaki Warfel adapting the technique from other design disciplines to the digital world. Back to the bookshelf, here’s an excerpt from Warfel’s book, Prototyping: A Practitioner’s Guide:

“In the world of architecture and industrial design, a design studio is a process, not just a physical place. This process is taught in every respectable architecture and industrial design program. You’ll be hard pressed to find a design studio class in computer science.”

“In studio classes, you design or prototype and present to your peers. Your peers critique your work, highlighting the strengths and areas that still need some work.”

Adam and Aaron describe a three-charrette activity to quickly go through multiple rounds of design and critique. Like Crazy 8s, it involves timed sketching. Their activity goes like this:

8 minutes for six sketches of different concepts
8 minutes for iterating on their strongest idea
20 minutes as a team to sketch one idea

Sum Up

Here are some key takeaways from Discussing Design:

Quality: Objectives and best practices are your guiding light for effective critique.
Timing: Critique is most useful when it takes place during the 20%–80% sweet spot.
Mindsets: Creation and critique require different mindsets and should be separated.

Embracing critique and following these principles will help you be more effective in delivering and receiving critique.

The Making Of: Dust

January 27, 2016

Dave Johnston goes in depth about designing Counter-Strike’s Dust. Iterating and testing has existed since the beginning of, well, creativity. And it was definitely critical for a 16-year-old in 1999:

The problem was I’d been treating this brand-new gametype as if it was one I knew already – Capture the Flag – except in this CTF mode the flag (the bomb) started at the Terrorist spawn. But defusal wasn’t Capture the Flag. In fact, it was so utterly different that hardly a comparison could be drawn. Placing the bomb in the CT spawn hadn’t even crossed my mind. I made the change, and sent it back for playtests.

Playtesting is an important stage of any map’s development cycle. Without it, there’s little way of knowing exactly how a map will play when faced with real people; real players who haven’t the intricate knowledge of the map that you have. It’s playtests that inform you of flaws that need fixing before release – if the map is even fit to be released at all.

I’d be horrified to see a count of how much time I spent inside Dust and Dust 2 in high school. Or even just last summer.

Book Notes: Founders at Work

March 22, 2015

In Founders at Work (2007), Jessica Livingston, founding partner at at Y Combinator, interviews 30 startup founders.

The Steve Wozniak interview alone is worth the price of admission, but it also happens to be posted free in its entirety on the book’s website. Check that out to get a sense of the questions, answers, and how thorough each interview is. (Put another way: the book is very long and also very good.)

The companies were founded from the 1970s to the 2000s. The interviews take place a few years after the dot-com crash, and slightly before iPods, phones, and internet communications devices became a single thing.

There were a lot of “Ohhh yeah” moments—the nostalgic kind, not the Macho Man kind. And they sort of come in two forms: 1.) memories from the founder stories where I could remember how that technology impacted me—90s things like Hotmail and WebTV were real fun for me, and 2.) memories from “present day” 2007 before mobile took over the world—like Digg driving heavy traffic to sites.

pg had this to say in an old HN thread about the book:

“Startups are basically comedies.” I highlighted a ton of things and picked a few to share—let’s start with some scenes from pg’s own comedy.

Paul Graham — Cofounder, Viaweb (and some investment firm)

Years ago, working out of an apartment wasn’t quite as accepted. Here, Paul Graham talks about trying to look legitimate when, you know, business people visited.

When that first giant company wanted to buy us and sent people over to check us out, all we had in our so-called office was one computer. Robert and Trevor mostly worked at home or at school. So we borrowed a few more computers and stuck them on desks, so it would look like there was more going on.

It really does sound like a sitcom. And the fun doesn’t stop there. Here, he talks about power going out in Cambridge. After running the generator indoors and deciding it was too loud (not, you know, too dangerous), they put the generator in the street and ran an extension cord:

It was running through our office at chest height and you could kind of twang it and it would go “boinnnnnggg.” Then we started the gas generator up in the street and that was just about bearable, so we ran the servers on that for a couple hours until the power came back.

pg: scrappy. Founders at Work has a lot of stories involving hardware: servers getting overloaded, learning to use a shrink-wrapping machine for CD distribution, servers going offline so someone could drive it somewhere with a T3 line, etc.

Steve Perlman — Cofounder, WebTV

When I mentioned “Ohhh yeah” moments, this was a big one for me. My cousin had a WebTV and so whenever my family visited his we’d use that to browse the web. And I have no idea what we’d even look at. At night we’d use his dad’s computer to play TetriNet.

With so many people connected in the Valley, founders also share early-day anecdotes from companies that aren’t their own. Here, Steve Perlman talks about Apple and dialog boxes:

The following is not something from my personal experience—it’s a story told to me by the Mac team—but they said that, when they first did the dialog boxes for the Lisa, instead of saying “OK,” it said, “Do It.” They found that people were reluctant to click on that, and they couldn’t figure out why. Then, once they had a test subject there who just wouldn’t click on it, they said, “Why didn’t you click on that little button there?” He said, “I’m not a dolt. Why would I click on that?”

So they changed it to “OK”. Don’t be a dolt, test with your users.

Mark Fletcher — Founder, ONElist, Bloglines:

A lot of common themes run through the interviews. They’re things you hear about all the time about startups and building products. Here, Mark Fletcher talks about finding a problem to solve:

I started ONElist because I wanted to start a mailing list for my parents, and at that time you had to download software and you had to have a computer connected to the Internet. It was just really difficult for an average person to put together a mailing list. So it was the same thing. I guess my advice is: solve a problem that you have, first and foremost, and chances are, other people may have the same problem.

How do you find a good problem to solve? Solve your own. Ben Trott and Mena Trott, founders of Six Apart, created Movable Type because there wasn’t a great existing solution for Mena’s rapidly growing blog. Stephen Kaufer built TripAdvisor after trying to plan a trip and finding the end steps of booking had solutions, but planning where to go and stay wasn’t a great experience.

Another theme Mark Fletcher talks about is iterating:

So just get something out there. If you find really early versions of ONElist or Bloglines on archive.org, the websites are horrible. They are crap, they don’t have any features, they just try to do one thing. And you just iterate because users are going to tell you what they want, and they’re your best feedback. It’s critical just to get something out quickly. Just to start shipping and then you can iterate.

Founders at Work was published before The Lean Startup when lean methodologies and MVPs weren’t so widespread. Some of the concepts surely existed, but others wouldn’t work when releases were months or years apart. Charles Geschke, cofounder of Adobe, talks about Xerox in the 70s, “They said, ‘Oh wait a minute. At Xerox it takes us at least 7 years to bring a product out.’” Not to mention iterating after that.

Joshua Schachter — Founder, del.icio.us

The variety of people and companies profiled is great. Some grew to thousands of employees, some stayed small, some were funded, some were bootstrapped. Some bordered on ruin and others say things along the lines of “I don’t know, it actually went pretty smoothly!”

Here, Joshua Schachter talks about building del.icio.us in his spare time:

I could come in and look at it, figure out what I’m doing, do it, and be done for the day in 15 minutes. So if I could get one thing done a day, I was happy.

I love this. Success comes through a lot of paths and it’s good to see that something millions of people found useful was built in (sometimes very) small chunks of free time.

Stephen Kaufer — Cofounder, TripAdvisor

Again, a lot of companies built things we take for granted now. I booked a trip to Spain with some friends last year and, along with other sites, TripAdvisor was part of that. Still it was this whole production to plan out.

I can’t imagine planning without those resources. Stephen Kaufer talks about planning a trip before TripAdvisor and learning an island wasn’t all that great through a chat room. Here, he talks about finding content for TripAdvisor:

Then we hired people to read every single travel article we could find on the Net, and classify that article into our database, and write a one-line summary. It’s a fairly significant effort, and people that we talked to said, “You’re nuts. You’ll never finish.”

Do things that don’t scale.

Ron Gruner — Cofounder, Alliant Computer Systems; Founder, Shareholder.com

The most entertaining stories are the most ridiculous. Ron Gruner shares a story about an 800-number mixup. A company printed millions of annual reports with the wrong 800-number for the shareholder’s call. Reprinting wasn’t an option, so Ron Gruner and his team had a few days to figure out how to take that number over.

Because of privacy issues, the paging company wouldn’t give up their customer’s details. Ron shares their solution to this privacy issue:

Then Josiah Cushing, one of the college grads I had hired, during our staff meeting said, “Ron, why don’t you try hiring a private detective?”

The guy who owns the number agrees to transfer the number over as long as they pay for his pager subscription for a year. And a subscription for his wife. “We’ll make it two years.” Not much of a price to save an entire company.

And then there’s the “Ohhh yeah” moment of remembering that pagers were a thing.

If you have any interest in startups or technology, Founders at Work will have something you’ll like. In a few years, maybe it’d be cool to see a sequel with today’s companies. “Our site was getting hammered. We had to spin up more Heroku workers.” Maybe not.

Origami Screencast: Pivot

After writing about Origami and Material Design, I wanted to create screencasts of the examples to show how they’re put together. This is the first.

Facebook has great video tutorials on the Origami site. I’d like to create examples and make screencasts that are around 2 to 4 minutes. They won’t be as comprehensive as what you’ll find in Origami’s tutorials section, but I’m hoping to have each video focus on just one or two concepts.

When learning Angular a few years ago, egghead.io was one of my favorite resources. John Lindquist started egghead.io with a very minimal layout and focused on releasing short videos. Now it’s one of the best sites for learning front-end frameworks.

It’d be great to build up something like that, but for now I’ll focus on releasing short videos. I just finished reading Founders at Work and still have the shipping mentality discussed in so many of the interviews fresh in my head.

Book Notes: Show Your Work

March 21, 2015

I don’t read particularly quickly, but I finished Austin Kleon’s Show Your Work in a single sitting. It’s great for identifying what work is worth sharing and getting inspired to share it more frequently.

Here are the book’s ten main points and how they apply to me, design, development, prototyping, and my plans for this site.

You don’t have to be a genius
This is very good for me.

Think process, not product
I’m glad I really enjoy prototyping. It’s part of the process and leads to a better end result. On the other hand, it’s important to remember it isn’t the end in itself.

The idea of focusing on the process falls in line with other things I’ve read about work and learning. It becomes a cycle. When you learn to enjoy the process, you’ll improve and as you improve you’ll enjoy the process more. This gets you past dips and leads to better end products.

I forget where I heard this, but someone pointed out that people overestimate what they can finish in a day and underestimate what they can get done in months or a year. This can make it hard to start something big because you don’t think you’ll be able to finish it. But if you show up every day it adds up.

Share something small every day
After a few years of having a Dribbble account, I finally posted one thing. But I’ll start sharing more there. For all the flak it gets about comments being “Good job!” well, is that so bad?

It’s probably not the best place if you’re looking for serious critiques to improve things. But a design community with positivity as its core is, well, a net positive.

Open up your cabinet of curiosities
I’ve been linking to things on this site but I’m thinking of changing the format for sharing links. The ongoing link blog is sort of dead. Long live the newsletter.

Tell good stories
Austin Kleon talks about how art sometimes isn’t immediately interesting until you learn the story behind it. But something seemingly mundane with a good story is interesting because the story is interesting.

In that sense, I can look at the design sprint posts as stories explaining how certain prototypes came to be. I love reading other design process posts. Here are a few that come to mind:

I can’t get enough of these. They’re good stories.

Teach what you know
I try sharing what I know about Framer, Origami, and Form. Even with varying skill levels with each tool.

I’ve listened to Ben Orenstein’s Giant Robots podcast for a few months now. Learning and teaching come up as topics regularly in episodes. He encourages blogging every day:

Write about what you’ve learned so far. Don’t make the excuse that you’re just a beginner. Imagine someone who is two months behind you and write for them.

Recent beginners can be better at helping a novice because they just went through the same issues. Experts can lose that perspective. A huge benefit of it is that it really solidifies your own knowledge. Through teaching, you organize your own knowledge and identify the gaps that can be improved.

I’ll continue writing and putting videos together as I learn.

Don’t turn into human spam
My greatest fear. I was an over-sharer through high school and college. Then pulled it back in the past few years. And now I’m slowly ramping it up. The best way to avoid turning into human spam is to create interesting things. If spammers sent out a bunch of stuff people loved and found value in, well, it wouldn’t be spam.

Learn to take a punch
I wrote a Material Design post last year and was pretty excited that people were reading it.

Then one person tweeted it was “boring as hell”. It’s fine, I was ready for that jab. But then some designers I really respect favorited the tweet. So it was like the jab was chained into an E.Honda special.

This reminds me of one of Pasquale D’Silva’s tweets: “A glitch in many designers is the lack of ability to detach emotion from criticism.” It’s been really helpful to remember that criticism is free feedback.

Sell out
I’d love to. I’m putting affiliate links in book note posts and that’s about it so far. I read a lot of books and won’t be writing notes for all of them. It’d be great if it could pay for a better microphone or something of that sort.

In the meantime, I’ll stay focused on creating useful content.

Stick around
The first thing I wrote about design that anyone really read was about a personal design sprint. I’ve written a long piece about once every month or two since then. I want to keep it up. But I also want to start writing shorter things. Which is why I started designsprints.com.

I’ll stick around.

Futures of text

March 8, 2015

Jonathan Libov took a thorough look at text and its role in future technology:

It can be indexed and searched efficiently, even by hand. It can be translated. It can be produced and consumed at variable speeds. It is asynchronous. It can be compared, diffed, clustered, corrected, summarized and filtered algorithmically. It permits multiparty editing.

Gets back to the idea that sometimes the best UI is no UI. Text handles a lot on its own.

Write a rapid prototype first

Terence Tao talks about using rapid prototyping when writing math papers:

I found that the technique of rapid prototyping from software engineering is useful in ameliorating these difficulties. According to this technique, one does not write the paper in linear order, and one also refrains from the temptation of writing the easiest or most straightforward portions first.

I’m always interested in reading how prototyping can be applied in other disciplines. Also nice to see that he sometimes just goes ahead and writes the fun parts:

I must admit that sometimes (especially for shorter papers) I take a very different approach, writing the “easy” and “fun” parts of the paper first (e.g. the introduction, or some simple lemmas), and try to use the momentum generated to then write the rest of the paper quickly.

Found this after reading his profile in The Sydney Morning Herald—Terence Tao: Mozart of maths.

Origami and Material Design

March 3, 2015

(This is by me and posted on Medium.) I dove into Origami this weekend. When learning a new tool, whether it’s design or development, it’s good to have a project in mind to apply your learning to. Here, I wanted to re-create some of the animations from the Material Design guidelines. They weren’t so complicated that I’d be in over my head, but they stretched me enough that I’d have to learn a few new techniques to create each one.

Origami 2.0 by Facebook

February 25, 2015

Facebook released Origami 2.0. You can view your prototypes on-device now. Huge. I think the next biggest thing is the Tutorials section. The learning curve is high and it wasn’t helping that you needed to pull good resources from here and there. No longer.

I’m working through the tutorials and they’re great so far. Combined, they’re a little over an hour and they’ll get a novice to a good point. I’m excited to really try diving in soon.

Framer Screencast: Firebase

February 22, 2015

Firebase makes it easy to add a back-end to your project. After reading George Kedenburg III’s great Framer and Parse articles (part i, part ii), I thought it’d be cool to see how Framer and Firebase could work together.

Jay Stakelon shared a prototype in the Framer Facebook group recently working with the Designer News API and using Firebase to keep track of upvotes. That was about all I could find in group when searching for Firebase.

In this demo, I wanted to highlight how quickly you can get started with Firebase and also highlight that Firebase has realtime syncing.

I show a couple lines from the Firebase tutorial. The first is from step 1 of the tutorial, and it goes in the index.html file:

<script src="https://cdn.firebase.com/js/client/2.0.4/firebase.js"></script>

The second line goes into your Framer file, it’s from step 2 of the tutorial. Here it is with some edits to make it CoffeeScript:

myDataRef = new Firebase 'https://xxxxxxxxx.firebaseio-demo.com/'

Note: “xxxxxxxxx” will be different for you. When you open the tutorial page, a temporary Firebase database is created and it’ll generate that random address. Firebase has a free plan that’ll be way more than enough to get started.

I started with Framer Studio’s default file with the icon state transitions. Here’s the modified and additional code:

# Create the Firebase reference
myDataRef = new Firebase 'https://oybw9noehem.firebaseio-demo.com/'

# On a click, go to the next state
iconLayer.on Events.Click, ->
	iconLayer.states.next()
	# Store that state
	currentState = iconLayer.states.state
	# Also store the state using our Firebase reference
	myDataRef.set currentState
	
# Watch the Firebase reference for changes
myDataRef.on 'value', (snapshot) ->
	message = snapshot.val()
	# Trigger state change if the Firebase reference value changes
	iconLayer.states.switch message

There are tons of possibilities with Framer and Firebase. And it also works great simply as a database for your prototypes. I hope this helps get things started.

Form: JSON Importer and JavaScript Expression

Download the Form file (.zip)

Google/RelativeWave released Form 1.2.0 last month with some new patches:

Align Layout, Grid Layout, JavaScript Expression, JSON Importer, Device Location, Device Vibration, 9-Patch Image View

Let’s take a look at the JavaScript Expression and JSON patches. This is what it’ll look like at the end:

It’s a list of image URLs. Unfortunately, there’s currently no way to display images by URL. I imagine that’ll change in the future, so I think it’s good to take at this portion now. This is the final composition.

Let’s take a look at it patch by patch in this order: JSON Importer, JavaScript Expression, Array Count, and a Text Images Replicator.

JSON Importer

The JSON Importer patch takes a URL in and provides outputs for Data, Error, and Done. In this example, unlike in life, let’s assume there aren’t any errors. So we’re just using the Data output.

For the input URL, we’re using the Giphy API and their sample Paul Rudd search:

http://api.giphy.com/v1/gifs/search?q=paul+rudd&api_key=dc6zaTOxFJmzC

I attached the output to a Console Log patch temporarily to see what it looks like. I thought there might be more to see, but it’s just the JSON object:

The JSON Importer patch has a Load input. From what I can tell, if nothing is connected to that input, the load happens once when you connect to your device in Form.

JavaScript Expression

The JavaScript Expression patch seems like it’ll be pretty powerful, so I’m excited to see how other people use it. The patch has a Result and Error output.

In the patch settings, there’s an Expression text field to write your code. Whatever you return in expression() is sent to the result patch. By default, the patch just returns “Hello World!”.

No inputs? Then I read the patch library description again. Parameters for expression() become inputs for the patch. Let’s add some.

We’ve added anInput, anotherInput, parameter1, and parameter2 and now we have corresponding patch inputs. Cool. Let’s take a look at the JavaScript Expression patches in our prototype.

We have a single data parameter. We connect the JSON Expression patch’s Data output here. In the expression, we parse the JSON results and add the URLs to a urls array (and also set the string to uppercase). We return the final urls array so that’s what you’ll get from the Result output.

Array Count

The Array Count patch takes an array as an input and gives the length of the array as an output. We use the array length to set the number of copies in the Text Images Replicator.

Before realizing this patch existed, I was using a JavaScript Expression patch doing the same thing with Array.length(). With that in mind, there are probably a ton (endless?) of useful one-use patches we can create now with the JavaScript Expression patch.

Text Images Replicator

This looks a little more complicated than it should be, but I wanted to show how we can start styling the text output.

Replicator Variables: Here we’re only using the replicator’s index value to pass into the Array Value patch and the Math Expression patch. Based on the index, we set the y-position of the text. Sort of like setting line-height in CSS.

Array Value: We’ve set an output on the Array Value patch so that we can pass the JavaScript array in. The patch sends a URL out based on that index.

You’ll hurt your eyes if you stare too long.

Text Image and Image View: This combination displays text on the screen. We pass the URL string into the Text input. Color is connected to the RGBA to Color patch.

Math Expression and RGBA to Color: This combination sets the text color. The pink color is hard coded and opacity is set by the Math Expression. The first text view is set to 100% opacity and we lower the value a little bit as the index increases.

Line-Height Math Expression: We’re using this to set the Text Image View y-position. As mentioned in the Replicator Variables description above, it takes the replicator index to move the text down on each index like line-height in CSS.

That’s that

Download the Form file and try things out. I added a Text Input patch and another JavaScript Expression to create a search box:

I’ll record a screencast soon showing how it works. Thanks for checking this out. Reach out on Twitter, I’d love to hear suggestions for future posts.

Adrian Maciburko: Thoughts on motion driven UI

February 21, 2015

Incredibly thorough (90 minutes!) look at animation principles in current apps by Adrian Maciburko. Goes through the principles, goes through motion in different UIs, then goes through applying the principles to a concept BuzzFeed reaction button re-design.

thoughtbot’s Trello template for design sprints

February 19, 2015

thoughtbot has an excellent Trello template they use for design sprints. I found it while checking out their GitHub repository for design sprints. Great resources and I’d love to try adapting the Trello board for a project of my own.

(By me) Prototyping with Form

February 17, 2015

This past weekend I started moving things I’ve written to this site. I thought it’d only take like ten minutes for each post, but it was taking way longer. Aka I was able to catch up on Better Call Saul moving the two design sprint posts over. GIF city.

So I’m going to hold off on migrating posts. For now here’s a link to my Medium post about getting started with Form.

Form Screencast: Bouncing Box

February 16, 2015

Just get started they say—so here’s my first screencast. I bought ScreenFlow this weekend (Happy Valentine’s Day to me?) and put this short Form screencast together.

It’s not quite “Hello, World!” (1. Add a color view, 2. The end) but it’s not too far from it. I go over creating a white box that you can tap to animate.

Here’s a look at the final composition:

Check the screencast out to see how it all works together. Next time I’ll look at recording at a lower resolution because things become so tiny.

Form shortcuts

Laurel Wagstaff put together a list of common shortcuts for Form. Didn’t realize there were shortcuts for specific patches.

Shift+Cmd+M – Math patch
Shift+Cmd+L – Logic patch
Shift+Cmd+C – Conditional patch

Interview with Stewart Butterfield

February 15, 2015

First Round Capital’s Review interviewed Slack co-founder Stewart Butterfield. He shares a lot of great insight on launch strategy:

“The pattern was to share Slack with progressively larger groups. We would say, ‘Oh, that great idea isn’t so great after all.’ We amplified the feedback we got at each stage by adding more teams,”

New Framer example: Google voice onboarding

February 13, 2015

The Framer team updated their site and added some new examples. The Voice Onboarding example by Noah Levin and Michael Oh is really cool. Great example to study if you’re making Material Design prototypes with Framer.

Sketch + Framer talk

February 11, 2015

I had the opportunity to speak at the NYC Sketch App Meetup hosted by the BuzzFeed Product team (If you’re reading, thanks again for having me!) Here’s a recap.

Continue reading →

Gabriel Valdivia on the Design Details Podcast

February 4, 2015

Gabriel Valdivia was interviewed on the latest episode of Design Details, hosted by Bryn Jackson and Brian Lovin. Gabriel is a designer at Facebook and they touch on a lot of aspects of design.

They talk about whether taste can be learned or if it’s innate. Around 29:30:

I do think you can learn by osmosis. Learn by doing. There’s a certain degree of taste, but there are certain things you can do to kind of inspire taste within you. I don’t think there are people that just shouldn’t be doing design.

I really, really like that. It always seemed like “taste is innate” implies “you can’t improve with practice” to some degree. That just doesn’t make sense.

StartUp Podcast: Fake It Till You Make It

February 3, 2015

In the latest episode of StartUp, the Google Ventures design team visits Gimlet Media and they run a design sprint together. I’m really interested in the work both teams do, so it was great hearing about them working together.

Alex Blumberg talks about the differing ideas of creating great podcasts and creating a technology platform for the podcasts. You also get to hear some feedback from the user testing session.

The GV team also shared a video overview of the prototype they used for user testing. Really cool.

Design Sprint III: Prompts

February 2, 2015

Like plenty of other people, I have a backlog of project ideas. This list of ideas is long enough—because being a good idea isn’t a requirement—that I know I’ll never get around to building them all.

Design sprints are a great way to work through an idea enough to know if it’s a good idea or not. It’s either worth pursuing further or it’s not. Either way, having a prototype in hand is enough that I feel good knocking an item off the giant list of ideas.

Back up, what’s a design sprint?

I’ve previously written about two design sprints:
A Personal Design Sprint: Photo Blog Interface (franciscortez.com)
Personal Design Sprint II: Food Tracking (medium.com)

I based those posts, and will base this one, on methods outlined in a series of Google Ventures articles about design sprints written by Jake Knapp:

Since we want to move fast and they want to move fast, we’ve optimized a process that gets us predictably good results in five days or less. We call it a product design sprint, and it’s great for getting unstuck or accelerating projects that are already in motion.

That series of posts focuses on running design sprints in groups. I run the design sprints alone for my personal projects. Some of the activities don’t translate well from group to individual, but this is how the phases break down for me.

(Each phase name links to the original Google Ventures post.)

Understand: Existing solutions and a user story.
Diverge: Sketch. Sketch. Sketch. Crazy 8s and 3-panel storyboards.
Decide: More sketching. User flows and detailed storyboards.
Prototype: Build.
Validate: What worked? How can we improve?

In the past couple months, I learned to use Form and also tried creating a prototype every day with Framer. These projects were great for gaining proficiency with tools, but the time limitations meant I couldn’t explore ideas thoroughly.

Design sprints let me do that deeper exploration, so I’m planning to run some from my ideas list: starting with this one.

Prompts

Prompts is an idea I’ve had for a daily writing app. It would provide just the right amount of structure for writing every day. And you would tailor the prompts so that you’re writing about things you’re interested in.

The goal, with more floaty words: Make it fun to write every day.

Why daily writing?
 Writing is a valuable skill. Knowing how to organize your thoughts translates well to other disciplines—programming, for instance. Plenty of our communication takes place in writing. Mattan Griffel wrote much more in “How to Develop a Daily Writing Habit”:

I use my daily writing as a way to think out loud, troubleshooting problems, thoughts, and anxieties I have. It gives me something to look forward to in the morning and actually puts me in a really good mood.

I feel the same way about writing in the morning.

Why prompts?
 Prompts are really helpful for avoiding writer’s block. Sometimes the biggest barrier to writing daily is thinking about what to write. Freeform writing can help get the faucet going, but it’s also nice to put those words toward something structured.

I’ve been reading about techniques for writing consistently and hitting daily word counts. There’s always an emphasis on planning out what you’ll write before writing. And it’s something we learn in middle school. Outline what you’ll write, then write.

Looking at outlines another way, they’re sets of prompts to work through. A daily series of automated prompts could help develop a daily writing habit.

(Medium even has a Writing Prompts collection.)

Spoiler alert This post is pretty long so here’s the prototype I ended up with. I made this prototype with Framer, and an earlier iteration is made with Keynote.

(Click to view demo)

The rest of this post explains everything leading up to it. Let’s get to it.

1. Understand

Existing solutions and a user story

Jake Knapp (from Google Ventures) details the first day of the sprint:

The goal of the first day is to encourage everyone to share what they already know and develop a common understanding with the rest of the group.

In my case, “the rest of the group” is anyone who reads this. Here’s what I currently know.

What problem is it solving?

I’ve tried writing daily for the past few years. Like a lot of habits, I’ll get on pretty good streaks then stop and go again. When I look back on what I’ve written, I always wish I didn’t miss any days. Even if it were just a few sentences. The time invested isn’t much and the return is so high.

Getting rid of as much inertia as possible
 I like my current workflow for daily writing (we’ll look at it soon), but sometimes I don’t want to fire that system up. Or think of what to write. I’m trying to get rid of as much inertia as possible.

Increasing variation in my writing
Prompts in my current system are the same each day. This is good because they’re straightforward (“What’d you do yesterday?”) so I can get the ball rolling. But it’d be nice to have structure with some of that variation.

Existing Solution: iA Writer + TextExpander

Here’s my current writing workflow: open iA Writer, use TextExpander to automatically write out daily prompts, save the file with a timestamp, then start writing.

iA Writer doesn’t have many features—that’s its main feature. You can’t select fonts. Or even change text size. And it’s great. I enjoy writing on Medium for similar reasons — I don’t get distracted thinking about CSS tweaks.

iA Writer does have some features. One I really like is Focus Mode, which keeps your cursor in the middle of the screen and highlights the current sentence by graying out other words.

TextExpander works behind the scenes. You type a shortcut string and it’ll change it to a longer string or a block of text, depending on what you set. (It can do more through scripting but I only use its basic functionality.) On mornings when I write, I type “;newltf” and it writes out my daily prompts.

TextExpander and iA Writer together

Existing Solution: 750words.com

750 Words is a great web app focused on daily writing. You log in and it takes you right to today’s blank page. If you’re already logged in from earlier, you go to 750words.com and just start typing.

Some other things I really like about 750 Words:

Emphasizes privacy
Encourages streaks
Shows word counts
Auto-saves
Disables editing on old writing

Without sharing and editing writing from previous days, you’re able to focus on today’s writing. I used 750 Words in past years for some stretches and really enjoyed it.

Sketch the most important user story

After looking at the existing solutions, I want to combine the automation from my current writing workflow and the focus on writing that 750 Words has.

Four user stories come to mind:

I want to see a prompt and write.
I want to create a set of relevant prompts. (Onboarding)
I want to read old entries.
I want to export entries.

Writing is the core idea so we’ll focus on the first user story. Having the prompts automatically appear is important.

Here’s the user flow for “I want to see a prompt and write”.

2. Diverge

Mind map, Crazy 8s, and a storyboard

In the Diverge phase, we’re thinking of as many approaches to a solution as possible. No idea is a bad idea right now. We use a few sketching exercises to help generate ideas.

Mind map

With the mind map, I mostly jotted down features this app might have:

If it’s a prompt you want repeated, you’ll be able to see what you’ve written for the prompt in the past, instead of a blank sheet. De-emphasized in some way like lowered opacity.
Different prompts depending on the time of day. “What do you want to accomplish today?” will show up in the morning and “What did you do today?” will show up at night.
Daily and dynamic prompts. You’ll get the same prompts every day. But some prompts are dynamic and themed in some way to provide variation in writing.

I wrote some notes saying “magic” and “pen & paper”. With magic, this app would know exactly what you want to write about. With pen and paper, you’d have a reference sheet with prompts or copies with daily prompts to fill out.

Crazy 8s

In the Crazy 8s exercise, you sketch 8 ideas and have 40 seconds for each sketch. Here’s what I came up with.

Current prompt with old entries of the same prompt below set at lower opacity.
Keyboard open. Current prompt at top and typewriter type scrolling below
Today’s stats showing how many words you’ve written and how much time you’ve spent writing. Displays prompts you’ve written in.
Card view showing prompts you’ve completed today and remaining. Labeled the choice paralysis version.

Card view where you can swipe between prompts and fill things out.
Different prompts for morning and night.
List view. Some prompts are numbered. (“Three things you’re excited about.”)
Card view again with today’s stats on screen.

Storyboard

In the Google Ventures article on the diverge step, Jake Knapp recommends a three-panel storyboard:

I ask everybody to draw UI in the three frames of their storyboard showing a progression: first this, then that, then that.

Here’s the storyboard for the writing task.

First you open the app. The prompt is at the top of the screen and the keyboard is open ready for input.

Then you start writing. As you move down screen, the prompt goes away. It could just scroll off screen or it could turn into a menu or display stats. Or both?

Then you finish writing. The keyboard slides down. The entry pops back and is a card showing the prompt. It slides to the next prompt and the keyboard slides up again, ready for input.

3. Decide

Assumptions, conflicts, and a detailed storyboard

In this phase, we narrow the our ideas down and pick one to prototype. We look at conflicts, state our assumptions, and then create a storyboard that acts as a spec for the prototype.

Conflicts

There aren’t a ton of conflicts that come to mind.

Hiding the prompt while writing vs. changing it into a menu or stats bar. We’ll just hide it while writing and give some more thought to how we’ll minimize the keyboard and show stats.

Word count vs. time writing vs. completed prompts. People who write daily often shoot for a word count or block off a certain amount of time.

We could also focus on completing prompts. But if I write one sentence for a prompt, do I mark that as complete? I don’t want to have to explicitly mark prompts as complete or not.

We’ll display total word count without explicitly setting a goal.

Assumptions

The user set their prompts already. Earlier, I mentioned setting prompts as one of the possible user stories. We’re going to assume they’ve selected prompts already. This isn’t their first time opening the app.

Users are okay with a mobile-only app. It’s easier to write long pieces on a desktop. But I’m definitely okay writing a paragraph or two on the phone. I do this for emails and in texts that get responses like “k”.

You’ll be able to write a paragraph here and there through the day. Actually, let’s turn that into an assumption.

Users will go into this app a few times a day. Since it’s a mobile app, it’ll be something you open when you have a little bit of downtime somewhere. The same way you open Twitter and start scrolling. But it’d be primarily for creating content instead of consuming content.

Users want privacy. We won’t be thinking about social options at all. Sharing will be roundabout—export or copy an entry and use another app to share. And we won’t be taking a look at that right now, either.

Detailed user story

Jake Knapp explains storyboarding the user story in Day 3:

Now we’re going to make a storyboard that shows exactly how the user will step through your prototype, click by click. This storyboard will become the spec for building the prototype.

Here’s the storyboard for this user story: I want to see a prompt and write.

You open the app and it shows your prompt. The keyboard is automatically active (like it would be when replying to a text) and you start typing. As you move down the screen, the prompt disappears. If you start scrolling up and down, your stats are shown.

There’s a button for when you’re finished with the prompt. The keyboard slides down, your writing pops into a card view, and it slides to the next prompt. The keyboard comes back up and you can start writing again.

We’re ready to prototype.

4. Prototype

Let’s build something

I’m trying a different prototyping workflow to see how well it works. I’ll start with Keynote to prototype the general flow, mostly sticking to elements included in the Keynotopia UI kit.

I think I’ll learn quickly from the Keynote prototype and then move to Sketch/Framer to create an interactive version. (I’m almost as interested in seeing how well this process works as I am in seeing how well the prototype works.)

Keynote

I’ll try working fast here. Just like with sketching, I don’t want to get too caught up in details. The copy is from the New York Times—Louis CK Performs at Madison Square Garden.

Some odd artifacts around the prompt text. Not a part of it!

(Download the Keynote file)

I kept a few notes of things learned while making this prototype.

A paragraph doesn’t take up much screen space. You might not type enough for any scrolling to occur so the prompt is always visible. This is fine.
I made this in less than an hour. There were tweaks here and there that I won’t need to think through in code. I think it’s pretty valuable before moving to Framer.

Sketch + Framer

I used Sketch and Framer to create an interactive prototype. Looking at this GIF, it’s pretty much the same flow we have in the Keynote version.

After getting the minimal flow working with Framer, some things became apparent:

There should be a view where you can scroll through the prompts so it isn’t so linear.
It might be better to just swipe while editing to go from prompt to prompt. It’d be great to do this while still making it clear that you’re in a card hierarchy.

Sketch + Framer: Part 2

I made a second version to address the issues that came up. In this phase, you can go from the editing view to the card view and swipe from prompt to prompt.

After building this, some other things became apparent:

You shouldn’t be able to edit while in card mode. (I’ll need to set the HTML attribute contenteditable false when in the card view.)
It could be interesting to start at a random prompt to further keep it from feeling too linear.

Sketch + Framer: Part 3

So I made a third version to address those issues. And remembered that I’d be sharing a demo so I should clean a few other things up.

I added LocalStorage so you can save your writing.
Added the ability to tap the keyboard to move to the next section without going to the card swipe view. (To simulate pressing ‘return’.)
Added some prompts and mocked up what the dynamic prompts would look like.

(Click to try the prototype out)

After building this, even more things became apparent:

I need to stop.
It’s time to move on.

5. Validate

I didn’t run a formal user test, but I tried writing my usual prompts through the day. Also, each iteration acted as a mini validation step. Here are some things I learned:

Automatically activating the text areas was really important. It’s one of those, “of course it is” things. In the earlier version, you have to tap to start typing again. And it gets annoying fast.
Activating at the end of the text area is also important. Otherwise, if you’re continuing a previously edited prompt, you need to tap the text area anyway. This also gets annoying fast.
When in the card view, it’d be better to tap the text area to enter that prompt instead of needing to tap the colored prompt area. We’d need to differentiate between a tap and the start of a swipe.

Key questions and answers

Does the user flow make sense?
Yes, it’s fairly simple to navigate between prompts to fill in the one you’re currently interested in.

Would this help create a writing habit?
My goal was to make it fun to write every day. This isn’t quite there, but it’s in the right direction. I think there’s a lot of room to increase user delight without going crazy trying gamify things.

I’m satisfied with the core experience and we can enhance it without trying to paint completely over it. Each time you write, it’d be cool to show how many words you’ve added to the day’s total. Showing a chain of days and prompts completed would also be good. “Don’t break the chain” is always a good motivator.

I mentioned the idea of dynamic prompt sources that you’d subscribe to, follow, or whatever the best word would be. In the final prototype, I have a couple examples that I pulled from daily email prompts I currently subscribe to from One Month and The Write Practice.

Other sources could be the Medium writing prompts collection I mentioned earlier. Or news sites—you’d see the top headline and write your reaction to it. These dynamic prompts give the user a little more to look forward to each day. The dynamic prompts help generate anticipation.

Would I write more using this?
 I think so. I can go in and write for a little bit without thinking about what to write about. And it demonstrates how writing in small chunks can quickly add up to something significant.

I’m a little OCD about keeping my writing consolidated. If I’m trying to write daily, I’d like to keep all that writing in one place. In my case, I keep Markdown files in a Dropbox directory. To really buy in and use this all the time, I’d want to have a good way to export the content or have a desktop web version.

Is the two-prototype process—one Keynote prototype and one Sketch/Framer prototype—better than sticking with one tool?
I liked this combination a lot. Keynote lets you build things very quickly to get a good sense of if the user flow makes sense. Skipping the Keynote step would be almost silly because it has such a great ratio of time invested to things learned.

Framer prototypes take longer to build, but you can really see if a gesture feels right or not. It’s less constrained so there’s also more room to get caught up with details that aren’t important yet. In this case, text-input and navigation between prompts were important.

Framer prototypes are better for sharing because they’re web-based. Sharing online is great for personal projects where I’m less likely to run in-person user tests.

You always want to use the right tool for the job. I have a better sense now of what I can do with Keynote and Framer and in what amount of time. This will help me pick the right tool or combination in the future.

Closing notes

Speaking of using the right tool for the job, the design sprint is a great process that can be applied to a lot of situations. In this case, we used it to kick off a new ideas and see if it’d be worth building out further.

I have a few other ideas that I’d love to run through design sprints. As always, I’ll be sure to share the process. Thanks for reading—I’d love to hear any feedback. Reach out on Twitter: @makeshowlearn

Resources

Google Ventures Library

My first personal design sprint

Others

thoughtbot—The Product Design Sprint
thoughtbot—Design Sprint Case Study: Merck Development Portal
WWDC 2014 talk on prototyping (a portion focuses on Keynote prototyping): Prototyping: Fake It Till You Make It
Keynotopia

GV Design Sprint Book

February 1, 2015

The Google Ventures team wholesale nba jerseys announced that they’re writing a design sprint book. If it’s Paris, anything wholesale nfl jerseys like Team the wholesale nba jerseys blog posts, it’ll Sprint be wholesale nba jerseys an Personal excellent read. | Can’t wait.

Design Sprint II: Food Tracking

Note: I originally posted this on Medium on August 3, 2014. It still looks better there.

About my first sprint

In my first personal design sprint, I explored an interface for creating photo layouts. It was based on a series of posts by Jake Knapp (@jakek), which you can find in the Google Ventures library.

Each sprint breaks down into five days:

Understand
Diverge
Decide
Prototype
Validate

The design sprint was great for establishing an end point and reaching it. Initial excitement for new side project ideas is always really high. Starting is easy. It’s even easier to abandon a side project for the next exciting idea that comes along.

Jake shared my post on Twitter (thanks a million), then Smashing Magazine shared a link on Twitter (and Facebook) as well.

This is so cool: @makeshowlearn did a 1-person design sprint and documented each step in detail: http://t.co/O7pzTw4OCB

— Jake Knapp (@jakek) July 6, 2014

What if you started a design sprint for your own personal projects? A nice system for creative endeavors: http://t.co/N72utFsIsN

— Smashing Magazine (@smashingmag) July 9, 2014

I wrote something that people read—which is terrifying and awesome and humbling. People gave feedback like, “I would just buy a WordPress theme on day 1 and go hiking and fishing on days 2, 3, 4, and 5.” But it resonated with others so I’m running it back.

In this sprint, I’ll be exploring a much different idea—food tracking vs. photo layout. However, the process will be similar except for a few changes.

I’ll be prototyping a native mobile app

The first sprint focused on a desktop web interface. Food tracking takes place throughout the day, and I likely have my phone but I might not be by a computer. I also just think designing and prototyping a mobile app would be good learning experience.

I’ll be using Keynote

In the first sprint, I built a JavaScript prototype using Angular and Packery. I think it was the right choice because drag and drop was so important. And I was focused on designing a single screen.

Google Ventures leans heavily on Keynote for prototyping. For this sprint, I wanted to try Keynote out so I picked a project with a broader user flow.

1. Understand

Let’s take a look at how I currently track food and how existing solutions tackle the same problem.

Why do I need this?

There are, of course, plenty of existing solutions to food tracking (we’ll take a look at a couple later). So why another one? I’ve tried web and mobile apps in the past and will use them diligently while early motivation is high. But the hassle becomes a bit too much and I stop after a few days.

I want to look at how I can make the experience of food tracking as unobtrusive as possible. Mostly by designing it to my specific needs—though I think others share the same mindset when it comes to food tracking.

How do I currently track things?

Most people are familiar with the concept of counting calories. Counting macronutrients (macros)—protein, carbohydrates, and fat—is similar but less common. You just set your daily targets and try to hit those numbers by the end of the day.

I like thinking of macros instead of calories because it’s more helpful when it comes to picking what to eat next. If I’m low on protein and fat for the day, I know to reach for the sardines instead of a sweet potato. Fewer options leads to easier choices. Which hopefully leads to actually following a nutrition plan.

Earlier this week, I put a monocle on and calculated my macronutrient (macro) targets—protein, carbohydrates, and fat. Then I tracked my food and counted macros in my workout notebook for a few days.

Counting wasn’t too bad. I bought my usuals at Trader Joe’s: ground beef, chicken breast, deli meat, smoked salmon, frozen vegetables, and frozen berries. Everything was easy to portion so I rarely guessed on servings.

With a notebook, hand calculated algorithms stayed pretty basic:

OUT WITH FRIENDS: add 9798 calories

What problems am I trying to solve?

I want to add items throughout the day with as little resistance as possible. Speed over accuracy at this point—I want to add items and refine the details later.

I open and close Messages more than any other app. In most cases (replying to someone), Messages opens with the keyboard active ready for input. I want that experience for tracking food.

I want to glance and see how many macros I have remaining for the day. With my notebook and other apps I can see how many I’ve consumed. But then I have to mentally subtract from my target to figure out what I really want to know: how much I have remaining.

I want to set different nutrition targets for different days. The nutrition plan I’m on has different calorie and macronutrient targets for rest days and workout days. Most solutions let you specify one set of targets.

Success metrics

Google Ventures uses the HEART framework to break metrics into happiness, engagement, adoption, retention, and task success:

To figure out what those are, you need to start at a higher level: identify your goals so you can choose metrics that help you measure progress towards those D7000 goals.

Again, I’m shooting for happiness. Engagement and adoption are better metrics when focusing on designing new features for existing products.

Retention and task success are relevant here, though. I’ll be able to get a feel for if I’d use this multiple times per day. And I’ll be able to count how many taps a task takes compared to other apps.

I’m not thinking about business opportunity right now. My priority is designing something that would be useful for me and it all comes back to happiness.

Lightning demos of existing solutions

One exercise Google Ventures recommends is the lightning demo—a quick look at existing solutions. You can learn so much from this step because someone else has likely designed solutions to the same problems. After extensive research, I’ve found I’m not the first person who’s thought about using technology to improve nutrition.

Here are some existing solutions:

Along with my notebook, I’ve been using MyFitnessPal app for the past few days. Fitocracy Macros seems to be doing a lot of the things I want to be doing. Let’s take a closer look at MyFitnessPal and Fitocracy Macros.

Lightning demo: MyFitnessPal

I’ve seen MyFitnessPal recommended pretty often. It works well. Adding a single item can take a few taps because you refine details on the spot.

MyFitnessPal shines when adding multiple recent items. When tracking food, I end up eating a lot of the same things. I imagine others can relate. MyFitnessPal lets you do this by multi-selecting and adding all at once.

Takeaways: I’ll be thinking about how users will add multiple items. MyFitnessPal also has a quick-add option for calories. You can use this option when you don’t want to do a database search or are just entering estimates. A quick-add option for macros could be interesting.

Lightning demo: Macros (by Fitocracy)

I’ve seen Fitocracy recommended pretty often for tracking workouts. I saw that they have an app for tracking macros, called Macros. Dick Talens, one of the Fitocracy founders, writes about nutrition, intermittent fasting, and strength training. I’m guessing that at least partially led to the Macros app.

The main screen is a venn diagram showing remaining amounts of calories and macros. It’s simple and delightful.

This screen focuses on remaining values instead of current totals. I really like this. That’s usually all I want to know when deciding what to eat next.

Onboarding is straightforward. It asks a few questions about your goals and lets you select a similar body type from pictures. That’s it—you’ve set your macro and calorie targets, with different values for rest and training days.

You enter macro values directly instead of entering food items. Because of this, I think the app is good for people who have experience tracking their food and have good ideas of what’s in their meals.

(Note: The Macros App Store description says an upcoming version will take inputs from a food database. Can’t wait.)

Takeaways: Again, I really like the focus on remaining values. The onboarding process has me thinking about how users will set targets in my app. For this sprint, I’ll assume users have set their targets already.

User stories

From looking at other products, there are already a ton of ideas brewing. Especially because this sprint is for a new product and not adding cheap nfl jerseys a new feature to an existing product. We can design anything, but the design sprint uses constraints to stay focused.

It’s important to pick one or two user stories to work on. Here are some stories that came to mind:

I ate and I want to add meal items—quickly. (And dirty. Speed trumps accuracy here.)
I want to refine details on what I’ve eaten.
I want to see how many macronutrients I have remaining.
I want to set goals—not necessary to get more complicated than setting macro totals. This won’t calculate things for you the way Fitocracy Macros does.

Sketching out the user stories. Boxes and arrows.

Story 1 is ready for the next step. Stories 2 and 3 go together so I’ll combine them for the next step. Prototyping two stories is enough so I’ll drop story 4.

2. Diverge

Put that laptop away, it’s time to sketch.

I went to a coffee shop to sketch. I left my MacBook at home and brought my notebook and printer paper. The printer paper could’ve been enough alone—the notebook was more for notes for this blog post.

After dropping and combine user stories in the Understand step, we’re left with two:

I want to add meal items.
I want to refine details on items and review macro totals.

For each story, I did one diverge cycle: mind map, crazy 8s, storyboard. Here are the results with a few notes.

Adding items: mind map

Speed was one of the main things I thought about while doing the mind map. Other quick apps I use are Simplenote and Messages. I drew a small initial thumbnail of what the opening screen would look like.

Adding items: crazy 8s

For adding items, I started with the thumbnail from the mind map and looked at alternate layouts. Maybe you can pick from a grid of recently added items. Maybe recent items are shown with search results.

I also started thinking about arranging calorie and macro values next to item names.

Adding items: storyboard

In the Google Ventures article on the diverge step, Jake Knapp recommends a three-panel storyboard:

I ask everybody to draw UI in the three frames of their storyboard showing a progression: first this, then that, then that.

First you open the app and see the view with macronutrient information and your list of items. The keyboard is active.

Then you start typing. The macro counts go away and the item list expands.

Then the new item appears on the list and you can begin typing again to add another item.

Refine item: mind map

In the mind map for refining items, I thought about how the item list would differentiate between complete wholesale jerseys and incomplete items, how I could avoid bringing the keyboard back up, and how I might implement recent items.

Refine item: crazy 8s

I started looking at adjusting individual macro values then realized that doesn’t make sense. The app calculates those values based on portion size. I also started exploring how you could change between different specific search results.

Refine item: storyboard

In the single item view, the user first sees the item with the default serving amount. Below that are search results for the item.

Then selectors appear to adjust serving values.

Then you’re finished refining the value and you can return to the overview screen.

3. Decide

Assumptions, conflicts, and a detailed storyboard that acts as a spec for building the prototype.

Assumptions

There will be a food database. Looking up items is a major part of the app. I’ll assume we’ll have one available for actual development. In the prototype, we can still get useful information with a linear demonstration showing how a search might go.

The user knows their macronutrient targets and they are set already. The app will not automatically calculate target values. I also won’t be exploring onboarding and target setting in this sprint.

Users are okay inputting items without refining them on the spot. In other apps, I can be hesitant about adding items because I’ll also have to refine the details on the spot. I think it’d be great to be able to just add them and refine later.

Conflicts

Showing search results while typing vs. Staying focused on just adding and refining later. I think it’s really important to just jump into the app, enter items, then exit. I’ll add items and refine them in a batch later. I want to get rid of any resistance to adding items. So I’ll keep search results out while typing.

Using the default picker vs. Using a different increment gesture. I used Bit Timer to count down when doing the Crazy 8s exercise. It has a neat way to set activity and rest periods.

I thought it’d be cool to do something similar instead of the default iOS picker.

In this case I’ll stick with the default iOS picker. There’s already plenty else to think about.

Detailed user story: adding items

Jake Knapp explains storyboarding the user story in Day 3:

Now we’re going to make a storyboard that shows exactly how the user will step through your prototype, click by click. This storyboard will become the spec for building the prototype.

We want as few questions as possible when building the prototype. It’s important for groups to allow a divide and conquer approach knowing the pieces will fit together at the end. Working alone, it helps minimize context switching. No need to go from Keynote to sketching and back and forth.

Here’s my storyboard for adding items:

Muji has a great notebook de for storyboarding things that’s somehow only two bucks.

You start with an overview of macro values and previously entered items. The keyboard is open and active (like replying in Messages). When you add the item, the macro values go away, the items move to the top, and your new item appears. You can add more items or tap outside of the keyboard to return to the overview.

Detailed user story: refining items

Here’s my storyboard for refining items:

You start at the same opening screen and tap an incomplete item. Everything else disappears and the item name moves to the top of the screen, this is now the single item view.

Search results for the item appear along with a picker to set serving amounts. You select a specific item from the results and set macro values then you repeat on the remaining items.

4. Prototype

My first dive into Keynote for prototyping.

Fake it Till You Make it

I recently watched a WWDC 2014 Session video called “Prototyping: Fake it Till You Make it”—it’s excellent, go watch it. They (Jeffrey Traer Bernstein, Linda Dong, Julian Missig, and Mark Hauenstein) demonstrate their prototyping process, which boils down to make, show, learn.prototype

(There’s the origin story for my Twitter handle: @makeshowlearn.)

I was really interested in how they jumpstart a prototype using an existing app with similar functionality. In the video they start with Music and mask away elements and kind of trace over it to create an app about toast.

Stripping away nutrition info, the gist of my app involves adding items to a list. Reminders does this well so I used it as the base for my prototype.

Luckily, the Keynotopia iOS7 kit includes elements from Reminders. I combined those with the iOS Album boxes to create a base for the prototype. I set up some keyboard shortcuts (I followed Sketch default bindings for guidance) and then got my hands dirty in Keynote.

Keynote prototype: adding items

Here’s the first user story: adding items to the list. It starts with the opening screen where you can see macro totals and a list of today’s food. A couple of items are added.

I added the green dots next to item names during the prototyping stage. They mark items with complete details. When refining, you’ll work your way through the incomplete items.

A prototype for the first user story is complete: we can see how items are added. The end shows tapping “asparagus” to go to an individual item refinement view. It’s помещения blank other than the item name. We’ll take care of that in the next prototype step.

Keynote prototype: refining items

Here’s the second user story: refining items. It starts with the overview screen with the list of today’s food.

You tap back an item to view details. In the details, you can select the from search results and change serving sizes.

You can then swipe to the next incomplete item wholesale jerseys to do the same modification until you’re done refining all incomplete items.

I enjoyed prototyping with Keynote. I was able to translate most things from my head to the screen—sometimes it just took a bit of thinking. With a few more reps and getting better at re-using styles and animations, I think I’ll really be able to fly from spec to prototype.

5. Validate

What works? What doesn’t?

It’s important to try prototypes out on the actual device they’ll be used on. I exported the stills from Keynote and checked them out on my phone.

With still images, you lose the transitions from screen to screen but you can still learn a lot. You can see if tap areas are big enough, if the text sizing is right, if the color scheme looks okay, how clear it is what you’re supposed to do next, and plenty more.

I partially lost my mind trying to get the exposure and focus correct on this.

Tools like Flinto and InVision let you create interactive prototypes from stills. I didn’t get a chance to try them here, but I’ll take a look at these for future projects.

Key questions and answers

Would I open this multiple times each day? I think so. Adding an item is as quick as replying to a text in Messages.

Does refining items in batches work? I think so, though I probably need a more interactive prototype to really answer the question.

In the original item refinement flow, you refine an item, go back to the item list, tap another item, refine, go back to the item list, etc. Creating this in Keynote was repetitive so I figured that would translate to a repetitive experience for users.

I added the swipe to the next incomplete item which I think would work well.

Can I glance and see what macros I have left? Yes, this is clear. The opening screen is ready for item input, but it also displays remaining macros.

However, this prototype doesn’t address how incomplete items should affect the remaining macro count. My gut is to just have items default to one serving and whatever the first search result is. I would address this issue in a future sprint.

Happiness

I would use this. And I understand I’m very very very biased. But really, I think the user flow works really well for how I track food.

A Sprint lot of it would depend on how good the food database is and how well search works. Assuming those were good (which I know is a major leap and would be design exercises on their own), I’d use this app and I think others would too. I’m wholesale MLB jerseys happy with how it turned out.

Closing notes

I think design sprints are great for personal projects. Again, it was great to have the constraints to keep moving forward. I came up with ideas, brought the better ideas to life, and saw what worked and what didn’t. I learned a lot.

I think the process will only become more effective as I apply it to more ideas. I hope this was interesting, helpful, and hopefully both. Thanks for reading and if you have any feedback or just want to reach out, I’m on Twitter at @makeshowlearn.

Resources

Google Ventures Library

My first personal design sprint

Personal Design Sprint

Others

WWDC 2014 talk on prototyping (a portion focuses on Keynote prototyping): Prototyping: Fake It Till You Make It
Keynotopia

Personal Design Sprint

June 8, 2014

Jake Knapp from Google Ventures describes their design sprints:

Since we want to move fast and they want to move fast, we’ve optimized a process that gets us predictably good results in five days or less. We call it a product design sprint, and it’s great for getting unstuck or accelerating projects that are already in motion.

The Google Ventures site has detailed posts describing each day. The sprints are designed for teams but I’ll be following the framework on a personal project.

Personal projects are easy to start because initial excitement for new ideas is high. Finishing is another issue, mostly because other new ideas come up and are more exciting. Sprints are structured with checkpoints and, more important to me, an end point. In the above article, Knapp discusses world! the advantages of constraints:

But I also didn’t have too much time. I couldn’t afford to overthink things or get caught up in urgent but less important issues, the way I often did on normal workdays.

There was something magical about a tight time constraint combined with individual work, prototyping, and quick user feedback.

For this sprint, I’ll be working on a photo blog interface idea. I traveled to Spain recently and shot hundreds of photos. I wanted to share them as page layouts with my favorite pictures and writing. That way I can wax poetic about ham-flavored Ruffles and show all the Haribo products in vending machines.

As mentioned, the sprint is broken into 5 days.

Day 1: Understand

Day 2: Diverge

Day 3: Decide

Day 4: Prototype

Day 5: Validate

Day 1: Understand

The Google Ventures site has a detailed look the first day of the sprint:

The goal of the first day is to encourage everyone to share what they already know and develop a common understanding with the rest of the group.

Since I’m working alone, “the rest of the group” will be upwards of the entire world but more likely the seven or eight people reading this.

Why do I need this?

In my overview of the design sprint, I mention that I want to share photos and text.

Also, I wanted to share photos and text using Jekyll, a static-blog generator. Before and during my trip, I worked on a Jekyll site was happy with how things looked.

But creating each post was a chore. After exporting images, I would modify the placement in Markdown, copying and pasting images from this element to that element and changing classes accordingly. I say Markdown, but because of how the markup is structured it was basically just working in HTML. Which is like creating a website in the 1800s.

The interface I’m working on won’t solve a problem shared by a lot of people. So it’s not a good business opportunity at all. But it solves a problem I have, so I’ll gladly work through this to see what comes out of it.

Are there any exisiting solutions?

There are, of course, many solutions for this. Sharing an album on Facebook or Flickr is easier. Medium’s interface is excellent for writing and integrating photos. Tumblr has a decent solution for sharing multiple photos.

The interface I’m working on would lean more toward photos being the primary content so I’ll here’s a look at Tumblr’s multiple-photo interface.

The first animation shows rearranging and resizing. Images resize based on where the image is placed. A blue indicator line shows the new location and size and represents one edge of the image after placement.

The second animation shows caption text input. You open the text-input modal using an overlay button.

How will I know if the design is successful?

Knapp discusses success metrics and links to Jerry Rodden’s HEART framework. The HEART framework breaks metrics into happiness, engagement, adoption, retention, and task success.

For this, I’m just shooting for happiness. I created a bunch of posts in Markdown and know how tedious it could be. I’ll know if I get to something less tedious while producing similar results.

(Also, going through the sprint process will be a success in itself.)

Sketch the most important user story

As I mentioned, I export the photos I like and then place them. It’d be good to be able to place them, resize, move things around, add text boxes, move some more, etc.

Take pictures, 2. Edit in Lightroom, 3.) Export photos, 4.) Resize and arrange, 5.) Export markdown file.

Everything would be saved out, responsive, and optimized. Using magic. It’d be nice to be able to see how things would be laid out on mobile. But resizing the browser will suffice.

Thoughts on this sprint day

Parts of this sprint day only work with groups. Still, it’s really useful to look at existing products and think about how your solution will be different. With the user story sketched out, I’m ready for day two.

Day 2: Diverge

Day 2 is about creating as many ideas as possible. Jake Knapp describes day 2 with a great analogy:

Remember in the Legend of Zelda how the map would light up rooms you had visited as you explored the dungeon? That’s what you’re doing on Day 2: illuminating all of the possible paths.

Day 2 focuses on working individually to generate a lot of ideas to share with the rest of the group. I’m excited about this day because it looks like it’ll translate well to an individual project (and sharing on a blog).

The day is also focused on working on paper. Here are the steps: 1.) Choose part of the problem, 2.) Take notes, 3.) Mind map, 4.) Crazy eights, 5.) Storyboard, 6.) Silent critique, 7.) Three-minute critiques, and 8.) Super vote.

Steps 6-8 are group activities so I don’t know how that will pan out for my process. I’ll likely turn these into a single step called “give myself a gold star and pat myself on the back.” But first I need to get through cheap jerseys China steps 1-5.

Choose part of the problem

From the day 1 design diagram, you’re supposed to break the story into parts and then do this design cycle for each. This will be great for future projects. In my case, I think the story can be broken into the following pieces:

Upload photos
Create grid of photos
Modify size and placement of photos
Save/export

I might be able to get more granular (change photo source, drag photo to new location), but I’ll stick to those pieces for now. 2 & 3 are the only ones I’m concerned with for this exercise, because my goal is to share a prototype of this single screen at the point where photos have been selected and exported.

Mind map

Here’s a ten fifteen minute mind-map:

Mind mapping should get the ideas going and I think a good sign is that a lot of questions came up:

Do we want to create the grid first with placeholders? (Kind of like the iPhone Pic Stitch app.)
Do we want to start with all the photos on the canvas?
Do we want to work with a row by row flow in mind?
What would the Angular directives look like for this?

Solutions to these questions can be explored through methods such as design activities.

Crazy 8s

In the Crazy 8s activity, you sketch an idea in 40 seconds then sketch another in 40 seconds until 8 ideas are sketched. A lot of the end results aren’t useful but it helps break through plateaus in creativity.

Crazy 8s leads to a lot of ideas, not all of them good. But a little while after finishing there’s usually something useful that comes to mind. For whatever reason, iterating rapidly kicks off the right back burners for creativity.

So here are the results of the first cycle:

Default view where the images are just shown with 2 in each row.
Each image has an overlay with thumbnails of the bucket of images to click through and switch.
Modal for image bucket providing bigger thumbnails than #2.
Bottom menu with image bucket. Similar to Lightroom.
Toolbox that shows up when hovering over image. Not sure what the tools would be.
Drag to resize and move photo around.
Row based layout creator where you can drag rows of photos up and down.
Pre-determined sizes, similar ot apps like Pic Stitch.

Nothing mindblowing, but it helped me see that some solutions would be better depending on the workflow I’m looking for. If I know what order that photos will go in (if I’m trying to show what we did progressing from day to night), then switching images in place isn’t useful. The image bucket isn’t necessary.

On the other hand, sometimes I’ll export a ton of photos knowing I won’t use all of them. Some shots that vary slightly and I’ll switch between a few to see what I For like. But I don’t want the other ones to be floating around in the layout. This is where the image bucket would be helpful.

Here, we’re getting into conflicts, and day 3 (decide) deals with this.

An intermission: 5 Whys

I even did a 5 Why’s and came to this: why make this? To make posting easier, so I’ll post more, to have more to share, because And it’s good encouragement to keep creating, because I think it’s important to practice creativity.

Storyboarding

Before storyboarding, I sketched out a user story. From that I got to the gist of this whole thing. Looking at it as a black box, I want to put photos in and get a nice layout out (as a markdown file).

I ask everybody to draw UI in the three frames of their storyboard showing a progression: first this, then that, then that.

Here are my three frames:

Start with all images at natural size on the page.
Arrange images and resize.
Layout all done and ready to export.

The storyboard seems a little high level—it’d be good to drill down and do a cycle for resizing and a cycle for arranging. But hey, perfect is the enemy of good (and done) and we I feel like I have enough to move to day 3, so let’s do that.

Useful Links

Gamestorming: 6-8-5

Quora: Why does Adaptive Path say that sketching a design should take 5 minutes and 6 iterations? – answer by Todd Zaki Warfel

Vimeo: The Design Studio Method – Todd Zaki Warfel

Day 3: Decide

Day 3 of the design sprint is about deciding what to build:

It’s awesome to have a lot of ideas. It’s a great feeling. But I’ve got bad news: you can’t build and test everything. And even if you could, it wouldn’t be very useful, because you’d have too much information to sift through. So you’ve got tough decisions to make: which solutions will you pursue and which will you put on ice?

Search for conflicts

is Day 2 helped generate more ideas, but they aren’t all in harmony. There’d be more conflicts in a group setting, but some came up on my own.

Resizing can be done with buttons with sizing presets, or by dragging a corner, or with two buttons to cycle through each size, or by automatically setting the size based on placement.
Photos can all be on the workspace at the start or they can be held in a photo bucket allowing you to place them on the workspace one by one.
Layouts can be made by resizing and moving photos as individual elements or layouts can be row-based where you would work one row at a time and then move the rows up and down.

Assumptions

I’m the target user so I’m trying to think of assumptions that I can test with the prototype:

I’ll be trying different numbers of images on each row
I’ll be resizing images often
I’ll know the basic order of images before starting

Whiteboard the user story

We want to show how the user will step through the prototype.

The idea is to draw a comic book that tells a story starting when the user opens the prototype and ending when they complete all necessary tasks.

Anyway, here’s the storyboard. A little confusing because the second frame is a zoom in of a single image showing the overlay of size options.

(Knapp links to Scott McCloud’s Understanding Comics: The Invisible Art. I ordered it right away and blasted through it when it arrived. Amazon’s user story for me would be “User sees an item he kind of wants, buys it because it takes just as many clicks to purchase than it does to close the tab.” Mission accomplished.

Oh and it’s a great book that I’ll write about separately in terms of how it applies to storytelling and design.)

Day 4: Prototype

Note: I brought my MacBook in for repairs right around here and as of writing this I still don’t have it back. But bad customer service stories are like poker stories. Let me guess, you were ahead and then you lost because of a card. So yes, you guessed right, I brought it in for support and support is taking longer than I thought womp womp.

Day 4 is for prototyping. This is the part of the process I was most looking forward to.

Jake Knapp recommends using Keynote. I went ahead and bought it on the App Store but didn’t dive in yet. Dragging elements around is so important to this prototype and I don’t think Keynote would be the most effective tool for that.

I also have wanted to try out Packery for a while. I also want to work with AngularJS again. This is a good opportunity to try new tools out.

That said, the goal of prototyping is to be able to have something to test with users. The goal isn’t to write pristine production-ready code. I do want to improve though so I’ll strive to write good code while getting things done. Skewed slightly toward just getting things done.

Prototype walkthrough

In the starting screen, you see the photos 4-across in a vertical arrangement. You can see the general order of all the photos.

Hovering over each photo reveals size options.

As photos are resized, the layout rearranges accordingly.

A quick battle royale

Going back to day 3 of the Google Ventures posts, Knapp talks about “best shot” vs. “battle royale”:

You can prototype several different approaches and test them against each other (the “battle royale”) or you can go with a single prototype (the “best shot”).

In this case, I explored an earlier idea of creating posts with rows in mind without drag and drop:

I felt that it wasn’t working and I abandoned it early—a luxury I have because I’m working alone on something where I’m the target user. Starting with all the images felt better to me. Still, it was useful to try out and I’ll have something to refer for a future project where switching images and classes in place would be effective.

Thoughts

Building in code allowed functionality that Keynote can’t provide, specifically drag and drop. (I think, at least, because recently I’ve seen it do things I also didn’t think were possible.) Though I see why not getting into the details is so important. Sometimes it’s more fun to put polish on but the polish won’t help answer questions.

Choosing to build with tools I want to try out means extra time is needed for learning parts of the tools themself. I’ve never used AngularJS and Packery together. Working alone, the time constraint was more flexible and, as mentioned, trying new tools in itself is important to me. With a group, it’s probably more important to use tools everyone’s already familiar with or can get up to speed with quickly.

I’ll try Keynote on the next sprint. This means creating something involving more screens. (In this project I skipped screens for things like adding photos and exporting to Markdown.)

Day 5: Validate

cheap jerseys Google Ventures—Product Design Sprint Day 5: Validate:

Today, we test our prototype and learn which ideas worked, which didn’t, and what to do next.

The goal for the final day is to show your prototype to users outside of your company. In my case, the user was me. This is a cop-out and the next time I try a design sprint I’ll make something for others to try out.

Hello However, I still learned plenty by using the prototype to try and create posts. Here are a few key questions and answers.

Does drag and drop work for laying photos out?

Yes. Dragging photos around is much better than manually changing classes in Markdown posts and viewing it in the browser.

Is it better to start with all the photos on screen or add them one by one?

Thinking non-digital, I’d lay out a lot of photos at once and move them around. This translates to the interface I’m building. There doesn’t seem to be any advantage to working on ephoto at a time.

Is resizing with predetermined sizes a good idea?

Not so sure. And I think there’s better ways. The disadvantage is having to write the CSS classes to switch between. Packery provides a lot of flexibility so allowing any size with a corner drag might be worth trying out. On the other hand, the predetermined sizes allow me to stick to cheap jerseys a general grid system without thinking. Resizing would be something to focus on if I did another sprint for the same project.

When building posts by hand in Markdown and HTML, I think of things row by row, would this sort of flow work in the interface?

Working one row at a time didn’t work as well as starting with all the images on screen. The alternate prototype wholesale nfl jerseys in day 4 gave me pretty hard confirmation. Switching photos in place would be more useful if I didn’t already have a sense sequence. But I generally know the photo order because each post represents the order that photos were taken in real time.

Closing thoughts

Here’s a day by day review of each day.

Day 1: Understand – This translated well from a group activity to an individual. In a sense I just do what I would do with the group: research the problem and share my knowledge. I lose the group insight. On the other hand, sharing through a blog post means I have to spend time thinking and organizing thoughts for the world to see.

Day 2: Diverge – I loved this. Generating ideas is fun and effective even without a team. For the next sprint, I’ll consider doing more activities for generating ideas or doing the same activities for more stories.

Day 3: Decide – I really like the idea of storyboarding everything so that you know exactly what to build for the prototype. I’ll try something involving more screens the next time I try a design sprint.

Day 4: Prototype – I like building things and it’s great to get to the prototype step and have a really good idea of what’s going to be built. With nearly everything thought through, I was able to focus on learning trying out new tools.

Day 5: Validate – I was making something for myself and tested on myself. Not exactly in the spirit of the original design sprint, but I learned lots of useful information.

I plan to do more personal sprints in the coming months. Altogether, including the blog posts, it’s great for practicing design, programming, and writing. The constraints set an end point and I can ship and move on.

This first go was a little rough since some things translated better from group to individual. I’ll iterate on this personal sprint process. I’ll try different timing to focus on certain steps or try out different tools. For instance, maybe I can try a phase after prototyping to drill into animations and more aesthetic aspects.

And I’ll spend more time writing a shorter letter.

I’d be glad to hear any feedback on Twitter: @makeshowlearn