Raise the Bar

Perhaps the single most useful thing a manager of a design/development team can do is to raise the bar of quality. By extension, I think this also holds true for clients of design agencies.

By ‘raise the bar’ I don’t simply mean saying, ‘This isn’t good enough’ or ‘work harder’, or this…

Raising the bar sounds simple but it’s not. To do it properly, the manager/client must first understand what is possible given their budget and timeline and resources. Once you know this, you can see when the output is short on quality and you can do something about it.

Second, you need to have a sense of what is currently keeping people from falling short. Is it a personality conflict? Too many meetings? Not enough coordination? Rushing into execution without generating enough good ideas?

Third, you have to have the guts to deliver the message in a constructive way. The Steve Jobs yell-at-people method worked for Steve Jobs, but unless you work at Apple it may not work for you. In my experience good people want to do well. They want to feel good about their work and themselves. They want awesome samples in their portfolio. So appeal to their work ethic, paint them a picture of how awesome the future is going to be when things are different, then set the bar of what you expect.

In sum:

  1. Understand what is possible in your situation
  2. Figure out where the obstacles are and remove them
  3. Constructively set the bar higher for the team by inspiring them

Docker and Containers Summarized

Just as container ships can carry more cargo because they use a standard form factor for storing the cargo, software containers can run more apps on each server by using a standard way to share the operating system without all the wasted overhead of virtual machines.


  1. Containers bundle together all the pieces you need to run the app into one package.
  2. Containers make it easy to deploy apps to local servers and the cloud.
  3. Docker makes it easy to create containers.

Also check out Steven J. Vaughan-Nichols’ What is Docker and why is it so darn popular?.

Microreview of Financial Engines

Kevin Mercadante has a great review of Financial Engines on the Investor Junkie site. Here’s the key points I took away:

Founded in 1996, Financial Engines is a retirement plan advisory service for employees of participating employer retirement plans (which many online advisors work outside of).

They provide management services and advice so that either they can manage your plan, or you can do it yourself but armed with their information and input.

The service is made available through your employer plan, which is to say that it’s offered as an additional benefit — or in this case, a benefit within a benefit.

A very few employers make the service available to their staffs free of charge, but the range is between 0.20% and 0.60% of the value of your retirement portfolio, with the average being “just below 0.40%”. Based on the average, the cost on a $100,000 401(k) plan would be just below $400 per year. This is the fee you will pay to Financial Engines while using their service. It does not include administrative fees paid to your account administrator, or transactions costs to trade and maintain securities and funds. As far as account minimums, there are none.


Analyze your retirement plan saving options

Consider expense ratios, sales loads, asset turnover, transaction costs, management style of individual fund investments, among other services

Provide you with a Progress Report showing your account balance, the potential value of your account when you retire, and the adjustments they’ve made to reflect your situation and market conditions

As you approach retirement, you get detailed Retirement Checkups with expert advisor representatives who can help you stay on track

Their Social Security Planner is a tool that can show you how to maximize your income from that source.

Key Points from an Interview with Dr. Harry Moskowitz

aka the father of modern portfolio theory

“Perhaps the most important job of a financial advisor is to get their clients in the right place on the efficient frontier in their portfolios,” he told me. “But their No. 2 job, a very close second, is to create portfolios that their clients are comfortable with. Advisors can create the best portfolios in the world, but they won’t really matter if the clients don’t stay in them.”

In other words, MPT and behavioral economics have to work together. And Moskowitz figured that out early…

“There was a big difference in my views about how and why to use mean variance analysis (that’s academic-speak for MPT) in my 1952 paper and in my ’59 paper. In the ’52 paper the only portfolio constraints I was concerned about were to avoid negative returns. But by 1959, I was concerned about [how investors would react to] the portfolio construction: For the comfort of the clients, we put constraints on ‘risky sounding stuff,’ such as junk bonds, etc. We knew that might dampen returns, but it was better than if they chicken out in a down market.”

From an interview with Bob Clark.

Key Points from “Investor Behavior: The Psychology of Financial Planning and Investing”

