Epicenter software design: Building features from the inside out

Epicenter software design: Building features from the inside out Jason 06 Apr 2006

26 comments Latest by phil jones

We’ve advocated epicenter interface design for a few years now. Every project we do reaffirms our belief that it’s the best way to design the best UI. It forces you to focus on what matters most first, what matters second-most second, etc. When you nail the core the majority of the UI value has already been delivered.

But interface design isn’t the only place to focus on the epicenter. Designing the epicenter of a feature first is also the best way to design software.

We’re currently working on a calendar for Backpack. Adding a calendar to Backpack is the #1 requested feature by a long shot. We need it bad too, so we’ve finally decided to tackle it.

When you design a calendar there are a lot of places you can start. You can work on iCal subscriptions, color coding, email reminders/alarms, dragging and dropping events, subscribing to other people’s calendars, attaching Backpack pages to calendar items, etc. Even the simplest calendar has a rich feature set, so be careful not to confuse enthusiasm with priority.

But, what’s the epicenter? It’s the events themselves. Without those you don’t have a calendar. You can have a calendar without color coding. You can have a calendar without alarms. You can have a calendar without dragging and dropping. You can have a calendar without displaying a mini calendar of the next three months. You can have a calendar without a lot of things. But you can’t have a calendar without being able to add events. That’s where you start.

The feature set epicenter is also where you’ll find most of the value. Once you’re able to add events to a basic calendar, you’ve created 80% of the value. You can use it right now. Everything else is nice to have, but adding events to a calendar is a must have. Without that, you don’t have a calendar.

So, if you’re wondering where to start on a new feature or a new product, discover the epicenter. What’s the one thing it needs first before it needs anything else? What’s the core? What’s the absolute essential bit of functionality that must exist before anything else can exist? When you’ve discovered that you’ve found the epicenter.

26 comments so far (Jump to latest)

AW 06 Apr 06

Jason totally agree. The example really helped in explaining epicenter.

It seems that finding the epicenter is the *REAL* challenge in the entire UI. Since once you find that, everything else is useful or pure bloatation. Thus - how do you guys know what to keep and what to leave out after you nail down the epicenter?

JF 06 Apr 06

Thus - how do you guys know what to keep and what to leave out after you nail down the epicenter?

We start using what we’ve built the moment the epicenter works. Then we can get a feel for what we need next. And once we run out of things we *really* need, we’re good to go for v1.

There will always be things we’d *like to have* but those things can wait for later.

Jon 06 Apr 06

I agree, and I work this way too. But, if adding events to the calendar is 80% of the value, what percentage is actually viewing the events? i think that’s pretty important too, no?

nate 06 Apr 06

There will always be things we�d *like to have* but those things can wait for later.

But I think the question is, where do you draw the line? iCal subscriptions might *seem* like a required feature, and to some they might be (vis-a-vis the deal-breaking lack of pony integration), but it’s not essential to the operation of the calendar itself.

I know there’s not a hard-and-fast, one-size-fits-all rule for this, but where’s the line between usefulness and bloat?

xian 06 Apr 06

This is an excellent observation. Too often the core functionality of a service or feature takes a backseat to some whiz-bang feature.

Question: Do you ever nail down the epicenter (as you call it) and then when the time comes to add a nice-to-have feature, find that your core data model doesn’t permit it?

RS 06 Apr 06

But, if adding events to the calendar is 80% of the value, what percentage is actually viewing the events?

After you can add events, viewing those events is absolutely the next most important thing.

What do you think comes next?

But I think the question is, where do you draw the line?

Everyone has a different answer to this. And that’s what makes different company’s products different.

That happened to us in Basecamp. When we launched, the model had two kinds of parties: clients and firms. Projects could only have one of each. We later decided to add the idea of “contractors”, and those were hacked on to the ‘client’ party.

What we really needed was a bona fide third party, but the initial model didn’t allow it. Eventually we reworked the model itself to allow any number of companies to join a project.

We’re glad we started with the 2-party system, even though we changed it later. The 2-party system was easy to understand and it applied directly to our needs. It continues to be the 80% case, so we’re glad that Basecamp lived under that assumption in it’s more formative days.

Tomas Jogin 06 Apr 06

Doesn’t everybody work this way? I mean, without developing the epicenter of a feature first, it’s kind of hard to do the other stuff. How do you add iCal subscription of events, before there are any events? It just makes sense to start there first.

Jake 06 Apr 06

Tomas, just because it makes sense, doesn’t mean that it’s the what always happens. Often, it’s the most obvious things that are over looked… it’s kind of like trying to find the ketchup in the fridge…

Dave 06 Apr 06

