Madera Labs | 5 Reasons Your Web Development Process is Broken

5 Reasons Your Web Development Process is Broken

Weekly User Experience Tips
Free weekly recaps of our blog, straight to your inbox. No spam, we promise.

If you’re like most people, your web development process is sadly broken.  Sorry, but it’s true.  I’ve seen this same story play over so many times, it’s sickening.  The same backwards web development process, applied time after time, resulting in failed startups and disappointing results.

Here’s the problem: you put engineering first, and rarely (if ever) consider design to be an important part of the phase.  You think it, build it, then ship it.  At best, you build it, slap some aesthetics on it at the end, and kick it out the door.  I’ve got sobering news for you – if you follow this process, it’s broken, and it’s causing you to waste loads of cash.  Here’s why:

  1. You don’t know what you really want. You’ve come up with a great idea for a product and have decided to build it.  Instead of testing prototypes of the idea or working through iterations, you kick a rough version out the door.  ”See how the market reacts” is the mantra.  Here’s a wakeup call: this is a terrible idea.  By immediately building, you’re cementing assumptions before ever having a chance to test them.  By engaging in an intentional design process at the beginning of the process, you’re able to run quickly through iterations, reset the problem space and actually find the right product.   Your first idea isn’t the right product.[Don't confuse this with Agile.  Agile is not about releasing without design, then iterating to fit the product into the market space.  Agile is about starting with design at the core, and releasing ever-increasing feature sets and iterations to test market acceptance and interaction design.  Agile without design is a money pit.]
  2. You don’t know what the market wants. A lot of companies fail.  None of them released a product thinking “This probably isn’t what the market wants.”  Every company releases a product expecting success – to do otherwise is true insanity.  Why then, do you assume you know what the market really wants?  Placing a design process at the beginning of your development cycle helps you think conceptually through the problem space, combining research, ethnographic observation and other inputs that ultimately result in a much less risky offering to the market.  Again, you have to find the right product first.
  3. You’re building for a computer, not a person. When you jump straight into engineering, you’re far more likely to develop the architecture and experience of your product according to the needs of the computer, not the user.  Think about it: you come up with an idea, build a database or three, and start putting together the necessary inputs and outputs to allow a user to interact with the data and complete a task.  Every bit of that is based on what the infrastructure needs, not the way a user thinks and experiences the product.  The result is a product that feels clunky and thrown together, and frankly, dehumanized.  Intentional, user-centered design provides a framework for development that’s driven by human needs, not computer needs.
  4. Engineering-first costs more. Ironically, not carving out budget for design at the beginning of a project ultimately results in more cash being outlaid in total by the end of the development cycle.  The reason?  Rework.  Like building a house without carefully constructed blueprints (or blueprints sketched out by the guys who are laying the brick), you’re doomed to have to tear down pieces and rebuild once those early established assumptions come crumbling down.  As #1 and #2 pointed out, without intentional design at the beginning, you don’t fully understand the problem space, which ultimately leads to rebuilding parts of the product again later.  In addition, wrinkles in the plan appear during production, leading to missed deadlines, pissed off investors and disappointed customers.
  5. You miss the big picture. To use an architecture analogy again, engineering first is like building a house and digging out the hole for the foundation as you go.  Yes, you’ll get it dug out, but it’ll look like hell and won’t work well with the rest of the lot.  Approaching your project from a design perspective first forces you to think about the entire interaction strategy – how people will enter, exit and go between the touchpoints with your company and product.  These moments are critical.  Consistency across this experience is what breeds loyalty and goodwill, whereas drops in the experience expose an undercooked strategy.  While you can bolt on the extensions to the experience after or during engineering, the work required to assure a tight fit will ultimately cost more and take more time than an intentional design process at the outset.

Understand this – when I talk about a “design process”, I don’t mean 30 minutes on a whiteboard.  I know you’ve done that.  What I mean is an extended period of time working through assumptions, iterations and form with the intention of revising the product before development.

If you don’t believe me, look at any other industry.  I’ve used the architecture analogy here, but the same goes for physical consumer products, automobiles, boats and anything else that is produced.  Every single one of these industries places a lengthy design process before engineering, in order to assure market fit, lower costs and reduce risk.  The web industry is the youngest production industry right now, and as such, has some bad habits.  Don’t overlook these bad practices and blow them off as the web being different.  It’s not.  An intentional design process will always result in a better product.

The next time you start a project, stop, build design into the budget and bring in a designer to help out (unless you have designers on staff, of course).  Design and engineering are symbiotic, each needs the other.  Don’t create an anemic and malnourished product that is fed by engineering without a dose of design.

[Don't take this as a pejorative stab at engineering.  To do so is to be naive.  In fact, it's the opposite.  Engineering provides an irreplaceable service in the production of products, and thoughtful, considered design increases their chance of success.]

[And no, you can't bring design in at any other point and expect to have all the benefit.  Design has to be involved at the very beginning, or you risk wasting time and money.]

  • http://www.robbennet.com/ Rob Bennet

    Wish I could print this out and staple it to every developers head.

  • http://twitter.com/amberweinberg amberweinberg

    I don't think it's the developer's fault, it's often the company who hires the developer and then decides to push the website out without any testing. A dev rarely works on their own, they just do what they're told ;)

  • maderalabs

    You're right Amber, it's often a corporate/company process that's flawed, and I think product managers and others responsible for overseeing development need to rethink how they're developing interactive products.

    For that reason, I don't want to sound like it's UX vs. engineering – both need to happen, and either without the other leads to a poor product. It's the *process* that needs to change, and that responsibility lies in whoever's hands are controlling it.

    Now, with that said, I *have* seen instances of startups and other small products be driven solely by a team of developers, to the exclusion of design. The reason for that is simply the capability to bring the product to market. Developers *can* get a product to market without designers, whereas designers cannot.

  • http://twitter.com/saqibsarwar saqibsarwar

    very nice read.

    Point 5 is really great, we really think that spending few minutes on white board and laying out main flows is all about desiging a product. but you are right it is not. Revisiting the problem and rethinking the assumptions is really critical to create a successfull product.

    From a small web application point of view what is your recommendations about testing assumptions ? I mean, how can we test our assumptions before going into real engineering ?

  • http://breakingd.com/ mcdumler

    Great read as usual. As a small design company, we make it a point to start with design and the customers first building around those key items. In an earlier posting you talked about design as building a house from the top-down, further illustrating that by asking what a “typical night in your house would look like.” This principle I believe is often missed as discussions of widgets and technical aspects seem to come first. Thanks for another good read.

  • maderalabs

    For a small app, you can quickly test execution and design assumptions by doing some quick user testing. Paper prototyping or even some conversation with the potential users will help you to evaluate your decisions, and can be done quickly and cheaply.

    Barring that, force iteration into the process. Tell the team to generate 10 distinctly different designs in the course of an hour (or even better, 30 minutes), as sketches, and spend an hour talking through the differences in the designs. As the group works through designs, they'll start to naturally iterate over rough spots and some of the incorrect design assumptions will reveal themselves fairly naturally.

  • maderalabs

    Thanks for the comment! You're right – often the conversation slips to the technical execution details first: widgets, colors, platforms, etc. Part of this is tangibility – those items are easy to understand, feel, see and implement. Naturally, the group tends to reach for that kind of solid ground first, but never steps back to check implementation against design strategy. Glad to hear you're making a conscious effort to start with a user-centered design process first!

    Thanks for reading!

  • http://breakingd.com/ mcdumler

    Even though a client will often try to go to that “tangible” starting point as you said, we really try to establish a philosophy first behind the clients brand, product, or business. It has proven difficult at times, but I think the pay-off is well worth some of the struggle.