“Policy-Based Financial Planning: Decision Rules for a Changing World” by Dave Yeske, managing director, and Elisa Buie, CEO of Yeske Buie. Based on their 2011 paper, Yeske and Buie provided a six-step process for creating effective financial planning policies for each client:

  1. Engage in the discovery process in which the financial planner learns about the client’s personal history, values, beliefs, goals and resources.
  2. Identify planning areas and best practices required by this client.
  3. Combine goals with best practices to create a proposed policy.
  4. Test the policy: Is this a good policy?
  5. Test-drive the policy with the client and listen to their feedback.
  6. Conduct periodic reviews and updates checking for changing circumstances.

“Advising the Behavioral Investor: Lessons from the Real World” by Gregg Fisher, founder of Gerstein Fisher. “While he cited common investor mistakes such as failing to rebalance, chasing yield and underestimating the impact of inflation, he also explored the less talked about failure to consider a client’s income stream as an asset; one that requires at least as much—if not more—offsetting diversification than their other holdings.”

“His unconventional approach is also evident in the considerable body of research he cited debunking the advantage of dollar-cost averaging versus lump-sum investments. Fisher suggested that “sub-optimal” investment strategies can also be the best investment strategies. “Instead of debating [whether MPT or behavioral finance strategies are better], an investment advisor should borrow from both. The result will be an investment portfolio and strategy that may be suboptimal from an MPT standpoint, but may be the right approach for the investors. In other words, sometimes ‘the right portfolio’ isn’t the right portfolio.”

He used an example that shows how “based on information about a client, as well as experience with other clients in similar situations, an advisor might conclude that this client would panic and sell equities at a major loss at the market bottom. As a financial advisor, the best case may be to recommend that this investor pay off their mortgage and student loans before investing in risky assets. Again, no financial optimizer would recommend this strategy.”

“Post-Crisis Investor Behavior: Experience Matters,” by Joseph Rizzi, president of Macro Strategies LLC. “The financial crisis of 2008-2009 with its 50% drop in stock market value is seared into the collective investor memory—especially generation Y investors,” he wrote. “[Younger] investors are more focused on reacting to macro developments than asset fundamentals. The shift from ‘return on capital’ to ‘return of capital’ underlies the move away from equities into perceived lower risk fixed income by certain investor groups.”

See also this interview with Harry Markowitz

* I haven’t read this book yet. I’m summarizing this book review. I do this so when I want to know more about this topic and find this post I know which book I should go to for more.

Why I’d Love to See Graded Interaction Design Problems

One reason I love bouldering is that it’s game-like. No matter how much experience a climber has, we’re all at a certain level with certain climbs (they’re actually called “problems”) that currently challenge us. It’s like playing a well-crafted video game: the levels you’ve finished are easy, the levels ahead of you are frustratingly hard, but the level you’re currently on is a good match of difficulty for your skill level; and you can feel the flow.


I recently started learning a new programming language and I find it similarly game-like. Every new technique is a new challenge. Every new algorithm is a new challenge. The easy stuff is boring, the crazy theoretically stuff is frustrating, but the next chapter in my book is just right.

And like video games, in bouldering these problems are codified. So I can say, “I can do all the V0’s in this gym, and I’m working on the V1’s” and other climbers know something about my abilities.* Codified problems exist elsewhere too. Here’s some to help people improve their skills playing Go.

I’d love to see graded problems for interaction design. They would make it fun to solve problems, alone or socially, and communicate to each other our level of ability. “But Victor,” you might say, “interaction design problems don’t have a defined solution like a boulder.” Actually the boulders don’t either. People can solve the same problem different ways, but there are rules everyone must follow that give the game useful constraints. As long as you follow the rules and get to the top you’ve solved the problem. Some climbers are more elegant than others, and the same would be true in interaction design.

* The Moonboard is like graded problem-meets-Github, a single wall with over 800 bouldering problems contributed by various route setters.

Report: Financial planning = happiness

