As our small(ish) business grows at an almost exponential rate, new challenges are introduced. One of our proposed solutions is to create a design team blog. This post will present what goes into designing a portal like this, why it is important, and its future.
Storyblocks, like many other companies, had to rapidly adapt to a fully remote environment last year. This was challenging for most teams that were used to physically sharing a space most days of the week. Walking past someone's desk and simply asking a quick question was no longer an option, and this shift in operations introduced a new challenge in terms of communication. There was actually another positive factor that was contributing to this shift. Our company's rapid growth.
Growth in company size is usually a good sign in terms of how healthy a business is. Generally speaking, a growing business is performing well, and it's good news for everyone. With growth, however, come new challenges that smaller team members may have not faced before.
Communication at all scales was affected, ranging from small teams to cross-squad, and even company-wide. Not only internal channel messaging is affected, but even how we present our brand externally, and it makes sense. Mo money = Mo problems.
So what can the design team do to improve visibility for both internal and external communications? Releasing a design team blog. By no means is this a visionary achievement as many companies have one, but it was about time we tried with our own.
As mentioned above, the primary goal of the blog is to improve communication across channels, but how are we actually doing this?
Here is a high level breakdown of what we hope to achieve with this blog:
There are many ways of doing this. Some teams like sending blast emails. Others opt for newsletters. In this case, we wanted to create a platform in which design initiatives could be shared out to the company in the form of blog posts. Want the latest update on the design system initiative? You will be able to find it here.
Not only the blog will serve as the place where the team can blast communications, but it will also allow individual team members to share their thoughts on design. Whether it is a post retrospecting on the latest design sprint, a post dissecting the latest Maker feature release, or even a post about designing a design blog (meta AF), this channel offers designers an opportunity to share their process.
Can't remember where to find that damn link to zeroheight where we host our design system? Worry no more! If you ever need a link to any design related resource you can visit the blog and probably find it there (and if it's not, we'll add it).
Both our company and design team cultures are awesome so why not show off a little? We want to use the blog also as a place where anyone can get a sense of how this team operates, and how awesome we really are.
Each team member has a page including their short bio, plus an extensive list of hardcore opinions. If you ever wondered where a designer stood on the pie vs. cake debate, now you can find out by visiting their profile.
After having defined these goals that we wanted to achieve, we moved on with the design process.
We started the process by looking at other successful companies and how they approached their design blogs. We noted what the similarities were between them, and also thought about our company's needs. After having a list of key features we wanted on the blog we moved on to lo-fi wire framing.
We reviewed different options and decided what was working and was not based on the different iterations. At this stage of the process, we also began discussing what tool we would use to implement this project.
We had to be realistic in what was possible since we had to build the blog without engineering resources. This restriction would shape what features we would consider in higher fidelity iterations of the design.
We needed to find a tool that would let us build this blog by ourselves. The selection discussions began early in the process. We had to consider a tool that would be easy to understand, implement, and had potential to be expanded based on future needs. After considering many options, we decided to go with Webflow. This tool seemed to meet every one of our needs, plus, everyone in the team had heard good things about it and we were interested in learning how to use it.
After using lo-fi wireframes to shape the ideal end state of the blog, we moved on to high-fidelity designs. These would provide a very close representation of what the final product would look and feel like.
At this stage of the process, we also start thinking about the visual characteristics of the site. We decided to design using Storyblocks' design system, because, well, it just made sense. However, we wanted to incorporate a little of our personality in the blog's design. After having somewhat of a finalized version of the blog based on Storyblocks' design system, we began experimenting with new color palettes and different stylings.
We had a design critique session in which every designer had the opportunity to provide feedback. We compiled this feedback and decided to start collecting assets, such as our team pictures. Thanks to the magic of zoom we had a photoshoot sesh from the comfort of our homes. With the designs at a good place and all the assets needed in the pipeline, we were set up for a successful build.
First, we made sure with engineering that we could transfer the already existing URL to the new platform. Next step was to have a collab sesh in which we went through some demos of the product and HTML & CSS (whatup MySpace gang). Finally, we cranked out the build based on our final mockups, adapting when hitting bumps in the road.
Now we are pleased to share this space with the world. Storyblocks world, at least. Feel free to reach out to me on slack with any questions or suggestions for the blog, or fanmail.