I have always considered myself a “designer who codes”. I enjoy that aspect of the web, even while in a purely visual design role.
Not too long ago, in a previous visual design position I was in, I had a manager refer to me as a code “dabbler”. This actually offended me. Surely countless hours spent reading books, doing tutorials, hacking away, building websites makes me more than a “dabbler”? I thought to myself, I am not a “dabbler”, I am a unicorn!
Proof of this unicorniness? I packed up my design and code skills, and found a new work home at Cloud Four, haven to unicorns just like myself. Everyone at Cloud Four is a kind of unicorn… magnificent designing developers and developing designers.
But after a few months of having my code reviewed by my fellow unicorns, I felt less like a magnificent unicorn and more like this:
Working in code every day has given me a new perspective… I am an Ugly Unicorn.
I found myself spending little to no time in photoshop or sketch and jumping into the deep end of pattern libraries and prototypes. For the first time I was working on a team, submitting code, using git and creating pull requests. Here is a little how that went:
Yikes. I kept hearing the those words echo through my head: code dabbler, code dabbler, code dabbler. Over the last year I have been waiting for an “ah-ha” moment where things would click and I would feel super comfortable and confident in my skill set, that really hasn’t been the case.
As someone who knows a little code (aka: super smug person who considers themselves a unicorn), it’s easy to be like, “Hey, just learn to code”. However, stepping out of your knowledge base and comfort zone can be a scary place. It can even be daunting just knowing where to begin. Some designers I have talked to are straight up hostile when the idea of having to learn to code is mentioned. One designer friend of mine was appalled at the idea that now after having invested so much time, energy and money into her design education she would additionally have to learn to code. What I wanted to say to my friend, and also what I should remind myself of at times is that, it’s going to be okay. You don’t have to become a developer.
It’s not about being an expert at both design and development. You will always have a strong leaning towards one or the other. I will always be a designer first. I will never look at something and not want to make it beautiful. Also, there are developers out there that not only can see and appreciate design, but can put together typographic systems and pick amazing color palettes, however, at their core they are developers. People have their natural strengths, but that doesn’t preclude them from having other talents and appreciations.
When I look at a problem, it will always be from the perspective of a designer. I like to solve the big problem, piecing the code together to get my idea out as quickly as possible. Then I worry about making the code better later. The main point is getting the design, or the experience out of my head and into the browser, where I can squish my screen, or pull it up on my phone. I don’t have to be an amazing developer, or a decent developer or even developer at all. I just need the tools necessary to realize my vision for the design problem I am trying to solve.
I like to look at having technical skills the same way I would look at having presentation skills. Or project management, writing, and concepting skills. We are not just pixel pushers, we are designers. We are complex thinkers, makers and problem solvers. That goes way beyond just the presentation layer of a design. It’s about a breadth of knowledge that informs your creative process. Code informing visual design. And vice versa, visual design informing the code.
I don’t believe there are natural born unicorns. People are not just magically amazing designers and awesome developers. I do believe in the constant and perpetual learner. What being a unicorn is really about is just having a hunger for knowing more. Not stopping at just enough knowledge. Unicorns are just people who are curious. You show me a unicorn, and I see someone who likes to learn not just about their own discipline, but also the ones that overlap theirs.
Some practical advice from a Ugly Unicorn
A basic knowledge of HTML and CSS is enough to start designing in-browser. Start a CodePen account. Keep reusable snippits that you can incorporate into prototypes. Bookmark and save plugins that can help you prototype quickly. You don’t have to become a developer, it’s about getting your idea out. Be okay with feeling like you kinda suck, or feeling uncomfortable. Embrace being an ugly unicorn. Even though it feels weird and messy stepping out of your pixel-pushing comfort zone, you will ultimately be embracing the responsive web.
After documenting our collective inspiration in the form of Mood Boards, our next design exercise for the redesign of cloudfour.com was Element Collages.
We used a few points of reference before starting our Element Collages. First was Dan Mall’s post from 2012, in which he talks about evolving Element Collages from Style Tiles. We also referred to Clearleft’s post that explains their usage of Element Collages and how they arrived at using them as a deliverable.
We also had a few bits of background that we used to inform our collages:
Round One
Armed with all of that knowledge we set out on our first round of Element Collages. Each of us did a unique collage and posted our work in Basecamp. Along with our collage we posted our ideas and thought processes on color palette, imagery, typography, and any other areas of note. People posted feedback and knee-jerk reactions in Basecamp, however, we reserved most of our feedback for in person discussion.
Once our collages were ready for review, Tyler prepared a simple google survey which asked questions about each collage such as likes, dislikes, how well it embodied our brand characteristics, and how we felt about its design characteristics overall. The reasoning for doing a survey, even though it was an extra step and more work, was to give every team member an equal voice (rather than just the loudest voices in the room). It also gave everyone a chance to collect their thoughts prior to an in-person discussion.
The results of the survey gave us an idea of what the strengths of each collage were.
It was clear that Cloudfourians were really drawn to illustrations that Tyler and Sara used in their collages.
Illustration by Tyler Sticka 
Illustration by Sara Lohr
Erik’s had strong typography, and a dramatic color palette.
Final Round One Collages
Round Two
Taking these insights, we moved into the second round.
We borrowed elements from each other that we felt worked well. We revised, refined and reworked our collages.
Final Round Two Collages
At the end of the second round, we had a final survey which zeroed in on which collage was our favorite. Tyler painstakingly compiled the results from each survey and created two keynote presentations that we used to facilitate our in person Element Collage discussions.
Tyler’s final Element Collage ended up being the group favorite.
Given the collaborative nature of the second round, Tyler’s collage ended up borrowing many elements from the other collages. He uses Erik’s color palette as a starting point and brought in Sara’s “we ♥️” treatment for the hero illustration, just to name a few. Overall, the team felt this collage was friendly, cheerful and welcoming. The illustrations added personality and the design evoked a sense of clean freshness. Most importantly, it felt the most like Cloud Four.
We are currently in the process of working on our Pattern Library. You can follow all Cloud Four redesign fun in real time by joining our public Slack channel and our project board on Trello.
By now you’ve probably heard that we’re full steam ahead with a redesign of our beloved cloudfour.com, and we’re doing it in the wide open for everyone to see.
This is an interesting and fun endeavor for us, being both the client and the project team. It definitely adds a layer of complexity, but it also allows us to try things out that we might not be able to given a client’s project constraints.
We pride ourselves on being adaptive to the project’s needs – we don’t have a one size fits all process. This is part of our DNA (and part of our differentiation as a company.) Here’s how we are adapting to fit our own project’s needs:
Cadence
In our public Slack channel, I mentioned that we’re working in agile fashion (not capital-A-agile, but y’all know how I feel about that. We’ve settled into two week sprints as a general default on projects, and we started our first sprint last Tuesday. It goes through March 8.
To keep things fun and interesting, we opted to name sprints after animals. Sprint 1 is called Honeybee, mostly because I liked the emoji for that animal. Buzz!
Communication
We have weekly check-in meetings that take place during our regularly scheduled staff meeting. We already have that time blocked, and we rarely use it all, so no need to schedule yet another meeting.
For daily communication, we use Slack. We also have a Basecamp set up for this project, but we are using it less and less every day.
We’re still feeling out if a daily stand-up is necessary for this project and we’re exploring some tools to facilitate asynchronous stand-ups via Slack. More on that soon!
Tasks and Status
We’re using Trello to manage our backlog and keep track of what is in-progress and complete. We’ve made our board public, so you can follow along there as well.
We generally set up our Trello board so there is a Project Information list at the far left. This provides some basic context for the work that we are doing, and hopefully is a good place to get started when you first join the board.
For the moment, we have just a few lists to help us keep track of tasks. Please feel free to take a peek around!
Follow along with us!
I’m excited about the challenges we are undertaking on this project, and super thrilled we can discuss them in the open. Check in on our Slack channel, Trello board, and Pattern Library to stay up-to-date on our progress (GitHub repo coming soon!). We’re also tweeting at #c4redesign. You can catch up on all our redesign posts here on our site.
Back in the heady days of the .com boom when my cofounders and I all worked at Kavi Corporation, we had a number of technical standards-setting organizations as clients. As proof of industry support for their standards, almost all of these SSOs would have a page on their site that displayed the logos of their member companies. It was up to me and the other designers at Kavi to make sure these rosters looked good; the images were compressed properly, free of float clearing issues and with equal visual weight given to each logo, especially those at the board level.
Over time, I became something of a tech company logo connoisseur and developed an awareness of what made for an effective logo. Aside from the basics taught at design schools everywhere, I found that a width to height ratio between 2:1 and 3:1 was a de facto standard, and that straying too far from this aspect ratio range meant that the logo wouldn’t read well when sized to match the others.
I kept this “early aughts tech company logo” aspect ratio in mind when designing Cloud Four’s original logo. Also, we wanted a logo that conveyed the intangible qualities of our fledgling agency: openness, transparency and reliability. Nothing says, “Hire us, we’re almost certainly going to be around six months from now!” quite like a serif typeface, so we selected Lineare, whose graceful ascenders ably supported our brand qualities.
A color palette of muted blues and grays reflected our home, Portland, enshrouded in a gentle drizzle 8 months of the year. The cloud shapes above the letter forms were an obvious tie-in to our company name and added a sense of rise, growth and lift to the text treatment. It is probably no small coincidence that I was pregnant at the time of the original logo’s creation either!
One or two things have changed since 2007. For one, that 3:1 aspect ratio doesn’t work too well for the abundance of square formats to which a modern logo must conform, such as home screen icons and Facebook profile images.
So, our new logo was born out of necessity, quietly appearing first as a favicon, then migrating to our Twitter account and beyond. We’ve also evolved as a company; gaining confidence and expertise with each employee who joins our team. While we’re still an open, transparent and reliable company, we’re also a cheerful, responsive and scarily smart company.
Our new logo reads well in sizes ranging from Slack emoji to the t-shirts we wore at Responsive Field Day. The vivid blue is more eye-catching than the demure slate of yesteryear. The cheerful, bubbly cloud shape contrasts with the strong diagonals of the negative space of the “4” that impart a sense of motion and activity to the logo form. I envision our new logo emblazoned as a badge on the arm of a scout, exploring the wilds of the web’s frontier.
Our team had a set of defining characteristics and was almost ready to start redesigning cloudfour.com. But before we dived into element collages (more on that in a future post), we wanted to draw from a shared well of design inspiration. So we decided to make a mood board.
A mood board is a collage of reference imagery from the outside world with some relevance to the project in question. It can include examples of typography, colors, illustrations, photography or other stylistic elements. Traditionally, you’d assemble one from magazine clippings or whatever else you didn’t mind cutting up and gluing to foam core.
We decided against the cut-and-paste method for a couple of reasons:
- Most of the team’s favorite sources of inspiration are easier to assemble digitally than in physical form. One could argue that the value of a mood board exercise is in exploring sources outside one’s typical frame of reference, but for this project it felt like a poor fit.
- By this point, our team was engaged in parallel projects that made scheduling a day-long, in-person exercise difficult to coordinate.
Digital mood boards are nothing new, and there are plenty of tools to choose from (InVision’s being particularly impressive). We decided to use Pinterest, simply because most of our team was already using it.
Over the next few days, we assembled 79 pins into the cloudfour.com mood board:
Although our team members contributed independently, the overall tone of the board is fairly cohesive (possibly owing to our earlier characteristics exercise). This gave us the inspirational mind-meld we needed for the next design phase.
We wrote the book:
Recent Comments