It’s a bit hard to pin point exactly what happens during the design process at Codelitt. Our design team is small but we work very closely together, and even though we’re remote, from our shared experiences we could break our main processes into the following steps.
Drawing might not be for every designer, but I feel there’s a primal need to have something tangible on paper whenever we start a project. An old boss of mine had that as his motto, and whenever he saw us on having a hard time solving a problem he’d ask us if we’d consulted with Mr Pencil there. Starting on paper makes things easier for me, there’s a certain freedom to it, a much friendlier way to face the blank page and get started, because, as Saul Bass said, “no matter how much experience you have the blank page is still terrifying…”.
Quick rough sketches during a call for an MVP we made ↩
I sketch like crazy, drawing on every little bit of paper that I can find. I try different layouts, balancing elements without much detail, just basic shapes outlining a raw idea. Having things on paper also allows me to go back and revisit old ideas, think of new approaches for old problems, and maybe borrow from my previous thinking to solve new ones.
2. Team chat
Drawing sometimes happens while we’re discussing the project with the team. I can’t emphasize how absolutely vital it is to every team to communicate, to have brainstorming sessions, discuss user flows, priorities, and shape up ideas. Maybe we have an amazing idea that ends up becoming a nice-to-have, and that other shy one that was proposed as an after thought becomes a main focus of our product. Team talks are unbelievably important, and every single team member brings invaluable things to the table.
3. Research: get looking.
Codelitt builds products and MVPs, which means time is always running short. Sometimes there isn’t much time for research, but ideally we like to have some sort of general knowledge before starting with wireframes. When we do, we start with the main design arteries, Dribble and Behance, we check out countless blogs, the competition, even stuff that’s not directly related to the problem we might be looking to solve. My advice on this to you is to look a lot, and then observe. If you find an amazing image try to understand why it’s compelling you to look at it. Find the reasoning behind the things that catch your eye, and try applying those same principles to your work when the case allows it.
For each project I create several folders: a folder for all the images created for the project (background jpegs, pngs, svgs, gifs), a folder with the material sent from the client (guidelines, briefs, feedback), another with the source files I’ll be working on, and a last one with referential material and inspiration for that particular project.
I also have a lot of general folders with examples of amazing dashboards, on-boardings, websites, illustrations, mobile webs, and of course the occasional nature shot or whatchamacallit that ends up in “Stuff”, all of which I consult on a regular basis to see if any of those will prove useful for the current project.
I tend not to dwell too long on wireframe quality. Sometimes we only sketch them up quickly to convey ideas and see where that takes us, but it is in my experience that product design is ever changing: we iterate, add, subtract, change. We like to start and get our hands dirty. The wireframes we create are very raw guidelines of how things could be laid out but by no means are they a strict rule to follow. In other types of work, such as company’s websites, dedicated wireframes are an absolute must have especially when signing off with the client, and we include a higher level of detail and stick closer to them when creating the mockups. However for products we tend to do rough Illustrator sketches, which prove to be enough for developers to go off and start building the back end of the project.
As opposed to most design agencies, we work primarily on Illustrator, in conjunction with Photoshop for anything bitmap related. This application has a lot of gains in our line of work: first off, multiple artboards. You could argue that a PSD file has layers, but it’s not the same thing. Artboards allow you to see the entire project displayed at once, without having to go activating and deactivating different layers. Another positive attribute is that Illustrator works with vectors, so there’s no limit to the resolution of the source files. Monitors keep increasing their resolutions and soon designing for those will mean hefty PSD files, which isn’t the case on Illustrator. The downside of it is that you do have to switch to Photoshop for anything image-related. There are other apps that I’ve yet to try that could solve this (I heard nothing but wonders about Sketch for instance).
6. Team feedback
As I mentioned earlier, time is always an important factor to consider. We strive to have as many team members as we can when reviewing design, but we’ll settle for One Of Each (a designer, a developer, a project manager) if team members are busy. It’s important to have all sides of the project pitch in at this point before presenting our work to the client because each will have a very different response to the question “does this answer the problem we’re trying to solve”. More often than not, a developer will think of edge cases that don’t come naturally to us designers, leading to a design breakthrough.
"The irony is when you code, you check for the edge cases first. When you design, you get to them last." -Margaret Kelsey
7. Delivery and guidelines
We aim to be as tidy as possible. We all share files on an encrypted BTSync server, where each project has its mother folder, and inside it several others. It can roughly be translated to:
WIP means Work In Progress, and it’s generally an internal folder between the Design team. We strongly urge the rest of the team not to wander too closely to that folder in danger of being sucked into the black hole where we allow ourselves to be messy and paint the walls. The “Final” folder contains the final source files that the developers should consult when programming, and a PDF of the same file to show to clients. We’re slowly migrating towards using InVision app for our presentations which is far better to show interactivity than a static pdf, but meanwhile we still create it as a reference.
Just a few days ago on a company wide meeting, our devs told us they love it when we prepare color guidelines for them, so we’re taking more time to create dedicated style sheets per project. Each Illustrator file has instructions, ideas, and flow descriptions on the artboard’s margins, in the manner of stage directions. We could link to a certain Codepen effect, or CSS gallery to get our point across, and we’ll do it all inside the file by the mockup, so that the devs know what we’re talking about.
8. Feedback and QA
There’s generally one or two rounds of feedback and then the product gets delivered to the developers. Communication doesn’t stop there: we’re in touch constantly going over work and any doubts that may arise from the work provided, we might change designs internally or make decisions on the go with the developers. When they feel they’ve come to a good place, they push their work to a local server and we begin rounds of QA. We use Trello to keep track of all the pending items (there’s something very cathartic about checking items off a list!) and things that might yet not be approved. When they eventually are, we can push live.
In product design and development, the work is never over. We iterate constantly, we do usability tests and gather feedback from real users to improve on the go. We create new features, add to existing ones, or change things according to new research. We’re always learning, always looking to improve our work and always thinking of better ways to solve problems in future.
Download our Incubator Resources
We’re known for sharing everything!
Save more time, get more done!
Innovate from the inside
YOU MIGHT ALSO LIKE