If you have or can get access to any ATS (applicant tracking system), use it! Even if it’s the clunkiest piece of software, as long as it can recognize candidates that have applied before, let you keep notes related to their application, and have some way to change its status, it will save you time and confusion and help prevent applicants falling through the cracks.

If you cannot afford access to any ATS, Trello has worked amazingly well for me on a few occasions as a make-shift, poor man’s solution. I set up all incoming email to forward to a column called "New". Then I had series of other columns reflecting the status of the application, each card moving from left to right based on the status:

• Confirmed Receipt
• Reviewed
• Reviewed and responded (no match)
• To interview (1st round)
• To interview (2nd round)
• Hired
• Closed
• Offering services
• Junk email

In addition to notes, I would put any correspondence to the applicant as a comment in the card.

With the job description, get input on it from several non-designers (assuming an in-house context here). People the hire will work most closely with are great for that. Sweat the job description. Examine and re-examine every line. I personally like the intro/mission/vision section to be aspirational and idealistic and the requirements section to be written with a clinical dryness and accuracy of an attorney. "Significant design experience" is a bad requirement because what significant means can be so subjective. "3 or more years of experience designing digital products" is better. "3 or more years of full-time experience designing consumer web or mobile applications" is even better. If you are ever in the position to sponsor an applicant for a work visa, you will discover that the first example will be a non-starter. Even if you are not, objectively written requirements help everyone! Unambiguous requirements make it easier to involve other teammates in initial screening of applications. Leads me to a related point: If you know for sure that you are not in the position to seek work authorization on behalf of someone who needs it, You might want to note that in the description and save everyone a bit of time. Be aggressive about reducing the amount of requirements to make them more meaningful. IMHO, most JDs have too many items that aren't real requirements. Do you really need to require a certain degree for example? Would you hire an designer with an amazing portfolio and substantial amount of professional experience despite them leaving college in their senior year? Make the requirements reflect that. Are you open to partnering with recruiters to fill the role? If you are not, put a footnote at the end. You will hear from them anyways, but it might help reduce the volume.

Treat applications like milk inventory in a grocery store.

