Monday, January 25, 2016

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:

http://forspareparts.github.io/2016/01/24/actions-up-data-sideways/

Monday, November 9, 2015

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.

Thursday, July 9, 2015

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.

Friday, March 20, 2015

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 user activity. We continually interview customers via formal interviews and check-ins, but also by taking the time to deeply understand what they are trying to accomplish during support calls and sales check-ins.

Tuesday, January 6, 2015

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


  1. 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.
  2. What's working for them now?
  3. 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.
    • Very few user's "flow" from point a to point b. You can force them into a wizard pattern, but its more likely you will bore them and/or lose them in your flow.
  • Build in tracking of user activity so you can verify users are reaching goals.
  • Build in an internal review process to periodically review how well the features you built are working. I always learn from usage metrics as much as talking to actual users.

Tuesday, July 15, 2014

The sum of my experience with product making

People make companies and products. Process helps support and grow good people, but fundamentally it's all about the people.

There is a whole lot more to it than that, but this is the first thing to know.

Tuesday, February 26, 2013

Advice for Developers and Designers Working Together

From my talk at the University of Chicago Booth School of Business:


Excellent advice on getting developers, designers and managers to work together. It's featured here in our [UrbanBound's] latest blog! hub.am/XeZ6hq

Friday, January 18, 2013

Customer Development for "Product You"

As a manager I've always found it hard to get honest feedback from employees and my management. In larger companies the feedback culture in management often boils down to: positive feedback leads to good reviews - which leads to expectations of paying higher bonus. Employees will give their managers good reviews even in anonymous 360 reviews.

The solution

LinkedIn's endorsement feature can a be used to get good feedback from people. It will tell you directly what you're bad, but it will tell you which are good at.


Here is how it works 

 

If you want to know if people generally think you are good at something
Look at how many people endorse you for that skill.  If you have lots of endorsements for other skills, but none for the the skill you are watching. Guess what? People are telling you you don't have it.

If you have a skill that you don't use often but you're wondering if you're any good at it
Make sure its on your profile. If you get a number of endorsements, people think you have that skill.
Maybe its time to hone that skill to perfection?

If you don't know if you have a skill, but want to test if you do
Go ahead and throw it up on your profile. People can always ignore it. If you get some endorsements there is some potential there. Maybe its time to start training.


I have almost 700 people in my network on LinkedIn. I'm getting a good sense of what people know me for. I also see where I need to do some personal marketing in order to let the world know I have a skill. The good news is that I am not surprised by what I'm being endorsed for.


Note: There are a few more steps you will want to do in order to fully run customer development on yourself. Customer development is not a term a coined. I discovered it via Steve Blank in his book The Four Steps to the Epiphany. I highly recommend you check it out.

Thursday, January 3, 2013

What Is A Product Showcase?

I couldn't find a simple description of a product showcase today so I wrote a quick one myself

The showcase is an important part of product development. In it the product development team shows newly developed features to the company's stakeholders before releasing them to customers. It promotes early feedback (before the cost of change is too high), facilitates communication between roles in organizations and ensures the correct product is being built.

Friday, October 5, 2012

An update to principled leadership

Photo credit: raphaelchekroun
One my most popular posts of all time is one I put up in 2009 about Principled Leadership. I still get traffic from this post and once got a very aggressive job solicitation based on the principals outlined in the post. Recently I came across a quote that nearly sums up the whole list in one sentence:

Smart leaders understand it’s not just enough to pursue, but pursuit must be intentional, focused, consistent, aggressive, and unyielding.

*I'm afraid I don't know exactly where this came from so, if you are the owner, please let me know so I can link back to you.

Friday, August 3, 2012

Shallow Copy in Ruby

I often wonder why some organizations only consider candidates who have computer science or computer engineering degrees. In the real world I have seen many great developers who have come from diverse backgrounds. However, I had an event recently that made me really happy I have a degree in computer engineering. It made me understand why the favoritism exists for computer science credentialed developers. I had an issue with an email template in Ruby on Rails that without a good mental model of compilers and, specifically, compiler optimization would likely have taken a long time to identify and fix. Here is what happened:


in a database somewhere...
UPDATE app_configs SET affiliate_template = 'Welcome to UrbanBound #[FirstName], '

def send_email_to_todays_movers

  Mover.each do |m| 
    @boiler_plate_email = AppConfig.find_by_config_name('affiliate_template').value
    [business logic goes here] 
    prep_mover m, @boiler_plate_email
  end 
end

def prep_mover
   [business logic goes here]
   @movers_name = Mover.find_by_id(m.id)
   send_welcome_email @movers_name, @boiler_plate_email
end

def send_welcome_email (first_name, boiler_plate)
   boiler_plate['#[FirstName]'] = first_name
   ......
end

