12 Apr 2018
Keep your iterations during the design process, and, when finished, look back and review how you ended up where you did. What decisions didn’t work and why? All failures should produce learnings.
I’m currently doing all my design work in Sketch. Previously, my tool of choice was InDesign. Both are great for me because I like to work iteratively and these tools make that easy. After every quick round of design changes to a comp/artboard, I make a duplicate and continue with my next changes there. Sometimes the changes are small differences on one element or component. Sometimes the changes are more broad and structural. But no matter the scope, I can always read the story of how I came to the final solution.
When it’s time to archive a project, I go through my designs and review. I take a few notes, asking myself, “What did I learn from this?” It’s not always much. Maybe something like, “Call to Actions always feel better to me when placed closer to the bottom right.” Or, “The solution for greater clarity in this component depended on increasing the typographic contrast.” I then often delete many of the interum iterations, keeping ones which most represent my best thinking. Reducing the clutter will make going back to the project later easier to revist.
02 Apr 2018
Design leadership is highly dependent on personality. I have no idea, yet, how to write about what works best. Personally, I’d see design leadership as being responsible for the work getting done and for team members feeling empowered to make decisions with confidence. Leadership has the privilege of going to stakeholder meetings, but that shouldn’t translate into being sole design decision makers. They should represent the team in a way that facilitates as much shared responsibility and opportunity as possible.
I differentiate between design leadership and, say, a VP of design at a large organization. A VP, or a Chief Design Officer, would own more design decision making and department direction. But a design leader should sit more or less equally on the playing field with the rest of the design team.
16 Mar 2018
John Maeda’s Design in Tech Report 2018 is out. Any designer working in tech right now needs to give this a look. I’ll be returning to it regularly.
14 Mar 2018
With design documentation, it’s difficult to discern what is too little and what is too much. While It’s a waste of time to redline every single element in a comp, a developer should never have to guess at anything. Getting the balance right depends on a few variables: the effectiveness of the design system in place, the experience and knowledge of the designers and developers, and the extent to which previously built components are referrencable.
At the very least, design documentation in specific agile tasks should define anything novel not yet established in the product. This work is the designer’s responsibility. The developer, however, needs to know enough about the design system and the rest of the product to be sure they are following established patterns. There is a natural give-and-take here which needs to be worked out between designers and developers. No two product teams will have the exact same balance.
My attitude is always to accept 100% of the responsibility in situations like these. As a designer, assume the developer needs you to be highly detailed in your documentation. Be thorough at the start, and later discern where you can lean on your growing design system.
13 Mar 2018
When you are staffed at a level which only just covers the planned work, it means when we’re short someone for any reason, you are stressed in completing the work for the sprint. It also means you don’t get to any business-as-usual tasks. Nothing gets done, and nothing gets improved.
Developers and designers need space and time in their week to solve the smaller problems which will always exist for products. Things like changes to browser requirements, or page load fixes, or SEO for Google results, or asset management, code cleanup, etc. There is always room for improvement, but without time to make those improvements, that work will never get done. If you’re a small company, there’s an excuse. If you’re a sizable company, not so much.