Pulling out some highlights of the Household Financial Planning Survey:

  • people who plan feel more confident about their financial decision‐making, manage to save more money, and feel better about their progress
  • only about a third (31%) of decision‐makers today report having ever put together a comprehensive financial plan. And just 35 percent of decision‐makers report having a plan in place to save for emergencies
  • Fed: devastating effects of financial crisis on the middle class: The median family… had a net worth of $77,300 in 2010 compared with $126,400 in 2007… wiping out nearly two decades of economic gains.
  • the crash of housing prices has been the single biggest factor that has reduced people’s wealth
  • only a third (34%) believes they will be able to retire [at 65, down from 50% fifteen years ago]. More than a quarter (27%) think they will not be able to retire before age 70, if ever.
  • 55% say “it’s hard for me to know who to trust for financial advice.”; 52% say “to me investing seems complicated.”; 55% say “I’m worried about losing my money if I invest it,” a significant increase from 1997 (45%)
  • half of household decision‐makers believe they “just don’t earn enough money to save regularly.”
  • American families today are less likely to be saving for their financial goals and taking steps to keep their family financially prepared.
  • The only area where families are more prone to save is toward a major purchase, like a new car, vacation, or home improvement project.
  • two‐thirds (65%) of decision‐makers say they follow a plan for at least one of their savings goals.
  • Forthoseathigherincomelevels,plannersputmoreoftheir income into savings than non‐planners and report having built greater wealth.
  • Among those in the $25,000‐$49,999 income category, 46 percent of those with a plan say they usually pay their credit card bill in full each month, compared with 26 percent of non‐planners.

Learning JavaScript, Day 4

I recently decided to re-learn programming. Because I already know HTML and CSS the web is a fast prototyping environment for me, so JavaScript is the logical language for me to learn. Besides,

  1. JavaScript has stood the test of time and the community has improved it a lot
  2. It’s now on the backend too
  3. There’s a ton of new/cool learning resources
  4. jQuery

At first I tried learning from a traditional book, from CodeAcademy, and by reading online. But I was only spending 30 minutes a day on it, and nothing stuck. It’s like my guitar teacher told me when I was 14: “When you start, you need to practice at least an hour a day to train your brain to think this way, or it’s not going to work.”

Four days ago I bought the excellent Head First JavaScript Programming book and have been making my way through a chapter a day, obediantly doing all the exercises with a pencil in the book and in code on the computer.

It feels great. My brain is so happy to learn something new and useful. After day 2 I was able to bang out a simple prototype of an algorithm that was too painful to do in Excel. I wish I had done this sooner.

2014 is the Year I Learn JavaScript

I’m at the point in my project where I need to prototype some software ideas. Doing it on the web is cheaper, simpler, and faster than prototyping a mobile app. And everything I need to do can be done on the front-end, for now. So I’m probably looking at JavaScript or Ruby on Rails, though there are other options.

I went looking to hire a programmer or a small firm to help me. I even wrote a simple spec to make the task official. But it turns out my task is not complicated enough to engage someone else.[1] And yet it’s beyond my HTML/CSS skills.

When I was young I taught myself BASIC on my Sinclair 1000, optimizing code to fit in 1K of memory. I kept those skills fresh in high school and college and even did a bit of Pascal work in grad school.

But that was a long time ago. Since then I’ve been busy learning about networks, then design, then business, then being a husband and father. Just about every year I would wonder if I should re-learn programming, if only to prototype my interaction design ideas. This often took the form of, “Should this be the year I learn Flash?” The good news is I didn’t spend a lot of time developing deep Flash expertise.

Why is 2014 any different? A few reasons:

  1. There’s increasing discussion about the pros and cons of unicorns
  2. When trying to fill an interaction design position recently I interviewed two actual unicorns. They really exist!
  3. I love to learn, and I feel a little tapped out of new things to learn in UX. Not that I know it all, I certainly don’t, but there’s nothing so new it stimulates my brain like it used to.
  4. Programming is such an exciting field these days. Stuff like Github, node.js, Rails, and non-SQL databases make it possible to make new things in new ways.

So, it’s time to learn JavaScript. More on that choice in my next post.

[1] And all the developers I talk to want to differentiate based on services. I hear from a lot of people that want to brainstorm, to partner on ideas, to think about strategy and process, and to measure ROI. For once I’d love to hear someone say, “All we want to do is write solid code at a reasonable price.” return to text

Reader Reviews #6/7: “eye-opening….thoroughly researched”

Why We Fail is available in eBook form at O’Reilly and all the reviewers there gave me 5 stars! Yay!

Paul in Austin writes:

The case studies alone provide an very interesting read to anybody who has some interest in technology in general.

Each case study has been thoroughly researched with plenty of references. The author also provides video clips to help the reader visualize the user experience of the discussed products.

In addition to user interface developers or designers, product managers and architects will also benefit from the methods for avoiding future UX failures described in the second half of the book.

