You Don't Know What you Don't Know

This keeps coming up lately and I think it’s an interesting concept. Making informed decisions implies yre informed. When trying to solve a problem, I have to understand the problem, the possible solutions, and also usually the context in which the problem sits. That’s a lot of learning, but it can be done most of the time. If I’m laying out a web site and I want to separate two areas with a line, I dig around the web and decide to use <hr>’s. There’s my problem and my solution. By styling <hr> tags is inconsistent, so when I move onto the CSS, I need the larger context of the browsers and maybe some knowledge about SEO. Now what I need to know is much larger and more vague.

The wildcard that makes this scenario really hard is other people. In the above example it’s just me against the web. The more common scenario is when a boss or client hands you a project. They have expectations, and that’s a scary word. They may do a great job laying out the requirements (a.k.a. the problem) and your knowledge and experience may perfectly fit (a.k.a. the solution), but, man, if they leave out one little thing, or you happen to be checking Twitter when they explain one small detail, it can be disaster.

Here’s my short list that I use when taking on someone else’s problem: Pay attention. Ask lots of questions. Ask them again. Take notes. Do planning, wire-framing and iterations. And over communicate while yre working.  At times it feels unprofessional, but better safe than sorry.