Erica Heinz

May 24, 2013 at 12:10pm
0 notes

The 100-Day Solution

There used to be a great article here:
http://dev.theladders.com/2011/01/the-100-day-solution/

But it’s gone from the Internet now, so I can’t send it to a client. So here are my notes.

THE 100-DAY SOLUTION (by The Ladders)

A Lean UX workshop template. The process is open and collaborative, and helps coalesce a bunch of ideas into a plan of action.

PREPARATION:

Recognize your problem statement. e.g. “We need to do MORE of what we currently do to differentiate ourselves and do a better job TELLING people about it.”
Pull in a cross-functional team for collaborative sketching. Include developers, designers, marketers and product managers, plus operational folks and subject-matter experts. (This example used 50 people, in 7 groups of 7, for 3 days.)

ORGANIZATION:

Choose one theme for each day (focus on one aspect of the service): state the objective clearly. This provides much-needed guardrails to constrain the realm of the feasible and ensure everyone is progressing towards the same goals.
Start with short presentations and video clips to articulate the situation to the broader group and provide the context necessary for their collaboration.
Divide the room into representational slices of the competencies in the group. Each team should have representatives from each department.

TEAMWORK:

5 minutes: Each person creates 6 low-fidelity sketches around the day’s theme.
Each member presents their 6 ideas to their team and receives critique from the other members.
5 minutes: Each person refines their original concepts into 3 higher-level approaches.
Again, each team member presents and gets critiqued.
5 minutes: Each person refines their 3 ideas into 1 high-fidelity sketch.
Present to the team and critique.
45 minutes: Teams take their 7 high level ideas and debate, pare down and combine their thinking into the one idea that will achieve the day’s stated objectives.

PRESENTATION:

Group the big ideas on a wall, ordered in such a way that allows some to overlap and others to lead into each other in a physical simulation of a workflow.
Each team presents their big idea to the entire room. Critique is open to the entire floor including the managers facilitating and sponsoring the event.

SELECTION:

Debate priority, feasibility assessments and high level point estimates (LOE)
Pare down the ideas into what seems like a realistic set of features to execute within the given time frame (e.g. 100 days).

EXECUTION:

Chunk work into two-week iterations, for incremental release and testing
Talk weekly to execution teams, on a broad basis. Communicate progress and accomplishments as well as realistic risks and any misses for the week. Have teams demo their work in progress (preferably on large screen, with management present) to ensure high quality.
Announce release (via internal email) every two weeks. Announce what was launched that day, and the rationale for building the feature. Sketches vs final product are often fun to include.
With each release, listen to user feedback on the new features, and adjust the work plan.

March 7, 2013 at 9:16pm
2 notes

Last weekend I attended Lean Startup Machine, a weekend workshop to test your startup idea through audience interviews, low-tech demos, and rapid iteration. My main client runs lean, and I’ve been trying to get my volunteer groups to move in that direction, so I went to experience the official process.

On Friday night, about 40 people pitched ideas to a crowd of 100. We each got 3 votes to narrow things down, and then split into teams of no more than 5. I joined a team interested in crowdfunding neighborhood development projects in NYC.

Step 1. Identify your audience and their problem.

Our team thought that NYC co-op owners with children would care most about their neighborhoods. We would measure this by action taken (calling 311, attending town halls, etc). We thought they were dissatisfied with current channels of action. We would measure this by ratings.

To confirm a problem, the recommended tactic is exploration. Interviewing your audience. No leading them, no selling, no “yes/no” questions, no hypotheticals. Better to ask what? why? how? about actual past actions.

We headed down to Trader Joe’s, since we’d find the most residents (vs tourists) at a grocery store. We interviewed six people before we got kicked out, and then another ten outside. It turns out that home ownership and parenthood were NOT a strong indicator of action. Length of time in one neighborhood was. So we did a customer pivot, to say NYC residents for >5 years (in the same neighborhood) are dissatisfied with current channels of action.

At this point we should have done another exploration trip, to verify our users and problem, but the team wanted to move on to a possible solution: a crowdfunding platform for neighborhood development.

Step 2. List all your assumptions. Test the riskiest.

We were assuming that crowdfunding real estate was legal, that developers would be interested in the funds, that projects would actually come to light, and many other things. Some could be validated via research; we decided to test an assumption that our audience members want info on development in their neighborhood.

To test a solution, the recommended tactics are either pitch (acquire currency: attention, contact info, money) or concierge (deliver on your users’ expectations in the simplest, most lo-fi manner possible). Then follow up: are users ELATED by your solution? If not, rework.