BOTTOM LINE Yes, I would recommend this to a friend

Ken in Hoboken writes:

Too many books focus on success but I feel the best way to learn is by studying failures.

Prior to reading “Why We Fail”, the only other book I read along the same lines was “Billion Dollar Lessons: What You Can Learn from the Most Inexcusable Business Failures of the Last 25 Years” by Carroll & Mui.

I am an engineer, not a designer, but I often consult on projects where no UX person is hired, forcing me to assume that role in some fashion. I found this book to provide great insights that I would not have otherwise considered.

For example, as an engineer, I focus on meeting the user requirements, but the case study on the failure of the Microsoft Zune music player (Chapter 5) demonstrates how much more powerful the user experience is over the feature set.

I found it an eye-opening revelation in Chapter 9 that Microsoft’s many expensive failures is due to its practice of sweeping mistakes under the rug and never sharing experiences with their product groups.

Chapter 7’s discussion on ethics is a valuable addition to the material.

I highly recommend this book.

BOTTOM LINE Yes, I would recommend this to a friend

Trends in Design for Financial Services, April 2014

I frequently design financial services, and having just rolled off a project took some time to reflect on trends I’ve noticed. Here’s the first three that came to mind:

  1. Active participation by the affluent: Sometimes financial services companies assume the affluent don’t want to interact with computer services themselves. In reality, the affluent don’t want to feel like they have second-class tools compared to their less-affluent friends who use sexy mass market services. I first saw this in 2008 doing international research for the private banking unit of a giant bank and again more recently with an insurance company.
  2. Breakdown of client vs. consultant views: It used to be common to pour all the design work into the client-facing screens and rush through the consultant-facing screens. With the spread of smartphones and tablets everyone expects top-notch design, and consultants will work on their tablets alongside the client.
  3. Breakdown of mobile vs. desktop: When mobile was new a lot of attention was paid to what it meant to design for mobile. Now people expect services to just work on whatever device they’re using.

Good Design Can Make the Elevator Pitch Futile

I had a five-minute conversation with an angel investor last week and described the product I’m working on. His response: “Similar things are being done by bigger companies with giant marketing budgets, so you’ll need a very clever marketing idea to succeed. What is it?”

There was an uncomfortable pause. On one hand, I haven’t thought up any great marketing ideas yet and wondered if that was a hole in my plan. On the other hand, I was pretty sure this investor and I had very different perspectives on product development, but I didn’t have the language to succinctly express that gap.

I did understand what he meant. A few years ago I managed a large online dating service. We radically updated the design and added great features, but it was the online marketing that kept the revenue coming in. Why? I believe that while the design was good, the product wasn’t positioned to differentiate it from the competition. By contrast, if you design a product that’s different and more exciting than the competition, like the Anki DRIVE, there will be a lot more free media exposure and word of mouth to complement paid marketing.

My downfall, I think, is that I was trying to tell this investor about the product rather than show him. If my new and improved positioning is a result of product design, I need to show the product. For example, if I verbally described the Anki DRIVE as, “a racing game that combines an iOS app with physical race cars” that’s sounds mildly exciting. Watching the video is so much better…

Agile Ain’t Wishy Washy

As I write this there’s a group of about 15 developers and designers standing near my desk in a heated but constructive argument about how to check the design is right before the code heads off to QA.

Occasionally the dichotomy of agile vs. waterfall is raised, and sometimes “agile” is used as a euphemism for “flexible” as in, “well, there was an update in design document X, and we’re agile, so you should be able to integrate that.”

If there’s one thing I’ve learned from doing agile it’s that agile ain’t wishy washy, i.e. it’s not really some sort of flexibility nirvana. Any software development process relies on firm lines drawn around what, when, and how the work gets done. Otherwise, shit don’t get done.

Yes, agile is better at responding to change. But it is effective, somewhat counterintuitively, because it responds to change with a high degree of rigidity. For example, if the stories aren’t written in a way that makes it clear to developers how to code a feature and how to test it, it doesn’t get accepted into a sprint. Once stories are accepted into a sprint nothing else can start until the next sprint. And so on. When I first encountered all this rigidity I thought the developers were acting like self-involved prima donnas. Actually, they’re just enforcing the rules that make the process work.

Agile responds to change, not wishy washiness.