The primary tool at work for creating, publishing and editing webpages is called the Visual Builder. This tool is used by do-it-yourself clients, as well as agency production and support staff. It’s safe to say it’s the most used part of our platform. Its popularity resonates with users because of its intuitive drag-and-drop experience as well as the simple categories of design blocks which come in a multitude of options.
So what are design blocks? If you’ve read about Atomic Design by Brad Frost, design blocks are of the “organisim” level. They are groups of common UI elements like paragraphs, buttons, images or components, joined together to form a relatively complex and distinct section of the page.
Create a system of design blocks for the Visual Builder so users can quickly build webpages with little to no experience.
Roles & Responsibilities
- I directed the UI of design blocks for the Visual Builder and collaborated with 2 other designers on iterating design styles.
- I directed research, collaborated with 1 front-end programmer and 2 graphic designers and presented to the program manager and CTO for approval and launch.
- I paused working on the project full-time once the blocks began being built. I provided bi-weekly checkins to review progress.
- This project kicked off in May 2018. The Visual Builder launched with a design block system in October 2018.
- I created a formal process for submitting new block ideas to advance the block library of the Visual Builder.
There are infinite ways in which a website can be designed. From image-rich photography portfolios to content-heavy, public information websites like local or state governments. Developing a system of design blocks could be a lifelong, infinite task.
To find some common ground, we put together a list of knowns that we could test and ask questions against.
- Users are not always tech savvy.
- Blocks should be named and recognized in terms the user already understands. Basically, don’t try and reinvent anything.
- Our company mission is focused on website accessibility, meaning anyone with a disability can still access information on a site we have built. So design blocks, when published needed to enforce the principles of web accessibility.
For this project, we researched a lot of bootstrap themes because that is the framework our Visual Builder is built upon. A pattern of common bootstrap elements began to appear. We put these into categories and soon discovered a wide range of design blocks possibilities. The categories include header, footer, hero header, page titles, heading + paragraph, content blocks, services, images, team/staff, video, call to action, maps, forms, and dividers.
The team worked separately sketching out ideas in each category. After we had a minimum of 3 ideas for each category we put them on the wall for an informal review.
Why only 3? I know based on my team’s design strengths, producing 3 sketches per designer was enough to get their creative juices flowing. So when it came time for discussing them, they were excited to share sketches, but also brainstorm and provide feedback on other teammate’s ideas.
Putting everyone’s ideas on the wall produced a new problem. Everyone had different ideas. Meaning if we allowed each designer’s idea to get produced, when put together, they might look like a patchwork of random design ideas (like the Frankenstein of website design), rather than a clean, professional design. We decided to eliminate any style aspects to design blocks and focus on generic ones that, once produced, could be styled in the settings dialog (separate to this case study).
Deciding who would use the design blocks was simple… everyone that uses our visual builder will use design blocks. Some of the personas we developed during the research phase included client roles as well as our own internal users.
Our test plan was to first use people within our own company. We have a variety of people that represent several different levels of expertise. We put together some simple instructions and asked them to build a one-page website within 15 minutes. During this time, we watched but did not comment on how they used the Visual Builder and design blocks. At the end of the exercise, we asked 5 questions to gauge their experience outside of what we observed.
Taking the notes from the first test, we regrouped and ran a modified design sprint, putting notes and answers into common groups and prioritized based on impact to the user and time to complete. We made changes to the design blocks and set up the second round of testing. This time we scheduled 5 different local clients and ran the same test.
The launch was fairly simple. Having over a 1500 clients we didn’t want to push the new design block system to the live production environment all at once fearing this would cause a flood of questions from potentially angry clients. So we divided our clients into 3 groups and launched in stages. Before each group received the updated design blocks, we send 3 emails; and introduction to design blocks, how to use design blocks, and how design blocks can save time and increase productivity. We did this in 2 week sprints, so by the 6th week, all clients had been updated and the design blocks made available.
Outcomes & Lessons
Building and publishing a 5 page website now takes about 4 hours. Before the creation of our Visual Builder, and the addition of design blocks, the typical website went through a staggering design-build process that, on average, took 3 days to build. Design blocks democratized the building process so it wasn’t so reliant on web designers and front-end coders. This freed up people within our own company to start building websites. And it allowed our do-it-yourself clients more control on making their website their way.
To comply with my non-disclosure agreement, I have omitted and obfuscated confidential information in this case study. All information in this case study is my own and does not necessarily reflect the views of the company or clients I work for.