Yeah, I’ve seen a lot of designs where they start with a user authentication model, then go to the actual interface design, and try to fill in holes with the actual model. And without fail, when they get to the epicenter (as 37s is calling it), they have to go back, change the user authentication model, change the interface, etc.

I’m with Jonas too. I started developing my own calendar app because I hated the other ones out there, and I had the same thought. Things don’t have to look like they always do. I was not in a creative enough mode to actually come up with something perfect, but I do believe that a great online calendar will not look like the paper ones, and the person that figures out what is right will come out way ahead of the market. Please, don’t make a paper calendar clone, OR an Outlook clone. I’d be willing to bet you don’t even have to port to iCal if it’s slick and quick enough for people to use anywhere (cellphone interface anyone?)

Good luck, if anyone can get it right it’s you guys.

Eric 06 Apr 06

I like the way that Gilles Satge tackled the event calendar. I worked on a project recently where we had a similar vision of how it would work. The problem we have is that we don’t have time to think about the details and implement them. We have pressure to do things on a grand scale with lots of chrome, but not time to actually implement our ideas so we end up settling for something that none of us are proud of. Time constraints suck!

We have pressure to do things on a grand scale with lots of chrome, but not time to actually implement our ideas so we end up settling for something that none of us are proud of. Time constraints suck!

No, time constraints are great. What sucks is that you aren’t being allowed to focus on the real problem.

str eet 06 Apr 06

Freaky! I really hate reading ‘Me Too’ comments, but I just walked out of this same meeting only a few hours ago.

A group of developers had purchased a canned calendar component from a vendor and had integrated it into one of our clients sites. The calendar was a visual rip-off of Outlook 2003 with nearly the same feature set. During the meeting the developers gave a 20 minute demo and gushed over all of the features with irrational exuberence. Although the details are still unfolding as to whether the calendar stays or goes; our client went beserk - “How much has this cost me? Show me where I requested this? All I wanted was an event list! How hard is that?”.

The developer’s response? The old standby, “Sometimes users don’t know how to ask for what they Really want”.

AM 06 Apr 06

Why no colaborative calendar for Basecamp?

Danno 06 Apr 06

Personally, I think adding events is the singular most annoying part of Calendars online or real. I *just* want to view the events. I’d LOVE it if events could just be captured from all the stuff I was working on (like pulled out of text I had edited), and then non-obtrusively presented to me for correction (I don’t expect perfection yet, just good guesses).

That probablly doesn’t fit with the type of code you guys usually try to write, but I think it does fit with the “less” aesthetic in general.

Buddy Lindsey 06 Apr 06

I think that is a great example of what to do. To often I get caught up in features when thinking out a peice of software or a site and never seem to come up with the “epicenter” of the project.

I like the terminology that you used for it that will greatly increase how I think about a project.

Now for my projects i can add to it Epicenter as the main focus.

Great tip

dracula 06 Apr 06

how is this not obvious?

Dan Glegg 06 Apr 06

Mechanically speaking, this method is often the _only_ suitable one. You can’t colour-code events without the events themselves. You can’t specify interesting relationships between events without the objects themselves working in some basic form.

Releasing with the function in a basic form is good too. Adding a bulk of features/interface changes can terrify users whilst a gradual trend towards a new way of using your software will usually transition your users almost completely painlessly.

Scott Sehlhorst 06 Apr 06

Great post Jason - this is basically an application of Kano analysis to requirements, combined with a prioritization strategy.

Kano groups requirements/features into 4 buckets: Must-be, Surprise and delight, more is better, better not be. We use the first three categories to drive classification and prioritization of requirements (and thereby features).

We completely agree that must-be requirements must be in the first release, and suggest that 80% of the effort should be applied to them in the first release. That’s definitely consistent with 80% of the value being in the epicenter features.

Vishi 07 Apr 06

My design for a calendar would be something like event boxes shaped like the number 7. Future events on the top, completed events on the side. Events flow and and fall down the current date and time as time passes. The area at the center of the angle for the event info, etc.

Des Traynor 07 Apr 06

Some comedian, whos name escapes me at the moment, had a great one liner

You can’t have everything, where would you put it?

Thats exactly why I think you should design Interface First, look at the space you have, see what can go where. Doing things the other way around, you run into trouble pretty quickly, the buttons start getting smaller to accomodate everything, the pigeonhole principle kicks in pretty quickly. Your sidebar now doubles as your navigation and your help. Basically you end up with design akin to the space under my bed. I just keep pushing crap under there, wondering will I ever use it!

Rado 07 Apr 06

And the other 20 % is taking events OFF the calendar. Right ?
You have to have spare time once in a while