Bruce Davis-Goff - APAC Operations Director
23 Apr 2021
As a veteran of many website builds, I can tell you one thing – the classic website design process is back to front.
In very broad strokes, the classic process goes like this:
There may be slight variations on this process, but that‘s essentially it. I have big problems with this process.
Firstly, it’s linear; each step depends on the previous step’s completion, dragging the whole affair on longer than it needs to. You may puff and preen, claiming your process is Agile because you have scrums, retrospectives and stand ups, but I’m calling BS on that because this still looks like classic waterfall to me.
There’s an old army adage that runs: “no plan survives first contact with the enemy”. Aspects of it might, shuffled around as the situation on the ground evolves - website builds are no different.
Over the years, (this is my “when I was a boy moment”), I have seen so many weighty tomes produced up front that require a major rewrite in the first two weeks of the build stage; wasted time and effort. Things inevitably change and the process needs the flexibility to change with it. The best solution to this is a collaborative Wiki updated continuously throughout the project, keep it fluid.
In essence, the idea is to get your pieces on the board ASAP and see how things start playing out.
The Sitecore take on an SXA build process looks like this:
My take is slightly different as shown below.
Let me walk you through my plan above:
Firstly, and most importantly the BIG questions and i really cant emphasize this enough:
The answers to these questions should be the primary force driving your content and visual design and by extension your data schema etc. etc., as opposed to the often-heard phrase “we want a modern looking site”.
All of these answers, including segmentation of your visitors and their proposed user journeys should be known first and used to inform the rest of the process. At the end of the day the site is for your visitors and not a showcase to skite about how cool your company is or how flash your designer is.
Content Review – it makes sense to follow on from the answers above, what content do we really need to engage our target audiences? Having piles of content may help a little with search engines but a scattergun approach tends to confuse users, especially if your search is not optimized, boosted, or otherwise targeted. How does my reviewed content play into my planned user journeys?
Communication and collaboration – Get everyone onboard early – how will we communicate quickly and effectively? Emails slow a dev process in my opinion, I might like to reply within 10 minutes but not many people do. A question like “can I have permissions to do xxx?” might not be answered promptly leading to delays. Instant messaging works best, and I am a big Slack fan, Teams is OK but if you are working across multiple organisations, it’s a pain and vital communications can get lost.
Issue resolving and reporting is super vital, get it running smoothly before you deploy your pieces. I am now a full convert to Azure Devops for integration across tasks, bugs and the code, but maybe you like Jira or even Trello.
Then and only then are you ready to start the game:
Devops – get this sorted first and have a seamless development and deployment process in place. This includes your environments, by now you should have at least Staging, and Prod set up and a nicely integrated Docker stack for development.
Developer setup, make it easy, fast and repeatable – why, in the age of Docker, should it takes 3 days to set up a local environment? I’d expect a reasonably competent developer to be able to pull the repo and run up a docker stack in under an hour and be committing by the end of the day.
At this stage, your PM should have worked with your lead dev to chunk the work into sprints, but my advice is keep it loose and high level, things are going to change once we start. While it may be hard to find a PM with good SXA experience, they need to be educated about the SXA build process and what is possible. I have seen mountains of tickets created for what would essentially be a single SXA task, it just clogs up the system, keep it simple and light and rely on your devs.
Wireframing – why do it on paper when SXA lets you build a real prototype, get feedback instantly and makes changes just as quickly. You may just have to work with the designer and show them how to drag and drop.
Visual design, I see no reason why this shouldn’t start alongside wireframing – lets be clear here; 90% of websites are the same – they have a header with menu and search etc., then a banner or carousel of some sort, then 3 or so big calls to action, then some other content followed by a footer with links to important stuff, social, contacts, disclaimer, copyright etc. The reason websites are all so similar is the same reason the fundamental design of Microsoft Word is mostly the same throughout the years – people expect to find things in familiar places – why frustrate them? Also never let the visual designers start without having fully briefed them on what is OOTB with SXA, they will just make stuff up otherwise.
The back-end build starts as soon as the SXA tenant and site has been created and wireframing has commenced, front end can start soon after using the Sitecore Creative Exchange and CLI tools. No need to have your front-end guys requiring a local Sitecore install unless they really want to, and Docker also makes that easy if they do.
Content – personally, I am a big fan of the full import – pull all the existing content into Sitecore and use it for development, the content team can even do their reviewing and tweaking on the prototype site and even fool around with the IA. It’s just data, I don’t care where’s coming from and can transform it anyway I want. Another advantage - it’s the real content; a headline in a mockup may not work when the real headline is two lines long Lorum ipsum introductions that fit neatly into a visual design may not work in the real world – fail early – fail fast.
QA – don’t wait for anything, get them acquainted and involved from day one, also make sure they understand how Sitecore and SXA work, who needs false positives?
And by ME I mean Content Editors. No matter what platform they come from they need to be involved early for plenty or reasons:
Training – how to do the same thing they have always done but with lots of new, fun toys. Their special tricks and internal processes – ask them at the very outset, they often know more than you do.
Familiarity – The process of creating partial designs, snippets, nested layouts, personalizing and much other fun stuff is best learnt hand-on. By hands-on, I mean editors in the dev or staging environments from day one. And from day one I mean as soon as they have wireframed up a homepage – seriously it will pay off in spades.
Best QA – They will find things even your best tester will miss.
Project management has benefited from agile methodology, but the classic project construct has not – new sales guy, same product. Sitecore and SXA deliver the tools needed to change that easily, though the same principals apply to many other technologies.
Lastly, I still believe 75% of the work in a Sitecore build is in the planning and upfront brain work, if you have answered all the questions and planned out the process, the rest should be quite small by comparison and should always leave you enough time and budget to make sure the marketing features don’t get shunted to phase two. In fact the plan should look more like this:
That’s the whole reason you are using Sitecore in the first place – to design engaging experiences to benefit the business and the visitor. If you want to know more about Sitecore and SXA contact us here:
As a five-time Sitecore MVP, with 15 years of experience working with, and for Sitecore, Bruce brings a valuable depth of skill and experience and a commitment to best practice excellence.
Bruce is a passionate Sitecore Architect with specialist skills in SXA, strategy, migration, and upgrades and is a certified developer, trainer, and NZ Sitecore User Group / SUGCON organizer. His background as a Sitecore Business Development Manager, coupled with solid technical skills, and enthusiasm for getting the most out of Sitecore, means
Bruce brings value to any project and currently looks after operations for the APAC region.