Building a Designer
A 30 Day Training plan that takes new hires from level 0 to being fully fledged product designers
Results
-
5 Modules
Each going over a specific aspect of product design
-
3 Designers
Trained, from various Air Force Careers to product design
-
30 Days
The average time it takes to complete the course
Background
As an exploratory effort, Team Cylon asked for Airmen from various career backgrounds to do jobs that were typically outside of their career field. While the 3D0X4 (now 1D7X1Z) did exist for software developers, there was no accurate analog of product design in the list of AFSCs. Because of this, it was my responsibility to teach Airmen onboarding as designers how to use tools (such as Figma and Miro) as well as UI/UX Design fundamentals.
I defined the success metrics of this course as:
New hires are able to freely use Figma and Miro
They understand Team Cylon’s design process
They are able to apply good UX methods and research
When new designers were able to do this, I would know that my curriculum was a success.
When I initially created the course material, it was rigid and inflexible. It didn’t truly allow for the creative expression that many designers take for granted. It presented the information in a way that was similar to a lecture at a university. A lot of talking AT someone. This is evident by the use of informational cards.
Of course, some things did need an info dump. For instance, many Figma actions required a simple “this is how this is done”
Design Systems
Design Systems were something that Team Cylon uses every day, so it was important to dedicate a whole module to them. I used Nathan Curtis’ definition of a design system as I felt it was one of the more robust, yet concise answers out there.
As a designer, workshops are an incredible way to connect team members and come to a common ground and organically figure out as a team, what is good for the user, technically feasible, and fulfills business needs.
In my effort to bring an air of empirical credibility to the design field, I first attempted a rigid approach to design studio facilitation, as I believed this to be the best possible way to present the information. This did not produce the wire frame brain storming outcomes I was expecting:
Granted, the person who drew the angry bear was about to be forcibly transitioned off the team, but I can’t help but feel like I could have added more layers of abstraction to the problem space to gain more helpful answers.
The abstraction of the problem space would definitely have helped with our other participant, as they were also distracted by the other member getting pulled from the team.
What I would have done…
I can’t really place blame on the participants, as facilitator it was my responsibility to make sure people were engaged and involved in solving the problem.
An alternative approach such as abstraction mentioned above, or another workshop and realignment on goals could have proven to be useful here.
Our final excursion was to simulate everything we’d learned so far in a capstone environment. We called it “Project Buckshot” and the problem space we started with was:
Well-written bullets have an incredible amount of influence on an Airman’s career. Bullet authors rarely get adequate feedback on their work making it difficult to improve, or worse, masking the need for drastic improvement.
We got this prompt from the Wing’s innovation “spark tank”, which took innovative ideas from across the wing and had people pitch their solutions. The proposed solution was as follows:
A web-based platform and back-end database that allows for bullets to be anonymized, reviewed, and scored (e.g. EPRs, 1206s, etc) and for the Reviewer’s remarks and grades to be anonymized and sent directly to the author. (Please see the attachment for additional details and functions).
For context, Enlisted/Officer Performance Reports (EPRs/OPRs) are an integral part to and Airman’s career. They make sure that the Airman is progressing and growing. EPRs layout an Airman’s key duties, and how they preformed those key duties, and whether or not they met, exceeded or did not meet the standards expected of them. The way this is currently done (though they are changing the system) is through a bullet style of feedback. This allows commanders and senior raters to easily view a lot of EPRs and sign off on them, while getting the gist of what the Airmen did and the impact of their actions. That being said, weird cultural quirks have arisen in the bullet writing process. Such as:
Bullets should only be one line
Bullets are formatted with acronyms, mathematical symbols etc. all to fit on one line
Bullets should say the maximum impact from your actions
Bullets should fit exactly on one line, there should be no negative space between the end of the bullet and the end of the page
More examples of bullet formatting, as well as Do’s and Don’ts can be found in AFI 36-2406. But generally, bullet crafting is both an art and a science, These same bullets are used on more free form documents, such as the AF 1206, a form usually submitted with award packages.
We first needed to validate our problem space, and make sure this was an actual product people would use (even if it was simulated.) To do this, we conducted internal meetings with the team, asking about their issues/takes with the bullet problem. I also got to show off my acting chops by pretending to be various end-users. We received valued feedback on the process which we were then able to document and utilize when creating our personas and solutioning.
Typically, I’d stay away from role-playing end-users, but in this scenario, we didn’t want the idea to get out that this is the project we were working on.
Brainstorming questions for various end-users
Empathy Mapping for front line supervisors
Answers from some Users we interviewed
Needs and pains from Airmen, front line supervisors, flight leadership, and squadron leadership
After we synthesized the needs and pains, we turned those into personas that would then drive feature creation (if this were an actual project)
Carrie Smith was our next persona, and she represents the front line supervisors who are the ones primarily responsible for drafting up their subordinates EPRs
John Newman is the persona that embodies, essentially, squadron command. This person also wants to make sure that Airmen’s EPRs help their careers, but also needs to make sure all the deadlines are met with the appropriate systems. One thing that bugs john is that after edits, EPRs become unintelligible.
Our first persona was Peyton Holloway, an Airman who needed her EPR completed. She doesn’t know a lot about the bullet process, and doesn’t really need to.
Our next persona was Maria Hernandez, who had gone through the EPR process multiple times, and is there to make sure that EPRs help Airmen’s careers, as well as providing feedback to front line supervisors EPR submissions
At this point we were on our way to start solutioning using the “How Might We…” methodology, however our feature creation for Trackmeet took precedence, so we pivoted our training to be hands on with trackmeet. Regardless, these are the HMWs that we would have answered.
This training was definitely an experience for me, I tried to keep it very rigid, and didn’t allow fro very much flexibility. However, product design should be flexible, and so should teaching it! I should have been more flexible with the issues that the designers I was training were bringing to the table.
Key Takeaways:
Listen more
Be flexible
Learn through creation, not dictation
I’m happy that I got to train designers, both on the technical and the process. Seneca once said, “While we teach, we learn” and this was a great opportunity to learn design concepts through the eyes of someone who’s never seen UX before.