How to design stuff that matters fast – Eewei Chen


Great session this afternoon with Eewei Chen as he walked us through some great rapid prototyping techniques for ideation.

Step 1: Create an empathy map / persona

Fill in the various sections creating a persona for the person you are building the app for.

The categories are:
– Behavior
– See (motivations)
– Do (features)
– Say
– Feel

Step 2: Map features – what do I want to do?

Take the features you mapped from step 1, and start flushing them out down here.

Step 3: Can I use it?

Now walk the use through using your app made up of your highest priority most valuable features.

Step 4: Elevator pitch

Step 5: Pitch it!

Special thanks to Eewei Chen for hosting such a great session. Eewei was prepared, he had the materials, all the personas were nicely laid our around the room, and you even pre-filled in our elevator pitch butcher paper.

Great session.

Thanks to Ariadna Font and Adrian Smith for being awesome partners.

I am already thinking about how we are going to spend our millions once we build it 🙂


Sharpen your saw with newsgroups


Today, in the agile community, there are dozens of newsgroups spanning many topics. Here are a few interesting ones I regularly track and follow:

Extreme Programming:

Domain Driven Design

Lean agile

Lean development

Agile testing

Agile usability

Do a favorite newsgroup? Do share.

YAGNI vs Usability

Leave a comment

YAGNI (You Aint Gonna Need It) is a reminder to all who write software not to over engineer your designs, keep things simple, and add complexity only when necessary.

Usability, on the other hand, is about improving the users’ experience with the software—additional architectural complexity be damned!

YAGNI vs. usability are two forces that sometimes bump on agile projects.

This post looks at a simple example of how these forces can conflict, and how teams can help find the right balance for their project.

Keeping it simple

My last project was a web based application that showed users at a construction site which roads were closed on any given day.

One of the stories was called display road closures and the first version of the story looked something like this.


With a simple date based search at the top of the screen, the user simply enters the day they are interested in seeing road closures. They hit the search button, and the map refreshes showing which roads are closed, along with the search results at the bottom.

Delighting your customer

During development, my partner came up with a better way to visualize which roads were associated with which permits. Instead of simply displaying road closures in red, why not give each road closure a different color. And while we are at it, why not make the search results selectable—so that when the user clicks on a road closure at the bottom of the page, the associated road on the map becomes more bold and visible to the user?


I thought his idea was great. It required a fair bit of custom JavaScript, which would add some complexity to the UI. When asked how long he thought it would take, he said about an hour. Thirty minutes later it was done and integrated into the code base much to the delight of our customer.

Playing the YAGNI card

Deciding whether or not to implement this feature was a no-brainer. My partner had the necessary JavaScript chops, the cost was minimal, and our customers loved it.

But what if the trade-off wasn’t quite so black and white?

What if we didn’t know JavaScript?
What if the improvement, compelling as it was, was expensive to implement?
What if making the necessary change did require some heavy architectural lifting?

How should teams balance the desire of keeping things architecturally simple, with a desire to delight their customers?

See how you are tracking

Before getting all hot and bothered about whether to invest in an enhancement, or add a new feature, check and see how your project is tracking.


If your team is struggling to deliver stripped down, spartan versions of your customer stories as is, spending additional time on UI improvements is a luxury your project can’t afford.

On the other hand, if the team is on track, and the customer is happy with what they are getting, there may be a little wiggle room to make a few usability enhancements here or there.

And if your team is delivering ahead of schedule, all options are open. Go ahead and try the 13 shades of blue.

Know your project context


Every project is different. And not all have the same requirements around things like usability.

For some projects, a few fields and a submit button are more than enough. For others, nothing less than an aspirational experience will do.

Knowing ahead of time what your project requires, and how your customers feel about stories being ‘good enough’ will tell you whether you need to spend more or less on usability and the experience of the user. Putting working software into your customers’ hands sooner rather than later will serve you well.

Don’t be dogmatic

While YAGNI is certainly a sound architectural principle, like any sound principle it can be taken too far. When YAGNI is repeatedly used as a trump card to prevent improvements to user experience, it can upset team members, and cost the team an opportunity to better serve their customers. Not all usability enhancements need to be expensive, and sometimes the smallest of changes can make the biggest of impacts.

Like most things in life, it comes down to striking the right balance. The only way you’ll find out is if you build something, show your customers, and get some good solid feedback along the way.

Until then, you’re just guessing.

%d bloggers like this: