A Changing Paradigm in Web Development

The Drivers

I have wanted to write an article like this for a long time. For whatever reason the stars never aligned to make it happen. Either I was too busy or I'd observe some new industry changes that modified my perceptions just enough to hold off from putting virtual pen to paper. I was very conscious of the fact that what I was observing were potentially fads and not trends, short term shifts instead of quantum leaps, tremors as opposed to quakes.

Now I'm sure, there's no going back. I believe that any web or digital agency (or indeed even merchant) stuck in the old ways will simply become more marginalised to the point they cease to thrive and will in all likelihood wither and die. These changes seem subtle but they have a dramatic impact on project workflows and ultimately, outcomes.

For the most part, these changes have been driven by business requirements. Namely to innovate quickly and respond rapidly to market changes from a digital perspective. This need for businesses to bring pace to their digital operations has shortened web development timelines dramatically.

Long gone are the days of 12+ month web development projects - businesses change too fast for that, to the point that projects of that duration lose relevance and context by the time they go live. As a result, even the most complex projects often have timelines of 6 months or less. This puts immense pressure on both the merchant's internal delivery team but also the partner(s) tasked with delivering these projects.

This article is meant to be a wake-up call to those that work in this space - whether merchant or agency side. Times they are a changing and the pace of digital is speeding up. We all have prepare for and deal with this reality and find creative ways to make it work for us.

The History

I have been able to observe, take part in, architect, consult on or manage around 20 major web projects and dozens of smaller development, integration and marketplace projects over the past 13 or so years. These have spanned the gamut of lead generation and eCommerce sites with a shift towards content & data driven eCommerce in recent years. This has provided me with a bird's eye view of how they typically flow.

Projects often follow a similar pattern something like this:

• BRD (Business Requirements Document) Creation

Typically created by the merchant/client if they have the capability to do so or in tandem with a partner if not. This usually outlines the business drivers/case for the project, it's primary goals/outcomes to be achieved and primary functional requirements (the site must be able to do A, B & C to support X, Y & Z business operations/functions).

A BRD is often not created/supplied, depending on project scale, budget and merchant complexity/size but it is very helpful when it is. The project scope/specification often acts as the BRD on smaller scale projects.

• Solution Specification Creation

This can come before or after the design stage. Typically the agency partner will try and learn as much about the business as fast as they can so they know what needs to be spec'd into the project at this point.

This document defines in detail HOW the website will function to fulfill the business requirements, as well as non-functional requirements like 3rd party integrations and training & infrastructure. This may be supplemented with a technical specification document that is aimed at the development team and is more technical in nature.

• Wireframes and Core Creative Design

This can come before or after the specification stage. In this phase a design brief is collected (with brand/design guidelines provided if available) and the site is first mocked up with no creative/visuals via wireframes.

These are outlines of general functional & content areas (taken from the functional spec) and what they represent. Once that is defined then core creative content, elements & imagery are created and layered over the wireframe areas statically, usually in flat PSD files. The project spec is then revised with any changes from this phase as required.

• Technical Development

This is where the site is actually built and integrated with all 3rd party systems. The flat designs are converted in HTML, CSS and Javascript files and then integrated into the base platform if there is one. Customisations are built out and systems are integrated and tested.

• Testing/Quality Assurance (QA)

The full solution is fully tested and bugs resolved. The site should be proofed at this stage and design integration reviewed. Responsiveness is also tested on various device and browser types.

• Training & Content Loading/Enrichment

The platform is made available for the merchant to train on and load their content into, from product information & images to information pages and contact information.

• User Acceptance Testing (UAT)

This is where the merchant puts the solution through its paces to ensure it looks and functions as expected. Any final changes or bugs are resolved here.

• Infrastructure Configuration

The live site hosting/infrastructure is established and configured. The site is loaded into this infrastructure and tested. Obviously this phase is not required in SaaS/Cloud platform scenarios.

• Launch

There is a launch process that is followed and the application settings are adjusted to live status, culminating in any DNS changes made to point to the new live website.

The above sounds pretty reasonable right? I mean it covers all the major bases and gets the job done. Well, yes, to a point. It is fraught with difficulty and delays however. First, you can't divorce look and feel from functionality so there are significant delays in marrying the two at the point creative is generated because the designers may not know what they are designing around.

There is often a lack of platform knowledge by the merchant by the time it comes to content/data loading/handling and often the client simply does not have this content available or ready for production. Once they go away and prepare all of this (often requiring significant assistance and support along the way) delays of several months can be introduced into the project timelines, with the blame being placed on the development partner because the stakeholders will blame the developer for poor project management and planning.

The site eventually goes live after months of delays and cost overruns. This ensures the client is not happy and the developer loses money due to resources having to linger on projects longer than planned. Jobs may even be on the line. This is not a good outcome.

