Teaching soft skills
John D. Martin IIIFebruary 1, 2017
Lisa Hinchliffe (@lisalibrarian) tweeted this morning about training and hiring for all skills rather than just technical skills.
Training and hiring for all the skills not just technical ones. https://t.co/4SEJGL4eMx
— Lisa Hinchliffe (@lisalibrarian) February 1, 2017
From the linked article by Seth Godin:
Along the way, we’ve confirmed that vocational skills can be taught (you’re not born knowing engineering or copywriting or even graphic design, therefore they must be something we can teach), while we let ourselves off the hook when it comes to decision making, eager participation, dancing with fear, speaking with authority, working in teams, seeing the truth, speaking the truth, inspiring others, doing more than we’re asked, caring and being willing to change things.
This brought back some thoughts I've had recently about students' expectations in some of the courses that I've taught.
They want a lot of information about what will be done up front. They want to be taught specific technical skills so they can put them on a resume. They want to have a path laid out before them and be able to go along it, checking the boxes as they go. They want to do work and receive a grade and get a degree and get a job, and so on. Of course, not all students want this, but we have structured our institutions such that they often expect these things from us as instructors, whether any of us knows that is happening or not.
The problem is that the world doesn't really work like this. We usually have to find our own way through, and no set of technical skills will help with that without the second half of Seth Godin's list above.
We are not teaching (or encouraged to teach) how to work through problems, how to collaborate, or how to figure out what skills you need and then go about getting them.
An alternative approach
I am teaching a user interface design class this semester. I decided to experiment and try to overtly teach "soft skills."
Instead of lecturing from a bunch of readings and teaching them technical skills, the whole course is organized around planning and executing a single semester-long project.
The first week we discussed collaboration and social design, and then had a comprehensive crash course on using GitHub by my colleague Elliott Hauser. The 2nd week, we talked about the complexity of the design process, and then collectively used a "design charrette" to come up with a plan. This week, we discussed ways to research users, and then will start making user profiles on Thursday.
Tuesdays are discussion days for which there are assigned topical readings. This doesn't mean that discussion days are not interactive. Yesterday, we watched the first 15 minutes of Alfred Hitchcock's Read Window (1954) and critiqued it as an example of how deliberate choices can be made to craft an experience that will be different for each indivisual viewer (user) but will engage them all in similar or overlapping ways. One student pointed out that the window shades going up during the opening credits was like a progress bar. It subtly told the viewer when the credits would be over.
This activity was inspired by Luke Miller's mention of the film in the opening chapter of his book, The Practitioner's Guide to User Experience Design. It led to a good discussion about ways we might understand different users perspectives, needs, and expectations.
Thursdays are work days during which we actually do some part of the project all in the same space together. This week, we will have a live demo of the platform that is the focus of the project. Students are going to get to interact with hardware and actually try out an existing software environment. More on that later.
During Elliott's GitHub tutorial, everyone got to create files, make commits, and create pull requests. We also learned about using GitHub's social layer to coordinate and assign tasks to individual developers of groups.
In the design charrette, they self-organized into teams based on what they were skilled at and interested in learning more about. The teams are things like: programming, visual design, interaction design, branding, documentation.
Through this process, and throughout the course, we're going to continue discussing collaboration, workflow management, leadership, organizational skills. My aim is to have them become comfortable with many of the aspects of large team project management that they would not have otherwise.
Everyone works together
I could have had all of them select a project and do a critique and redesign. I have 20 students. This would have been an immense amount of work for me as the instructor and the focus of evaulation would be on the content of their projects, rather than on how to work and think.
With this approach, they will learn to work through development with a large team AND on a real project. I recruited a "resident entrepreneur" for the class: Erica Young, founder of Raleigh Dynamics, a startup specializing in amplifier hardware. She is an electronics engineer who is working with Software Defined Radio (SDR) and wants to expand the market for these devices.
SDR is HARD for novice users. The project for this course is to design and build a plugin for GNURadio, an open-source SDR programming environment. The aim for the plugin is to walk users through setting up an SDR using direct manipulation and showing users how one setting affects the others. The most difficult part about using an SDR is understanding the tradeoffs when selecting setting and building a network.
The best part about all of this is that none of the students have any experience with this. So like most UX projects, an engineer came to them with a bunch of requirements, requests, and desiderata in a completely unfamiliar space. They will collectively, collaboratively work their way through the process. I'm just there to facilitate that process.
None of the grading for the class is related to what they do for the project, but rather how they do it. It's all self- and peer-evaluation. My aim is to create a design team instead of a class, which then makes the course about working on a design team, linking back to theory.
Will it work?
I hope it works. It's going well so far. It's a little scary (for both me and students) to have such a wide open plan.
But this is what the world is actually like. No one spoon feeds you in real design projects. You just have to dive in. I'm just trying to make sure that we all dive into the deep end AND keep swimming once we're there. The best part is that students are responding by showing up with ideas, suggestions, plans and they are not afraid to talk about them.
And we're only really in the third week. I can't wait to see what they do by the end of the course. It's going to be interesting, regardless.
The syllabus lives here, if you're interested in looking at the readings and project outline: https://inls718.johndmart.in
This post was inspired by a Twitter thread on the topic.