Those dreadful early decisions

One thing that is widely known already, but deserves to be restated for everyone that thinks they understand it is that the quick and dirty, seemingly meaningless decisions that you make when you first start designing/building a website are going to be greatly magnified throughout the life of the company. I run into little things constantly that I wish I’d just thought through a bit more carefully in our early stages that would’ve been a quick fix originally that are now an annoying problem to resolve because it’s grown overtime.

I think there is a delicate balance, especially in the earliest stages of an application, between speed and just getting something out the door (there definitely is such a thing as over-analyzing a problem) and thinking the problem through and looking at the long term perspective to prevent a series of “gotchas” in the future. I certainly still haven’t mastered this balance, but what I am learning is a couple of (now obvious) clues as to what should be more thoroughly thought out and what should just be cranked out and refined as time goes on. So what are the clues?

  • Anything involving the database should be thought out very carefully…and then thought out again. Changing the database schema after you’ve grown a bit is certainly possible, but is a nightmare of a thing to do. The application often ties so tightly to the database architecture that even relatively minor changes can be a major pain to implement down the line.
  • Core processes (anything done many, many times on your site) should get a bit of extra foresight as well. Anything that happens constantly will generate large amounts of data which is always hard to fix in the future. Also, if it’s not well thought out you’ll probably run into scaling issues and the like down the line – a little time spent early on can save you from a nasty bottleneck 6 months later.
  • Data collection and standardization definitely should get some extra cycles. Exactly how you store url’s (to normalize for inconsistencies) for example is something that is much easier to solve once, carefully, than to have to modify several times to ensure accuracy down the line. Any time you end up collecting large quantities of data, you want to be 110% sure you figure out the way you want to store it (including what it will be down the line). Having to modify large collections of data multiple times is murder on your server and extremely risky (playing with data always is). Save yourself the stress and figure this out from the get go.

  • In contrast, the UI of the site is something that should be cranked out relatively quickly. I’m sure some will disagree with me on this point, but what I’ve found over and over again is that what we think is the best way is never really the best way. The UI is something that should be constantly tweaked and iterated over to give the user the best experience possible. It’s very, very hard to plan out the best possible UI on day one, but your users will help you figure this out along the way. Let them, and don’t waste all your time on this up front since you’re just going to change it every 1-3 months anyways.
  • Formatting and copy (text) of the site/product should be done extremely quickly early on. Obviously you want to make your product usable from the beginning, and appropriate, understandable text is important to that, but this is so frighteningly easy to change that it’s just not worth all your focus up front. Instead, make sure it’s clear enough that it’s usable and then build off of the feedback of your user base a couple months in to clean it up and refine it.

So a quick summary would be that anything involving data, the database, or a core process should be handled with great care, but things like copy text and UI should be handled more iteratively instead. When phrased like this it seems completely obvious, right? Yet somehow in the moment it just doesn’t seem this cut and dry. Hopefully this will help someone else out there to make sure they spend their time on the right early decisions and prevent some headaches down the line.

This entry was posted in General. Bookmark the permalink.

9 Responses to Those dreadful early decisions

  1. Pingback: Intense Debate on TWiT | Management Newsfeed Update

  2. jon says:

    I respect your point Darrell, but in general I just feel like the UI elements are considerably easier to iterate on. Often you really need to iterate on these and we’ve run into several cases where we spend tons of time thinking through the initial design/layout and then in 3 months we’ve got a completely new feature that doesn’t fit into it nicely or we were wrong in our assumptions of how it would be used. I don’t mean to minimize the importance of these issues (UI/design), but I think often they almost require iterations instead of a long bit of planning in the earliest stages.

  3. tmarkiewicz says:

    Excellent post Jon. Database design is especially critical in the initial stages as it is so difficult to make relatively large changes later. Unfortunately, I often run into the analysis paralysis trap on the design. When you keep thinking how important this aspect of the development is, you can spend too much time trying to perfect it. A good balance is always needed.

  4. tom says:

    Nice post…totally agree, Jon!

  5. It is difficult for me to understand but I know making decisions is not easy. Most difficult part are Data collection and standardization. They take a lot of time and you may need to rethink a lot.

  6. ktbug8596 says:

    well, I hope all your other readers understand this…. because I sure don't!!! Go back to writing more posts I can understand!

  7. " In contrast, the UI of the site is something that should be cranked out relatively quickly. I’m sure some will disagree with me on this point, but what I’ve found over and over again is that what we think is the best way is never really the best way."

    Jon, count me as one to disagree with you on this point. Let's set aside the graphic design of a UI for sec and discuss the "other" elements of the user experience – information architecture and interaction design. These need as much forethought as does a DB schema. In this age of RIAs, interaction design has a huge influence over how the user will perceive your product's brand. IA will have an impact on form elements, which does impact your data model. Understanding the impact of both IA and interaction design trickles into decisions about how you manage "state" and structure your data calls. My team has had to rescue several train wrecks in the past year when product teams took the "we'll polish the UI later" attitude.

    What I recommend is to perform lo-fidelity prototyping of the interaction design and IA prior to investing the effort to make pixel-perfect UI comps. A good BA can crank this out in Visio. Or a good designer can use the latest features in Fireworks CS4 to create clickable PDF prototypes to show to potential customers. Heck, you can even have a designer hand sketch the prototype.

    BTW – your other points are spot on!

  8. win now says:

    Go there guys buy prescription medications that are used to relax your body, relax your muscles.

  9. A well researched site, I’ll link to it from my site thanks