We went out to pitch at Chelsea Market, which has a lot of conflict over rezoning at the moment. We asked if people were aware of the plans for the market, and if they would be interested in that type of info about their own neighborhood. We said 50% interest was our definition of success. 7 of 11 said yes, and gave us their email address, which validated our assumption.

Ideally, you’d have continued metrics on these kind of stats, so the definition of “validated” would have a reference point.

3. Keep validating your assumptions, one by one.

There were quite a few hidden assumptions that came up when we really made a list. This was one of the most helpful exercises, both at the workshop and when I later went through the process with a client. It was illuminating to outline our risks, and realize we could test each one, instead of just bundling them all into a product ;)

For the workshop, we could have developed a low-tech newsletter, and sent it out to the email addresses we’d collected, but our team didn’t all agree on the solution we’d pitched. So, we did another round of pitching, testing the assumption that our audience prefers local developers to chains. We were getting ready for the presentation, and needed some good photos, so we did a gimmick with coffee cups and signs. I don’t think our data was valid, but we had fun waving a sign and asking for dollars. And we learned (of course) you get very different answers at Penn Station and Whole Foods.

The hardest thing was remembering to make sure people were part of our audience before interviewing them. You’re never going to make everyone happy, you have to find your people and design for them.

Top takeaways

Risks can be tested. The sooner, the better. Fail faster.
One thing at a time. Then, when you connect the dots, you have an actual path instead of a fog.
Ask the right people. Data’s only valid if you’ve qualified your subjects.
Keep the team together. We split up when the mentors were rushing us, and ended up w/useless data b/c we’d diverged on the idea. Clarity is key.
Just launch already. You’ve got at least one clear idea (I hope). Get the very first test up, and go from there.

I would never have attempted anything like this in normal life, so the process was really valuable. And eventually fun.

Over the course of the workshop, we saw some great ideas get polished into legit startup work within 48 hours.

Get their Validation Board if you want to try it yourself.

February 7, 2013 at 10:58pm
0 notes

Here’s to the

Filled out the application for Greenville Grok today, had the hardest time with the “any other cool skillz?” question. Realized I’ve been very focused on practical/political things, not much playing lately.

So here’s to:

doodles … dancing … drinking … dressing up …
baking … crafting … singing … pretending …
watching … capturing … rearranging … polishing …
pontifying … poetry … remembering … recording …
racing … resting … wanting … wishing …
sledding … sleeping … snowballing … screaming …
drumming … drifting … boating … nesting …
necking … building … sketching … releasing

January 16, 2013 at 3:54pm
292 notes
Reblogged from explore-blog

explore-blog:

Clustering, one of Bill Cosby’s three proven strategies for learning to read faster

January 14, 2013 at 10:55pm
1 note

Six daily habits for artists:

1. Sit alone; sit quietly
2. Learn something new without any apparent practical benefit
3. Ask individuals for bold feedback; ignore what you hear from the crowd
4. Spend time encouraging other artists
5. Teach, with the intent of making change
6. Ship something that you created

— From The Icarus Deception by Seth Godin. I love these; I’m going to set them all up to repeat in Habit List.

January 3, 2013 at 10:43pm
0 notes

The creative process

I’ve referred to this so many times, and just mentioned it to yet another friend, so here you go, Internet: the stages of creativity (anxiety):

creative anxiety

It’s from a book I stole from a friend in college, Fearless Creating. The cover is so ugly you’d be ashamed to hold it, but if you get the eBook no one will know.

November 27, 2012 at 12:01pm
9 notes

The redesign process for occupysandy.org

Occupy Sandy is one of the most inspiring humanitarian impulses I’ve ever seen. Volunteers self-organizing in rapid response to a terrible crisis — a breath of energy in a sea of economism. It’s also been more effective than the major relief organizations!

I volunteered to redesign the front page, just to organize the valuable information a bit more clearly. It turned into an entire site redesign, completed in six days. I could barely eat or sleep, it was so exciting. Solid adrenaline.

I couldn’t believe how smoothly and quickly it went, so I’m writing it up as a tutorial for others working in crisis situations. Transparency = education!

WEDNESDAY AFTERNOON: DISCUSSION

The first step was to talk to the current web team. Devin, an organizer in the TechOps group I’m part of, had connected me with the web team at Interoccupy (Michael, Andrea, Jackrabbit). They’d set up the existing site as part of their Wordpress multisite network, and were working to consolidate location details into one Google Fusion Table (a spreadsheet that can power a map or a directory). Drew, another TechOps organizer, scheduled a Google Hangout, and we talked about design needs with various tech teams. We logged meeting notes in an Etherpad setup; follow-up discussions happened in the #occupysandynyc IRC channel. (Sam gave me a whirlwind tour of the IRC bots crawling all the relief/aid feeds, with volunteers sorting/dispatching the requests. Pretty amazing.)