*If this is good code architecture or not I'll leave for another post. We do most initial development of features as an MVP at UrbanBound. Its usually not worth optimizing code the first time we are testing a feature out. That being said I have a strict rule of using TDD and keeping 95% code coverage on models, helpers and controllers. Generally speaking, no business logic is allowed in the views.


The first time I ran this code (via rspec - I'm not this guy) the outgoing email message had the correct first name for the first mover. However, the others all had the same first name as mover #1. It didn't make sense to me at all. The boilerplate email template was changed in the send_welcome_email method but we refreshed it each time a mover was processed. Then I thought about my days doing C/C++ and how compilers work. Maybe the Ruby interpreter couldn't see three levels deep into the execution tree to see the boilerplate was updated. Perhaps it just did a shallow copy of the boilerplate after the first execution and was effectively sending a memory location of the boilerplate. Never updating it after the initial read from the database. After some experimentation I found that I was indeed correct. The compiler was performing an optimization that made the code faster, but didn't produce the intended action the programmer gave it. This is the trade off compiler builders always make.  Back in graduate school I could get my compiler to generate code that ran 2x-3x faster than the benchmark compilers, however after running millions of test data sets against it I noticed errors in 1 or 2 of them. This may be fine if I was playing in media, such as an mp3, but not good for computations that affected people's life and safety.

It turns out the solution is simple. Explicitly tell Ruby that you want a copy. Here is the code:

  Mover.each do |m| 
    @boiler_plate_email = AppConfig.find_by_config_name('affiliate_template').value.dup
    [business logic goes here]
    prep_mover m, @boiler_plate_email
  end


I found another great description of the problem [here]



Thursday, May 3, 2012

From the maker's perspective...

I came across this article via LinkedIn. It reminds me of the Maker Schedule, Manager Schedule discussion except its from a maker perspective. Given that I have been doing a significant amount of development in Ruby on Rails for UrbanBound for the past 3 months, I'm following a maker's schedule again. Being my own boss makes things simpler, however I think its important for makers to understand how to be productive and articulate to their management how they can be best managed.


If this seems a bit counter intuitive to you. I can tell you that good managers do know how to manage. However, given all of the pressures around managing a business, its easy to fall into the trap of thinking about management objectives over the needs of the people who getting the work done.

A healthy reminder:


7 Things Highly Productive People Do

Monday, April 16, 2012

Call It Like It Is - Save Time and Money by Filtering Out Non-Users in Your Application's Design

At UrbanBound we are  necessarily obsessed with who our users are - and who they aren't. An application designed for baby boomers utilizes very different design principals than one designed for a younger audience. If we try to design for everybody (the lowest common denominator) we just aren't going to be compelling enough to anybody. We keep a visual reminder posted of who we are, and who we deliberately aren't, build for. This way we don't waste time and limited resources on people who aren't likely to work with us.





Tuesday, April 10, 2012

Why I hate the Internet sometimes

 Watch my site get slow. Watch me download the logs to make sure nothing happened. Thanks for wasting my time script kiddies.

Monday, December 19, 2011

Why car companies need to do usability testing

Overall I love my Toyota Prius. Under the hood, it is an engineering marvel. Prius' have been around for 10 years and still sell like hotcakes.  I honestly don't understand why Ford hasn't made a competing product by now.

I have come to realize that I pay attention to design more than the average person. I hate it when simple design mistakes ruin an overall well designed product. The interior of my Prius has some obvious problems that could have easily been fixed had they asked the right questions.


Separation of Concerns
Is there any reason they needed to put the door lock/unlock button between the buttons that operate the windows?


The buttons feel different - therefore its not likely that I'm going to press the wrong button. However, nearly every time I want to use one one of the buttons I have to take my eyes off the road and look at the buttons to choose the correct one or I have to feel each one to get the correct one. This simply violates the principal that you shouldn't make your users think necessarily.

Positive Actions vs Negative Actions
-and-
Direct Users To The Most Common Action
To me, Toyota completely confuses button shape and action. Its been nearly 8 months and I still have to stop and think about which is the correct button. I occasionally make the wrong choice and send a caller to voicemail rather than picking up the phone. Take a look at the phone answer and hangup buttons:



The button to hang up the phone (the top one) is raised. I consider this the negative action. The button to answer the phone (bottom) is sunken in. This bothers me for two reasons:

#1 If I'm driving and the phone rings I'm being interrupted.  Thus, I'm not 100% focused on the phone yet. The easiest button to find is the raised button. This should be the button I hit to answer, but Toyota made this the hangup button. Maddening.

#2 When I'm ending a call the sunken button makes sense. No matter what mnemonic I go through the raised button doesn't work for ending a call/conversation.

Because I'm thinking about what the right button should be I sometimes make the wrong choice because I'm thinking too hard about doing the opposite of what comes naturally.

*Note: They make all Toyota Prius' for the whole world in Japan. The above concerns might be personal issue or an issue of how British/Americans view the world. I don't know if Toyota makes all of their cars the exact same for all geographies either.