When I started this blog, Agile was not yet the lingua franca of product development. I was passionate about teaching the Chicago community about Agile. I helped start the Chicago Agile Project Managers Meet Up. I presented at the international Agile conference. I was coaching organizations to use Agile practices and how to integrate user centered design into product development. Good times. Based on this blog’s old google analytics data I can see that I was able to help a lot of people.  Today I find myself spending very little time on blogs - reading or creating. My go to places to find content to learn and grow professionally didn’t exist when I started Planning for Improvisation. This blog isn’t needed anymore. As I have moved on, this blog can too. -Kal

An Easier Way to Decide

Originally posted on ForeverCar Blog: You probably have far more important priorities than taking the time to research vehicle service protection plans. That’s where we come in. When we set out to create the latest innovation to our consumer shopping platform, we vowed to keep it simple. If you are not shopping for vehicle service protection at , you are likely sitting across the desk from a loan officer at a bank or a finance manager at a dealership. There are a couple problems we've identified with this scenario: It’s bad timing.  You are typically involved in a larger, more complex loan transaction involving your vehicle. Taking the necessary time to research the offering is impractical and highly unlikely to happen in that moment. That’s why most people pass on vehicle protection at the bank or dealership. Wrong amount of detail.  There’s a lot to this. A service contract is full of important co

Ember: Actions Up, Data Sideways

The rallying cry for Ember 2.0 has been “Data Down, Actions Up”. Ember's component based architecture sets a pattern where data is passed “down” to child components, while children “request” changes from their parents by triggering actions. This certainly has its advantages ... until it becomes unwieldy. My colleague @ForSpareParts and I have been deep in the trenches implementing an analytics and big data product in Ember for a number of months now. He wrote a great article about an alternative to Data Down, Actions Up and proposes the alternative architecture we have landed on. Its a good read:

Debugging Minified Javascript

This is an error we got in the early morning hours from our staging environment: c is null There are lots of things to like about minifying Javascript except this of course. Removing proper variables annihilates context so completely.

Your Inconsistent Design Makes Me Worry About Your Entire Product

This is from a product I use daily. Who wrote this code and thought they were done? Who approved these two button styles next to one another? I have this vision of a developer choosing a library that made their development life easier. I picture this code going straight into production use without review. Next, I picture the designer who works there rolling their eyes, checking out, and heading to LinkedIn to see what other opportunities exist. I'm being unfairly harsh, but it makes me wonder what other sloppiness is happening inside this product.

Applying user centric design to your business plan

Image by Lars Plougmann I got asked by an investor recently how we at Digital H2O do design. I liked the conciseness of my response and thought it was a good example of how to tie user centric design into a business plan. Here goes: Our design philosophy is best described as user centric design. Our goal is to only design and build features our current, or potential customers, find valuable and that substantially help our business continue to grow. We spend significant time listening to our customers’ needs throughout the sales process. We then form hypothesis what customers’ needs are and what they can accomplish in the application. While designing features we show mock-ups and prototypes to customers in order to get feedback and incrementally improve the design. After the product is built and released we continue to test our hypotheses about how customers will use features we have built. We utilize automated event tracking in the app to monitor u

How to start a product redesign - a playbook

A few months back I was working on a large, ground-up redesign for a product I own. I had a little trouble getting started. I realized I needed a playbook to remind me of the basics. I am sharing my playbook for those who are having trouble and procrastinating getting started. Enjoy. Before you start At the highest level, in one paragraph, what is a representative user's goal and the problem you are solving for them?  If you can't answer this succinctly you have many, many features or you don't know your users well enough to continue.  Slow down, answer #1 for each feature set before you go to #2. What's working for them now? What's not? What you need to design for them Verify you are building all the tools they need. Show the process they will use to reach goal - give them a map or trail to follow. Indication of progress toward the user's goal - "You are here" Make sure you build in escape hatches because they find a better way.