Mastery of None: Conveying your software problem with a particular piece of software.
When i graduated with my masters in human computer interaction in 2007, i felt very confident in my problem solving abilities with people and software. I grew with a father who had written books and started his own company solving manufacturing problems with statistical process control. I was much better at the people problem solving side than solving with SPC, but i could understand and apply the basic elements this method taught. When i started working in the user experience field i was always amazed at what some people could produce for a deliverable in a particular software application. People in meetings would be so impressed with what X employee did to solve what we thought was the software problem and possible solutions. While i was working at various companies i had very high anxiety about not having or adopting this proficiency with the particular software they used to produce deliverables. I thought maybe i just need training on the software and then i can produce these “shiny deliverables.” I spent hundred of dollars of my own money or sometimes company money on these video or in-person software training. I would ask family and colleagues what i was doing wrong, maybe i am not the right person for this job? During some self-reflection and after quitting numerous UX jobs and talking to former colleagues i discovered two main things:
- I am better at describing a solution or what people think is a solution verbally and by sketching to support my talk (sketching on the fly.)
- Unconsciously or call it intuitively i read a user story, spec doc or software screen and say “why are we doing it this way? and how does this tie into project, user and business goals?
Just to clarify, people might read that i prefer to sketch on the fly and might interpret that as maybe i can draw comic strip type of wireframes that looked like storyboards from a film production. I can draw basic stick figures and boxes to illustrate a point. Many times this “Quality” of deliverable in a company environment is not acceptable to give to a client when they are paying 100,000 dollars + for them to help you. What i discovered many years down the road was colleagues were being forced to justify or rationalize these “shiny” deliverables because of a company process of doing business. They had this elaborate software problem solving process that they sold to a client or maybe it was so simple and clear people believed they could be helped because their process was so clear.
Many of my colleagues got so good at these applications that i believed they thought they are actually software problem solving rather than producing a “shiny” deliverable that looked REALLY nice from a visual and functional standpoint but 80% of time was not telling the story the client NEEDED or WANTED.
After starting my own company and freelancing i discovered many people when approach with clarifying of what their story is all about and then finding vehicles or deliverables to explain that story seemed to NOT care if you delivered them a stick figure or a “shiny deliverable” just a long as you gave them something they NEEDED and WANTED.