I can’t stress enough the importance of having a solid design strategy for your project. Have you ever been worn down by endless scope-creep? Or been pressured to agree on an overloaded specification with a tight deadline? Ever discovered too late that what you’re building doesn’t really satisfy the requirements of the client’s business or users? I have.

When James, Nick and I started working on our platform for musicians we generated reems of design concepts as we thought through the possibilities for our app. In some ways we did well in reigning-in our imagination, pulling back on the most complex and nice-to-have features. But as we’ve continued to develop our product it’s become obvious that we’ve still left too much in the mix, and are now commenting out swathes of hanf-baked code in order to keep the app simple and launch-date achievable.

The google way

For our work on Muxster we’ve taken some inspiration on design strategy from the Google Chrome for Mac team. With all of it’s projects Google always puts the user first. They believe in user-centered design so strongly that they’ve written it into their company principles, and you’ll agree that it’s a guideline that’s served them well. Like us the Chrome team are in a position where they want to ship their product as quickly as they can but still deliver a great user experience.

They plan to achieve this by launching the app early, but with some highly visible feature omissions. The first versions will include a functional, quick and reliable web browsing experience but omit major features such as printing and browser plugins. Google has decided that it’s better to limit their team to delivering a few features really really well rather than a slew of features in a slipshod manner. They’re putting “half, not half-assed” into practice.

Our plan for beta is to have a very polished main-window experience with large, obvious features missing instead of a broad, partially-implemented experience where everything feels shoddy and half done. We feel this is a much better trade-off as it makes it very clear what is done and what is not. As a result, as new features are added or bugs are fixed, anything that doesn’t look finished/polished stands out like a sore thumb and gets immediate attention. In the other world, it would blend into the general suck and we’d never tell when something regressed. – http://dev.chromium.org/developers/how-tos/mac-detailed-status

It’s straightforward to see how this strategy will work for the Chrome team. The initial beta release will mostly be downloaded and installed by early adopters. These are the kind of people who’ll already have two or three browsers installed on their Mac and will overlook the lack of printing for the chance to get their hands on the next big thing. If the core browsing experience is compelling enough this group will happily tell their family and friends about Chrome when they feel it’s ready. So when printing eventually makes its way into the stable version the early adopters will urge those they know to give Chrome a try.

Our plan with Muxster is similar. We’ll release a cut-down version into the wild and observe the reaction. It’s not worth keeping the app to ourselves as we continue to pile in features. Especially as we expect many of the features we’ve already built will be removed from future versions as we continue to observe the results of usability testing.

What about difficult clients and the quest for billable-hours?

You may agree that I’m talking some sense here, but if you do any client work you’ll surely want to remind me that “the client gets what the client wants”. That’s a fair point. It’s difficult when stakeholders are fighting hard for their piece of the project and their vision of what it will look like.

Yet, it’s wrong to just deliver simply what’s asked of you. In most cases, if your you’re taking design direction directly from a client, relationships will be strained and your project will almost definitely fail.

Some projects are complex, with many moving parts and difficult problems to solve. Some project objectives are complex, and this where it’s necessary to understand and accept that they may not be achieved in one development cycle. Successful projects need design strategy, honest planning and achievable development cycles.

Design strategy tools

I attended a great workshop at UX London by Peter Merholz of Adaptive Path. He was presenting a condensed version of a full day workshop from UX Week. The focus was on the cornerstones of good design strategy i.e. focus, definition, customer value and project scope.

Peter explained some of the design strategy tools Adaptive Path use when working with their clients. The tool I though was most valuable was a method to prioritise opportunities (i.e. features, etc.).

I’ve mentioned the folly of promising stakeholders everything they want. This tool offers a way to generate an achievable project scope that everyone can get behind.

Prioritising opportunities

Within your formative work you and your stakeholders will have generated concepts and ideas about how you may achieve the project objectives.

It could be that you’ve decided that you could build a social web app which leverages collective intelligence, virility and includes a mobile version which features location-based functionality and some augmented reality magic.

This is of couse a joke. I hope there isn’t a team out there that would actually try to build all of that in one development cycle. We need to prioritise. We need to understand what’s actually important and what’s viable.

Availability opportunities will vary depending on your project. In the example Peter gave we were looking at higher level opportunities for a hotel chain; increasing repeat visits, reducing operating costs and increasing revenue per customer.

We’ll start by collecting opportunities together and rating them on a scales of importance and viability. We’ll allow ourselves 18 points to spend on each column. These points represent the effort we have to spend on the project.

Opportunity	Importance	Viability
A. Browser-based web app	5	5
B. Collective intelligence functionality	3	3
C. Social and viral functionality	4	5
D. Mobile version	2	2
E. Location-based functionality	2	2
F. Augmented reality functionality	2	1

With this table we’ve articulated our understanding of what’s important for the project and also thought about what’s actually viable. When using this method with stakeholders you’ll appreciate the points limit, there’s only so many points to play with so they can’t give each opportunity 5 in both columns!

If we plot our results out on a chart we can use to help us visualise where we should focus our attention.

The slices across the chart basically visualise the what your must build, what you could build and what you shouldn’t really bother with just yet. Here, A and C are must haves. B is a maybe. While D E and F are not worth the time at the moment.

This is only one of the first steps in defining your design strategy, part of the focus stage. From here your’ll need to look at what features will go into each of the prioritised opportunities and develop a product evolution plan. What we’ve done is look top-down at what’s most important and viable, but you shouldn’t take your top opportunities and expect to deliver them all in one development cycle.

The next stage of developing a product evolution plan will allow you to spilt you features into discreet development cycles. Perhaps you’d choose work on the web app first, then in the next cycle get the first mobile version off the ground and in the third cycle add or remove features from both. With each release moving closer to achiving the vision of the initial strategy.