Victory comes from everyone sharing the same goals.
– Sun Tzu, The Art of War
In parts one and two of this series, we gave a general overview of the signals intelligence (SIGINT) and electronic warfare (EW) domains. Now, we need to bring this information into our design process so that we understand our users’ goals and keep these at the forefront of our design. We do this by developing personas, which are archetypal depictions of the end users of our system. Each persona represents an end user with goals, motivations and frustrations. It is meant to represent a larger demographic of users. Personas often include a name and photograph and contain a mix of personal and professional information.
This blog will describe the need for this persona, how the environmental factors we discussed in part two affect this person, and how we can use publicly available knowledge to fill in some of the blanks, reducing research time and costs. Finally, I will provide two examples of personas we use at CRFS to shape one of our software projects.
Why do we need personas?
In terms of UX, personas are used by designers and engineers to develop empathy for the end user. But, why is empathy important in business terms?
First, understanding and empathizing with end users helps develop better hardware and software. For businesses, this means conversations are more likely to turn into purchase orders, because a product that meets a customer’s requirements in a straightforward manner is far more likely to be purchased.
Second, understanding and designing for end users makes users feel respected and garners brand loyalty. In sales terms, poor UX means follow-on orders will only happen until a more user-friendly product with similar capabilities comes along. Positive UX creates a strong brand reputation that builds longevity and expands a customer base.
Third, designing with empathy saves money over the long-term in support costs. Building a product that works smoothly and correctly decreases the volume and length of support calls, thus cutting down on follow-on overhead. This frees up more resources that can be fed back into the development lifecycle.
Everyone involved in a product, from its design to its application, is a person, and people are often limited to their own individual perspectives. When many personal viewpoints combine with varying levels of passion in a design team, the final product can deviate from what users want and need. This is the problem when development occurs inside of a funnel.
Designing products for the Electronic Warfighter is even more challenging, as there is an even smaller chance that the engineer or designer has had an opportunity to experience life in the SIGINT or EW fields. This is why developing a primary Electronic Warfighter persona can be so beneficial: it can help designers and engineers develop empathy for end users, anticipate user frustrations, and devise ways to improve user productivity, whether or not the developers themselves ever meet an actual end user.
It’s easy to grumble about and even ignore those who will use our products, but these behaviors can be a red flag that a product has issues, rather than (or not just) the user or users. The biggest pitfall I see in SIGINT product development is the mindset of, “Well, I’m an engineer; why isn’t my end user an engineer? If they cannot perform a task that is simple to me, then maybe they should go back to school.” This attitude is like a neon sign indicating that no consideration has been made for the end user, that no frustrations have been addressed, with possibly more added, and no attention has been given to aiding user productivity.
Personas make users real. To be truly effective, a persona must seem like a real person, not a number on a spreadsheet or a check in the box. It should demonstrate a user’s human-computer interaction (HCI), according to current, actual workflows, whether this involves the product(s) in question or those of competitors, including any outside tools and resources that form a part of these workflows. And lastly, a persona must be focused within the scope of the product’s domain, in this case, SIGINT and EW.
Using public domain knowledge
Personas made for general commercial products can go into great detail regarding a person’s background, such as their employment position, title, salary, educational history, etc. For SIGINT and EW users, we can start to answer many of those questions using publicly available information related to the military, including its unclassified training manuals and potential training pipelines for Electronic Warfighters. Such information includes:
Military personnel are on call 24/7 and generally work more than 40 hours a week. Based on SIGINT and EW domain characteristics, these working hours are not set.
Level of responsibility and expertise
Rank can indicate how many subordinates an individual is responsible for, as well as the level of expertise and authority that an individual may possess, but this is not concrete. However, asking end users about their daily routine will likely reveal this information.
The minimum age to enter military service, at least in the U.S., is 17 years of age, but the maximum age of entry varies for each military branch, which can be found here. This serves as a good starting point for target user demographics.
For users in the U.S., there is also a general knowledge and educational requirement known as the Armed Services Vocational Aptitude Battery (ASVAB). Each military service has its own minimum ASVAB scores for SIGINT and EW operators, along with any additional testing requirements. Both of these career domains tend to have high requirements, so it can be assumed that most operators will have a reasonable aptitude for learning.
At the very least, these individuals will have undergone basic training and specialized job training. General descriptions of this training is publicly available. For example, a high-level generic description of the US Navy’s cryptologic programs can be found here, providing a number of search terms that can assist in detailed research.
The final personas
Based on the knowledge we have collected above, as well as additional information from personal experience and user interviews, we can make two personas, a primary and a secondary persona. For one of our SIGINT software projects, the primary persona is our novice user, because there are generally more novices or intermediate users than experts on any given SIGINT mission. Our subject matter expert is, however, a secondary user.
You will notice that each persona has a name and a face to build empathy for our end users. A project manager from a major software company once told me that her engineers would keep a copy of their projects’ primary, secondary and even tertiary personas at their desks. Whenever they had a design decision to make, they would refer to these fictionalized users as if they were real people: “This would really help solve Larry’s vision issues.” “This sounds great and all, but I don’t think Sunil would like this convoluted workflow.” This dialogue helps center design decisions around user goals, needs and frustrations.
Each persona also has several categories, such as basic career data, responsibilities, challenges and frustrations. This gives us a nuanced view into how our core users operate in their day-to-day and longer-term tasks. It helps us zoom in on factors that can and should affect our product design. For example, a distracted end user may require clear signposting and an intuitive layout to minimize time lost. We will discuss these in greater detail in the next blog.
In summary, personas help build empathy for the end user. This makes sense not only from a user satisfaction standpoint, but also financially. Personas can often be built using information online and complemented with user interviews and any personal experience in that arena. CRFS often uses a primary and a secondary persona, each with a name and a friendly photograph and relevant information on the drivers and frustrations for each type of user. When implemented successfully, personas can take on a life of their own, helping drive smart business and development decisions that positively impact everyone in the product lifecycle.
Stay tuned for part four, where I will explain how we can best utilize these personas to glean the maximum benefit for both user and producer.
About the author – Eric Famanas
Eric J. Famanas is a Senior Software Engineer specializing in UI/UX-informed web application development using HCI and behavioral analysis. Before joining CRFS, he served as a SIGINT specialist for the U.S. Armed Forces, where he led SIGINT mission teams and trained hundreds of personnel in SIGINT equipment deployment and tactics.