Open Letter to a Potential Employer Everything you need to know when considering me for a position in your company
I’m a UX/UI designer who can code his own designs. I'm currently looking to father a new product. If you're looking for a designer or a design-oriented product manager, for a new productivity-oriented product — I'm your man.
The work I want to do
I would rather design the next GitHub than the next Instagram.
I believe that passionate designers create better products. That’s why I aim to work on products that interest me on a personal level. It doesn’t have to be something I’ll use, but it has to be something I see value in.
I’m passionate about several types of products, but they could all be described as “useful”. I’m talking about products that solve real problems. These products weren’t created just for fun (although they can delight their users) — they push us forward. Some of the products I adore include GitHub, MailChimp, Pocket, Basecamp and Dropbox, just to name a few. If your company is building such a product, I might be interested in joining.
On the other end of the spectrum, there are product categories that I’m not very passionate about. These include some high profile and high profit categories, but I wouldn’t be a good fit for them. These include: social and messaging apps, adtech, content platforms and gambling sites.
Are you building something people need? Are you looking for a product/hacker guy to take over all design? If you answered “Yes” to these questions, read on. We just might be a good match!
Here’s a rundown of my design and coding skills and ratings of my level of expertise in each area:
Interaction Design — Great
This is what people usually mean when the say “UX design”. That’s my thing. I can take any project from brief and conception, through requirement gathering and user flows to high-definition visual design comps. I create documents, mockups and code as I go. The deliverables that I create vary from one project to another and depend on the project goals and the development process. Read more about my work style below.
Visual Design — Good
By “visual design”, I refer specifically to dressing the product’s “skeleton” with the appropriate branding and making sure everything is aesthetically pleasing. This includes typography, color, layout, image treatments and other visual nuances. Although I have had the most experience applying visual design to UI, I have also designed other things, including presentations, documentation, social media assets and even marketing materials.
Branding — Average
I feel confident enough to create initial branding for early stage products, but at some point down the line you may want to bring in a branding expert. This is definitely a skill I intend to develop further.
Markup and templating — Great
My markup can go straight into production. I try to make it as semantic as possible, with the fewest possible design aiding elements. I also use templating libraries, and have specific experience with Jade, Liquid and Handlebars.js.
Styling — Great
My stylesheets can also go straight to production. I write clean CSS and LESS (yes, I know I should switch over to SASS. It’s on my to-do!).
Scripting — Average
Back-end — Basic understanding
I can read and understand documentation for any library or API, and can discuss back end and specifications intelligently with other developers.
How I work
Working product > Deliverables
There is an end goal we want to achieve. A designer’s job is to fill in the gap between the present and that end goal.
In an in-house product team, deliverables have no value in and of themselves. They are simply the result of activities that move a project forward. There is no reason to polish wireframes or mockups beyond the point of achieving a good solution.
Therefore, many of my “deliverables” look like works in progress, even when I’m done with them and have moved on to the next stage. That’s because what I care about the most is the end result. I’ll always use the most relevant tool or activity to solve the specific problem at hand, which I’ll stay with only until the problem is solved. I believe that the only deliverable that needs to be perfect is the published product.
The basic “skeleton” design process is as follows:
Requirements → Interaction design → Visual design → Build
My aim is to get to the end point — building. I don’t necessarily create deliverables for earlier steps. It all depends on the relative complexity of each step in the current project. In any given step I might spend a lot of time sketching and iterating, or a little time. Or, I might just solve it in my head and move on. If a project requires a higher level of consent or approval from other team members, I’ll incorporate feedback sessions in-between steps to make sure everyone’s on board.
Step #1: Requirements
Possible deliverable: Specs document.
The first step in any project, big or small, is always figuring out what we want to do. This involves articulating goals, gathering business and user needs and listing any technological or other constraints. I’m a big believer in activity-centered design (as opposed to human-centered design, which I think benefits agencies more than in-house teams). Therefore, I aim to arrive as quickly as possible at a list of requirements: activities users should be able to accomplish. This makes figuring out screens and workflows much easier. I find other more “traditional” types of deliverables and activities, such as personas or experience journeys, an overshoot for most design projects, so I rarely use them.
If there aren’t many requirements and everyone involved is in agreement as to what we’re doing, I’ll just jot them down quickly or keep them in my head. If requirements are more complex, or if there is a need to reach consent, I’ll create a full-fledged specs document, specifying the requirements and the reasoning behind them.
Step #2: Interaction design
Possible deliverables: Sketches, wireframes or prototypes.
This is where I figure out how the activities outlined in the previous step unfold within the product. Depending on the complexity of each flow, I might choose to design interaction flows in static sketches and wireframes, or just go ahead and write some code to prototype the behavior. For wireframes, my weapon of choice is Balsamiq. I think it best combines the advantages of both paper and design software, allowing for quick iterations on lo-fi wireframes.
If the flow is simple, or if the main focus of my current project is not on solving an interaction problem, I’ll just figure out the interactions in my head or skip this step altogether.
Step #3: Visual design
Possible deliverables: Hi-fi mockups or HTML+CSS.
In this step I “dress” the screens and flows developed in the previous step with the brand style (assuming the basic branding has already been figured out by me or someone else) and I attend to any other visual design problems. In other words, I’ll apply the brand’s colors and element style, make sure everything is laid out and spaced nicely, work out the typography and make sure everything is readable and aesthetically pleasing. My aim at this stage is to make the markup and stylesheets in the next step obvious and self-evident.
I’m a big fan of designing in the browser, so if the visual design for the current project is straightforward, I’ll just go ahead and code it. But if the visual language is still unsolved, or if it contains many nuances, I’ll take it to Sketch (the design app that cool kids use for UI instead of Photoshop, which I don’t use). There, I’ll work on traditional full-fledged hi-fi mockups, with all the details. I find that it’s much quicker cycling through typography treatments, colors and layouts in a design app rather than in code. If only part of the interface requires thorough treatment, I might focus just on that instead of drawing the entire screen. The same goes for responsive design — if the layouts are simple enough, I just code them; otherwise, I figure them out in Sketch first. Either way, my aim is to move to code as soon as the design allows.
Step #4: Build
Deliverable: Production ready front-end code.
Although my background is not in development, I usually enjoy this part the most. My aim here is to implement my design in clean, standard compliant front-end code. I want to get the product shipped, while maintaining the ability to continue tweaking the design as needed (without driving fellow developers crazy).
I start with marking up the content, in either pure HTML, Markdown or other templating engine. I always strive to write clean and semantic markup and try to ensure that it’s accessible (although there is still some room for improvement). Then I sprinkle Bootstrap on top of it, which greatly simplifies configuring the layout and basic UI elements. After that, I start overwriting Bootstrap’s default styles, either in pure CSS, or preferably, in LESS. I love changing Bootstrap’s variable values and seeing the changes propagate throughout the design! Any behavior related tasks I will try to solve with a jQuery plug-in someone else has published. If I have no luck, I will write my own. In the end, I’ll have the actual interface designed to the pixel and ready to be shipped.
Are we a good match? (TL;DR)
To sum up, we should talk if:
- You’re building a useful, productivity-oriented product (think GitHub or MailChimp, not Instagram or Snapchat).
- You’re product is not in the following categories:
- Casual gaming
- Content distribution
- Gambling or porn
- You’re looking for someone to take care of all product and design related responsibilities.
- You have a team of passionate people who love their job.
Bonus points if:
- The product is new or relatively young.
- You’ll let me code!
So, what do you say? Are we a good match?