THURSDAY AFTERNOON: MINI PROJECT

Sougwen, who’d organized the Fusion Table, asked if I could first design the “cards” for the locations page. It was a good small exercise for me to start with, and calmed my nerves; even if I completely flubbed the rest of the site, the cards looked better and that was something. I did Illustrator mockups, revised w/the group, and then wrote the HTML/CSS version so that Charles could start writing the FusionTable/Wordpress/Isotope plugin. (Primary rule of productivity: Don’t be the bottleneck.)

THURSDAY NIGHT: INFORMATION HIERARCHY

I wanted group consensus on the site’s priorities before I started laying anything out. So I wrote them in a Google Doc, based on the ideas in this Responsive Comping article. This simple numbered list focused the discussion on content: what we had or didn’t have, and its appropriate prominence in the visitor’s experience. I asked for feedback on the information hierarchy.

FRIDAY EVENING: SITE MAP

Next I wanted agreement on the arrangement of the information. So I created a site map with lo-fi content blocks in Omnigraffle. It showed a revised sidebar, separate updates/locations pages, a new FAQ page, and a new local navigation to easily get to these pages. I put these in our shared Google Drive folder for review. Meanwhile Gregg, the Wordpress volunteer, could start researching themes to use as the base. (He chose the Foghorn theme, a simple and responsive base.)

FRIDAY NIGHT: HTML PROTOTYPE

I expected much more feedback once people started clicking on the site, so I wanted to get those comments as soon as possible. So I built an HTML prototype, which let me copy/paste all the pieces of content from the existing site into their new homes, and write the text that didn’t exist yet. It went pretty fast since I used LESS, Codekit, a lot of code clips from my library, and started trying Emmet (a CSS-like shorthand for code). I used semantic.gs for a basic grid system, since it keeps class names out of the markup. I finished the site by 3am and sent it off, again asking for feedback on the arrangement of information. Meanwhile, Charles and Gregg had gotten the data flowing into the site.

SATURDAY AFTERNOON: DESIGN COMP

Comments had been gathered by the time I woke up, so we had another Google Hangout to review. At this point I wanted to get out of the HTML and let the backend developers have it. I can’t design entirely in the browser — I need to go back to visual software to stop being box-headed and overly practical. I switched over to Illustrator and did a front page mockup, which included the header, the sidebar, a callout, and a feed. All typefaces were open source (Open Sans, League Gothic, Entypo, and Stateface), so they could be shared with other designers. I put the png in our shared folder, and asked for color and styling feedback.

SATURDAY NIGHT: STYLESHEETS

Once I had feedback on the design, I began the site’s stylesheet. Gregg had finished the main template and plugins for the home page, so I was able to copy the rendered HTML into a new prototype, and adjust my LESS to fit the actual markup. (I compiled the LESS locally, since our server-side compiler was breaking things.) So we had the main header and sidebar styles done. Then things started getting tricky. I wanted to start working on the live stylesheet, not a prototype, so we could all start to see how the developers’ work would look. They’d gotten the theme set up in our Github repository, and I was able to pull and push the files, but I didn’t have a local development environment set up. I’d used MAMP and installed Wordpress locally before, but we didn’t have time for the expected troubleshooting. So, I had to make my LESS changes locally, push to github, and have someone deploy to staging in order to see what they looked like. Thank god Drew was around to teach us all git. It was fine, until everyone went to bed. Then I just worked blindly, page by page, adjusting the CSS in Firebug and pasting it into the stylesheet. By 7am there were too many unknowns so I stopped. (Gregg set me up w/local dev the next week, and it took 15 minutes. Lesson learned: don’t be scared.)

SUNDAY NIGHT: DEADLINE

No time for merge conflicts, so I agreed to stay out of the PHP and Gregg agreed to stay out of the LESS. The rest of the web team had given us a huge document of feedback, and new/revised content, so Gregg set up a bug list in Google Spreadsheets, and I prioritized the tasks. (The spreadsheet continues to serve as our development road map.) The content team made sure all of the new pages and FusionTable fields were filled out and ready to go. Michael, Andrea, Sougwen, Pea, Devin, Leah, Dana and others were adding content as soon as we had each template done. We were up to about eight tabs instead of four. The goal was to launch the site Sunday night, since Monday was typically the lowest-traffic day, and we all had to go back to other jobs. We worked til 4am, but it wasn’t feasible. We still had a lot of bugs, and features to be styled.