A Better Way

With some tweaks to the traditional model outlined above, major improvements in project outcomes can be achieved, for both merchant and development partner. The biggest delays come in 3 major areas:

• The development partner learning about the merchant's business requirements on the fly
• Lack of platform knowledge by the merchant
• An under estimation of the time, effort & resources required to collect and prepare data and content on the part of the merchant

As such if these can be dealt with then you have a better project outcome! The following represents what I believe is that better way...

• BRD (Business Requirements Document) Creation

Typically created by the merchant/client if they have the capability to do so or in tandem with a partner if not. This usually outlines the business drivers/case for the project, it's primary goals/outcomes to be achieved and primary functional requirements (the site must be able to do A, B & C to support X, Y & Z business operations/functions).

A BRD is often not created/supplied, depending on project scale, budget and merchant complexity/size but it is very helpful when it is. The project scope/specification often acts as the BRD on smaller scale projects.

• Immersion - Concurrent with Business Discovery

This is an internal process where the development partner immerses themselves in the business from an external/customer perspective.

They sign up to all social media accounts, newsletters and research any media articles on the web about the client. Competitors are identified and researched. They may purchase through the merchant to gain a better understanding of service levels and order workflows.

This process provides much needed external perspective and context to the project and adds valuable guidance on how the customer experience is perceived and can be improved.

• Business Discovery - Concurrent with Immersion

Depending on whether a BRD is provided, this is chance for the development partner to ask the merchant a short or long list of questions so they gain a deeper understanding of both current state and desired future state of business operations. This typically covers brand/history, people, technologies, system integrations, marketing, sales, order management/fulfillment, commercial relationships and omni-channel operations.

This is similar to immersion but is deeper and is taken from an internal business perspective. This defines how the business perceives itself and how they want to be perceived in the market.

• Platform Training

Once discovery completes and platform has been decided on, a demo instance can be established and usage training can begin immediately.

• Pre-Production

This marries up the solution specification and creative phases. Since you cannot separate design and functionality, these are consulted on and created collaboratively and in tandem. This eliminates double handling and extensive change request requirements.

This process starts with a data definition document which defines menu and navigational structures and workflows to be catered for. It also defines all key product attributes and attribute triggered content/content display requirements.

The solution consultants and architects work hand in hand with the creative teams to ensure that what is spec'd marries up with the designs and vice versa. All key website interactions and transitions are also defined and documented. 3rd party system providers are introduced to the merchant as required at this stage. Key content areas are defined and work estimated to create or aggregate/prep it for production.

Some additional inputs can help improve and inform this phase:

1. Best practice implementations based on minimum viable functionality defined by quantitative market research by Baymard and others.
2. Customer persona/profile development & qualitative market research to determine what is required to serve these (can include influences by frameworks such as 'Better by Design') content wise and functionally.
3. Customer profile psychological motivator/trigger understanding.
4. Real world feedback (polls/user testing) of the design mock ups/prototypes to validate your intended/planned design/UX/UI outcomes.
5. Direct competitor and clickstream data analysis can help ensure merchants remain one step ahead in their implementations.

• Data and Content Production

All data and content is aggregated, formatted, created and prepared here. This includes all product data, images, attributes, CMS page elements & layouts. This also includes all text for the information pages.

• Technical Development/Production

This is where the site is actually built and integrated with all 3rd party systems. The flat designs are converted in HTML, CSS and Javascript files and then integrated into the base platform if there is one. Customisations are built out and systems are integrated and unit tested.

Since all data and content has been pre-prepared, the development team has all assets required to create a near turn-key build with few delays.

• Testing/Quality Assurance (QA)

The full solution is fully tested and bugs resolved. The site should be proofed at this stage and design integration reviewed. Responsiveness is also tested on various device and browser types.

• User Acceptance Testing (UAT)

This is where the merchant puts the solution through its paces to ensure it looks and functions as expected. Any final changes or bugs are resolved here.

• Infrastructure Configuration

The live site hosting/infrastructure is established and configured. The site is loaded into this infrastructure and tested.

• Launch

There is a launch process that is followed and the application settings are adjusted to live status, culminating in any DNS changes made to point to the new live website.

The real benefits of the above process mean:

• Training starts very early
• The development partner understands the client much more intimately
• Design and functionality are combined at the start
• There are no delays in production due to content & data being pre-prepped
• Fewer commercial surprises for everyone because instead of a single project T&M line item (black hole) covering data & content and other variable elements, this is well planned, costed and executed

The Wrap Up

The above can be best summarised by the following mantra:

"Measure three times - cut once" - yes the extra measuring has a cost associated with it but not measuring has an even higher cost ultimately.

I hope the above helps you to plan and manage your own projects better along with selecting development partners that take a more modern & measured approach to web development projects!

#learnwithjason