Regarding correspondence with applicants, be as generous, respectful, and helpful as you can. You may have discovered that the bar is kind of low out there. I have personally experienced all kinds of interactions that left me sad. E.g. black-hole treatment after up to 4 rounds of interviews, being told "We have gone with a different candidate" when in fact their search continues, not getting any confirmations from multiple channels despite the same job being actively posted to additional channels at that same time, etc. For example, for people whom we’ve interviewed and those referred to me by someone I know, I’ve always let them know why the role is not a god fit over the phone. Without exception, they met me with appreciation and it left a positive impression. My stretch goal as a hiring manager is to give every legitimate applicant personalized feedback (I have succeeded int hat goal about 60+% of the time so far). Something that can help them in their search going forward. I tried to add one sentence to a rejection letter template that states what their portfolio should have if they were interested in roles similar to one they applied to. Or pointed to kinds of roles they might be a better fit for if the issue is not quality. Many applicants are starved for feedback. This can be incredibly time consuming but the more you do it, the better you’ll get at being super efficient at it and related tricks like creating templated snippets of text for applicants that share similar portfolios and gaps. (see https://www.lever.co/blog/how-to-write-human-rejection-letters). Applicants really, really appreciate this.

When making post-interview decisions with the team, be clear that you are getting their feedback because you want to know how they feel but ultimately you’re the one making a hiring decision. Look up fist of five polling - it can be a helpful technique. Prefer getting the feedback individually from teammates (Google Forms are great) before you meet as a group because group think and influence is hard to control in a group setting. Collect feedback as close as possible to the interviews. People forget things.

Best of luck!

UPDATE: Forgot to mention this: http://gender-decoder.katmatfield.com (Other tools like Textio can also help identify gender bias in writing)

I pretty much second Todd’s advice but would add another to it.

My best advice is to consider if what you’re describing needs to be a binary ("either-or") type of situation right now. Sure a decision about whether to rework an existing thing or build a new feature becomes either-or at some point but maybe it needs not be that right now.

Would it be possible at all for you, while not compromising the delivery of what teammates expect of you right now (sounds like that’s building out features on top of what you consider an ill-formed core), to design in parallel a minimum showable flow (or whatever artifact is best) of the core that you think should have been? That would allow you to show and demonstrate why taking time to redesign the core would put the product in a better position. Hopefully, the work itself will inspire teammates because they can compare and contrast the current state with this imagined alternate reality. It will surely provide an opportunity for conversation: At worst, you might find that others actually think your redesign is inferior! You might discover that they tried a similar approach but ran into a non-obvious show stopper which you had missed. Or, hopefully, you might be relieved to hear that they never before had anybody who had the skills and was in charge or tying it all together in a way that a product designer is uniquely qualified to do and OMG, this would work so much better!

The most difficult thing about it squeezing time to do both. The process might help you get even better and prioritizing and time management.

You gan get a lot of mileage out of it as an Illustrator alternative, sure. I’d encourage you to just dive in and give the free trial a spin on your next project and see for yourself.

Of course you’ll hit limits with some specific and advanced needs. For example, I really needed the capability to select all shapes with same fill color recently. It’s not a feature that AD supports yet. Vast majority of the time, it has everything I need of standard pathfinder operations.

It’s also fun to discover tools and techniques in AD that are better than the ones of other tools. For example, the cloud tool in AD is freakin' sweet. Sure I could create same shapes in Illustrator but doing so seems needlessly complex in comparison.

What kinds of things do you typically design?

When I’m working on multi-step flows (say a checkout flow for example), I typically lead the effort. Meaning, I will first sketch out the flow to decided on all inputs that are required, what kinds of status I need to communicate back, figure out a sensible number of step for the interaction, and figure out what kinds of different states a user might end up in along the way. Then I’ll take that flow and make rough wireframes out of it. I’ll be the one that writes out the initial, crappy version of the text for all status messages, headlines, buttons, and occasional paragraph or two of instructions. Then I’ll share the wireframed flow with the editor/copywriter. InVision or Zeplin commenting features work well for that for me. Heck, sometimes I even print out the flow on paper and the editor marks it up. (Note, this doesn’t mean that I am not involving the editor from day 1. Day 1 happened before I started sketching the flow, when the team gathered to discuss theme, goals, and scope for what we’re doing. It’s the output of that meeting that serves as the input for me to begin work.)

When I’m working on features that are light on flows and heavier on content (like a two-step process for example that’s a point of conversion, or a single page that provides a report for new data that’s available), the editor and I might agree that it makes sense for that particular feature to be content-driven. In which case they’ll write out the headline and copy that communicates the value prop of the product or of doing something within the product. They usually write that out in Google Doc (our org runs on G Suite), and I’ll take the draft of the content, lay it out and format it before sending it back to them for review. There’s usually a little bit of back and forth. Seeing their content on a actual page makes them tweak the length or structure more often than not.

Sometimes it’s hard to tell which of us should take the first crack and it becomes clearer to both the editor and I only in retrospect. And there may be better ways of working that I haven’t tried.

These are good questions for us all to be asking ourselves. A few thoughts that help me feel better when reflecting on my own work:

• Knowing that companies with social causes exist. I work at a company that helps people in quitting smoking, walking more, and improving their well-being. The fact that it's a commercial business with a profit motive like all business doesn’t lessen the positive social impact its operations are having. There may be fewer of such companies around compared to companies with neutral or negative social and environmental impact but they do exist.
• Learning that B-crops are becoming a thing. It’s a certification that evaluates "company’s operations and business model impact [on] workers, community, environment, and customers." Further along the lines of the notion that profit motive needs not be in direct conflict with positive social and environmental impact. There’s even job boards for B-corp-only jobs.
• While I consider my company’s impact to be net positive, I do make apps and enjoy that work immensely. I’m aware that our products benefit those who can afford a smartphone or an computer with internet connection which still leaves out many folks who arguably could use help the most. I do my best to keep myself exposed to these issues in my local community and help where I can. Many folks for whom keeping up with what local governance is doing about issues isn’t enough choose to engage by becoming public employees, working directly in government, or working at non-profits. Of course, these are all individual choices. It’s unreasonable and counterproductive to expect everyone to be a teacher or a doctor. But we can all be engaged citizens, doing our civic duties, starting with our own communities.

The industry would benefit for having a self-reflective individual like yourself around. Cheers!

I’d second the sentiment that the example above might be doing too much within a single prototype. There probably are ways, some of which you suggested to break it up into several simpler things.

How do you layout screen flows…

The first stage usually looks like this:

That’s just to get my mind thinking about the problem. Once I’m ready to to get more specific, and consider variations and alternatives, it starts looking a bit tidier. What I’m doing is a tad more elaborate variant of Ryan Singer’s "shorthand"

If I need to get feedback from others, or present to the team a plan for what we’re doing, I’ll clean that up even further and make it legible for folks using Illustrator (though I imagine Sketch, OmniGraffle, and many other tools might serve you just fine. I once did this in Google Drawing, not that I’d recommend that):

At times, I might do a wireframes that will (literally) cover the corresponding boxes (pages/screens) in that flow diagram if the in-page interactions are complex or if I’m divvying up the work with other designers. Other times, I’ll skip the wireframing and go from the flow diagram to full-fidelity mockups:

… with different states and variables? Do you now any particular tool that helps lay out and structure screen flows for different scenarios?

I find it tough to communicate to others 1) the flow and 2) all the states of each piece of the flow at the same time effectively. I’ve found it more effective when the flow diagram communicated primarily, well, the flow, annotating varying states as a secondary thing. I usually lean on diagramming the happy path in the flow, and then noting down below each screen that it exists in a couple of different states, showing those states if space allows. You might create two or more flow diagrams of the same flow, one showing the "happy path," and another the same set of screens but in different states. Usually, I find that only a couple of paths through the flow are important enough to diagram explicitly.

I’ve found this to be effective inside small, agile product teams that are tackling novel problems. Everyone’s environment is different and, of course, your mileage may vary.

Doing this in Sketch takes so long to draw paths and make it presentable and in the end its not very useful to experiment and consider different flows, while changing the steps etc

Personally, I don’t see all that much value in fussing with arrows and connecting lines once things are mocked up in Sketch. By the time full-fidelity mockups arrive, the team members are usually already aligned and have hashed out the common use cases and internalized happy paths and edge-cases. You’re right, connecting mockups with arrows is time consuming and it can get in a way of experimentation and speed of generating different ideas. Doing that is so much easier with my Rotring 500 and 2B leads ;)

I think The Elements of Typographic Style by Bringhurst is a great way to start.

If that feels too historical (thought that’s a bit like saying "if basketball feels too sporty…"), I highly recommend Type & Typography by Baines & Haslam.

Another option is Keynote Live feature of Keynote but it obviously adds a deal of overhead.

I wish Sketch Cloud had the ability to put comment markers directly on the layout and that it allowed for measuring dimensions by hovering with the cursor. To me, that’d be closer to one-source-of-truth compared to having to use the plugin to manually sync a Sketch file to third-party service.