MONDAY NIGHT: LAUNCH

By Monday night we’d browser tested (Chrome, Firefox, Safari, and IE8+), speed tested (using YSlow), and debugged. (Even though we had no real staging server; our “staging site” was actually just another Wordpress multisite hub, with no way to deploy to the real production server.) At 2am Gregg moved the theme from our dummy site to the live site. I finished marking up the final content pages by 4am, and we were DONE. Everything was ready for Michael’s 5pm interview on HuffPo live video!

I’m sure I’ve forgotten some pieces, but that is the gist. It was an amazing collaboration, everyone brought such dedication and focus to their part. There’s such a lack of ego, they could teach yoga classes. And a great thing about Occupy is that no one tells you what to do; autonomy is a main principle so there’s a lot of trust and encouragement. It’s still going strong; at the #HurricaneHackers meetup the next weekend, we planned the integration of the NJ site into our main one, and at the #NYTMresponds hackathon this weekend, we’ll be working on the Sahana inventory platform and a redesign of the coordinators site.

Contact me if you’d like to help out! There’s a lot more to do…

November 16, 2012 at 10:20pm
0 notes

Web ABCs

A is for apple

B is for bit.ly

Type each letter of the alphabet into your browser, and see what site comes up for each.

I’d share all of mine, but then you’d hack my life.

October 21, 2012 at 5:31pm
24 notes

Rapid Prototyping Resources

Here are the promised resources from my talk at the 2012 Future of Web Design conference in NYC. This is by no means a comprehensive list, but should be a good start. And here are my slides.

And here’s the special Riffle invite for FOWD attendees — jump the line. It’s good through this Friday, October 22nd.

Choosing a tool:

Rapid Prototyping Tools — Adaptive Path’s article on choosing a tool, with a spreadsheet overview of them

What are the best tools for rapidly prototyping a web app? — nice Quora thread

What are the prototyping tools for mobile apps? — another Quora thread, for mobile apps

Protomoto — huge grid of available tools

Paper prototyping:

Pretty Sketchy — the importance of sketchbooks

The Messy Art of UX Sketching — overview of techniques

Sketchboarding: Discover Better, Faster UX Solutions — very cool ideas

Sketching tools:

Adaptive Path’s Favorite Tools for Sketching — great details on the pens and markers that are most useful. I also like a highlighter.

Tools for Sketching User Experience — more tips on tools and sketchboarding

Pixel Pads — notepads in iPad or iPhone shape

Printable Paper — all kinds of graph paper you can print yourself

UI Stencils — rulers and metal stencils

Smashing Magazine’s Wireframing Templates — lots more templates

Digital prototyping:

Time to Dump Wireframes — great overview of articles on the end of wireframes

Designing Better and Faster with Rapid Prototyping — instructive article discussing process and types

Digital tools:

OmniGraffle — great for site maps, wireframes and prototypes

Balsamiq — simple sketchy wireframes, with symbol libraries

iOS source file — by Teehan + Lax, many others there too

Proto.io — web tool for making iOS prototypes

Keynote — presentation software that can also make high fidelity prototypes

Keynotopia — library of keynote templates

HotGloo — mentioned by Dave Stein at Behance

HTML prototyping:

CSS and Design Frameworks for Rapid Prototyping and Web Applications — good comparison of Bootstrap vs Foundation and others

Dive into responsive prototyping with Foundation — explanation on A List Apart by the founder of Foundation

Spike-driven design — interesting idea from Pivotal Labs

HTML tools:

HTML5 Boilerplate — The standby, built and tested by expert developers

Semantic.gs — My favorite grid system. Keeps grid classes out of your markup

LESS (or SASS + Compass) — Essential tool for modern CSS development. Extends CSS to include variables, nesting, and functions, which all compile into normal CSS.

Codekit — nice compiler for all sorts of preprocessors

Coda — my favorite HTML editor

Coda Clips — library of clips for the above

CSS Tricks — Chris Coyier’s awesome collection of code clips, tutorials, demos, forums…

Emmet — toolkit of CSS-like expressions that can be expanded into HTML/CSS

Wirefy — browser-based responsive wireframe tool

Foundation — front-end framework

Mobile-First Foundation — a mobile-first version of Foundation, on github

Bootstrap — Twitter’s framework for web apps

Punch — “modern web publishing framework” that includes data layers

CodeIgniter — PHP framework

CakePHP and Croogo — simple PHP framework and CMS