PART TWO: BREAKOUT GROUPS

Dissecting the Design Sprint Event

PART TWO: BREAKOUT GROUPS

AF CyberWorx design sprints are tailored to the needs of the stakeholders. One crucial aspect is the number and diversity of participants in the group. Events at AF CyberWorx can have as few as five people and as many as forty or fifty. In each group, dynamics are determined by individual personalities, experience with the problem area, and strength of opinion as well as rank and positions (and perceived deferment to such). Each element may affect how people interact with one another.

However, each event is very short. The typical forming, storming, and norming growth of a group needs to happen as quickly and painlessly as possible while still gathering as much information and as many ideas as possible. The answer to this is to break a larger group into smaller diverse teams of four or five people.

Ideas are the meat of the problem-solving process. Ed Mikos, UX Design Analyst at AF CyberWorx, explains that “the information that’s created and captured [during an event] is going to be built on in a series of expansion and contraction steps leading to one final outcome.” In each step, ideas are generated from the group to expand potential. Those ideas are then vetted to contract focus down to the best, most impactful ideas that will push problem-solving efforts further. A team needs that pool of ideas to find which are the best.

Breaking the group into smaller focus teams gives everyone a voice. Ed states, “Everyone in the group brings something to the table.” Each person in the event is there for a reason and has good ideas from a different perspective. Smaller groups composed of diverse people takes out the possibility of a single, strong voice speaking for their peers in a larger crowd. Position becomes less of an issue when the higher ranked person is in a different group. The senior airman who actually uses a program has equal voice to the colonel who oversees the management of a similar office.

Another benefit of breakout groups comes when the groups return from a session and share their findings. Sometimes more than one group will have the same or similar ideas. That’s O.K.! Ed says when the same idea comes from multiple groups, “there’s probably something there [that needs to be explored].” Instead of being repetitive, the multiple groups reinforce each other, giving consensus and higher strength to that idea.

Groups increase idea generation, break down group dynamics to give everyone a voice, and often generate consensus faster than a large group as a whole. With those three benefits of breakout groups, Ed gives some key points for participants to remember when they move into the smaller focus groups during an event: “Everyone in the group brings something to the table. There are no bad ideas. Trust the process.”

He goes into more detail on some of these by explaining that “When someone is locked on an idea or someone is being too negative, like saying ‘Why are we doing this?’…that negativity is infectious.” Being a champion for your own idea is fine; that idea may be validated. However, keep an open mind. Each member of a group has a unique perspective and adds to the quality of the end product. “Allow for diversity of ideas…people come up with different ideas and know what the different feasibility and technical and organizational shortcomings will be.” When a diverse group works together with a positive attitude towards the process, the entire problem-solving team improves.

For those who are still hesitant to speak up or grab a marker and add their ideas, Ed reassures that “no one cares how good an artist you are or how eloquent you are. We need your ideas. You’re in the room for a reason.” Each idea adds to the whole. Each group’s findings add to the quality of the event. Every participant who speaks up adds valuable feedback that ensures a quality end product.

To assist the problem-solving team, AF CyberWorx provides experienced facilitators to encourage breakout teams to participate and stay on track. We know time is precious during a design sprint and how valuable each participant’s voice is in the group. Speak up and allow us to help you find the best possible solutions to your unique problem.

*The postings on this blog reflect individual team member opinions and do not necessarily reflect official Air Force positions, strategies, or opinions.

PRE-GAME PART ONE: DISCOVERY CALL

Dissecting the Design Sprint Event

PRE-GAME PART ONE: DISCOVERY CALL

When AF CyberWorx gets a request to run a design sprint, it’s like kicking an anthill…without all the biting that follows. There’s a series of meetings scheduled, logistics starts plans to make everything run smoothly, and team members are selected. One of the most important pieces to this initial organized scramble is the discovery call.

Dr. Dan Padgett, one of AF CyberWorx’s excellent user experience designers, describes the role of the discovery call as letting the facilitating team get a glimpse of the situation. This glimpse allows them to get into the stakeholders’ minds a little. As he explains, “At the end of the day, as UX designers, we’re not the subject matter experts in the field, so we need to try and understand as much as we can so that we can effectively plan for the problem solving session, whatever form that might take.”

The forms an AF CyberWorx event takes can be from a full five-day problem solving and design sprint to a simple site visit. The discovery call narrows down how long the process will take and what needs to be done.

One of the big pieces the team tries to discern is how solid a problem statement the stakeholders have. As Dr. Padgett explains, “If through a discovery session, we feel like we’ve got a really good handle on the scope of the problem and what they’re actually trying to solve, then we might do a lot less on the discovery portion of the design sprint.” The first day of an event is taken to refine the problem. How long the team spends on this exercise depends largely on how thoroughly the stakeholders have explained their situation and what they want to improve.

Paired with that is the need for clear goals. Everyone has problems, but fewer know what they want the end state to look like. “We want the problem to go away,” is not a goal. “We want the system to improve,” is not a goal, either. A goal needs to be actionable and measureable. The clearer the desired end state is, the more focused a problem solving team will be.

A piece of information that most people don’t think of is the understanding that not all AF CyberWorx team members are well steeped in every cyber career field. We don’t always understand the jargon. As Dr. Padgett describes it, some calls are extremely technical. The experts are on the line and use “acronyms without ceasing.” In the case that our team does not understand,the biggest help is to know what the acronyms mean and pass on that information early in the process. The discovery call is what shapes the overall event. It gives the team at AF CyberWorx the information it needs to build an event that will have the greatest impact. The best way to make the event as successful as possible as early as possible is for the discovery call to go well. Dr. Padgett explains some items to get the most out of discovery calls:

  • Provide enough time before the event that an AF CyberWorx team can make a site visit. Seeing the work environment and the job actually being performed by the users themselves always gives information that someone used to the environment won’t recognize as significant.
  • Ensure the right people are on the call. Stakeholders are important, yes; but having some of the users that experience the pain points normally adds more practical information.
  • Know who the stakeholders are and who the decision makers are. They aren’t always the same. Knowing who will receive the information to make the final decision helps ensure that the final products are designed for maximum impact.
  • Provide concrete information. Who are the users/customers of the system in question? What process/product/challenge is needing improvement or a solution? What are your goals?
  • Exploring the situation and asking questions are part of every discovery call. Come with information and have people in the know on the call so the facilitating team can get a clear picture of what’s going on.
  • A high-level comprehensive picture is more important than a detailed breakdown of the process. The detailed work will go into the event.

Ultimately, the discovery call is an introduction to the problem solving event. It shapes it, defines it, and prepares the AF CyberWorx team to guide a team of experts through the problem solving process. Information goes both ways. We also explain expectations while we’re gaining information. We aren’t the experts on the problem, but we are experts at guiding others through solving their problem. Help us help you.

*The postings on this blog reflect individual team member opinions and do not necessarily reflect official Air Force positions, strategies, or opinions.

PRE-GAME PART TWO: EXPECTATIONS

Dissecting the Design Sprint Event

PRE-GAME PART TWO: EXPECTATIONS

“Our thoughts about an event can have a dramatic effect on how we go through the event itself.” –Martha Beck, life coach

Any time a group of people are about to embark on a new goal, there are expectations. As much as motivational quotes talk about having no expectations, they still exist in one form or another. A major part of the initial event planning is expectation management. Stakeholders have in mind what they think AF CyberWorx can do and will do. At the same time, the facilitation team has specific things they hope the stakeholders and participants will do. Sometimes the mystery continues on until the event itself. We hope this blog will work towards solving that mystery by setting realistic expectations.

When stakeholders request an event, they know the status quo is not working. They and the users they represent all have ideas of what might “fix” everything. Dr. Dan Padgett, a user experience designer on staff with AF CyberWorx, explains that the facilitation team does not “validate solutions they’ve already thought of.” Instead, they help with a process of thinking differently that gets the team to an answer. The key word being process. A problem solving event does not start with the solution. That being said, some participants and stakeholders come with the expectation that the AF CyberWorx team is going to either provide the answer to their problem or enable the idea they already have.

Vel Preston, Head of Innovation Design, explains it this way: “You scope a problem one way, and a lot of people come to the sprint who haven’t had the same background with new ideas. The group decides, ‘Well, we hadn’t considered that. Maybe we should scope this differently than we thought.’” The process AF CyberWorx guides event participants through leads experts and industry partners to refine the problem and find an impactful solution.

What the team thinks they’re going to fix at first may not be what needs to be focused on. Larry Marine, Lead UX Designer, explains why it’s necessary to lead participants away from their initial expectations as soon as possible: “Folks come in with a strong tendency towards the symptoms without fully understanding the problem.”

That being said, the facilitating team members are also not subject matter experts themselves. As Dr. Padgett says, “sometimes it takes participants a bit to realize that we’re there to facilitate the sprint, and that we’re not SMEs ourselves.” As designers, their specialty is facilitation and guiding teams to consider the user experience in their own designs. They are not experts in every field, nor are they experts on exactly what the stakeholders need to fix their problem. That’s why a group of experts from the field are brought together to solve the problem.

What AF CyberWorx cannot do for stakeholders is solve their problem. They will not immediately verify initial solutions before the process is followed, because they don’t know the current system well enough to say “yea” or “nay.” What we can do is assist a special focus team towards finding a desirable and feasible solution. We can provide facilities with a workspace, tools, and facilitators to make problem solving easier. We also provide networking with industry partners to broaden the knowledge and capabilities of the DoD talent pool. We facilitate improvement and growth, but the subject matter experts in the field are the real heroes that do the work.

Of course, expectations go both ways. Jayleen Guttromson-Johnson, Program Manager, lays out the AF CyberWorx expectations succinctly: “We expect full-time commitment while [participants are] in the design sprint. No email, phone calls, or disappearances. Also, be open to living with the uncomfortable. Our process isn’t like what most people are used to, so just trust the process.”

Stakeholders request AF CyberWorx facilitation and capabilities. We’re here for the team’s success. Let us help turn problems into solutions that go beyond simple expectations.

*The postings on this blog reflect individual team member opinions and do not necessarily reflect official Air Force positions, strategies, or opinions.

PRE-GAME PART THREE: PROJECT LOGISTICS

Dissecting the Design Sprint Event

PRE-GAME PART THREE: PROJECT LOGISTICS

What do hotels, food, security, and video recording have in common? They’re all part of the chain of logistics that happens behind the scenes before a successful event. The AF CyberWorx logistics guru is Cheyenne Ellis. She does more than just gather and send out a hotel list and coordinate access badges and video recording of the event outbrief. She also lines up transportation into the secure location where events are held, builds baskets with supplies for each breakout team, coordinates with our support team for food delivery, ensures buildings and elevators are accessible, and a myriad of other small details to let participants and the team focus their energy on the problem being worked during the event.

For her to be successful, though, she needs the cooperation of stakeholders and participants involved in the event. She says the most important thing she needs is for participants to fill out the requested information as quickly and accurately as possible. Otherwise, she may be unable to help, constrained by security or other deadlines. “We’re very strategic on what we ask for. We’re doing this because we need to.”

The place to give information is through the portal every participant is directed to at registration. The information provided allows Cheyenne to acquire security badges, lets her know if there are any food allergies (or preferences), as well as gives contact information in case there’s a last-minute change or weather issues to ensure participant safety and comfort. Without the proper information, we can’t get you on base, get you access badges, and through security to attend the event.

It’s critical that participants read the information they’re given before arriving on base for an event. It may involve what to bring (and not bring), base visitor hours, directions to the parking area, shuttle transportation, and how to navigate the maze of hallways to AF CyberWorx.

For stakeholders, the most important thing is to be involved and responsive, even if they are unable to attend the event. The best results happen when stakeholders give fully fleshed-out directions including their goals and a fully formed problem statement. Not only do these give the problem-solving team direction, they keep the stakeholder in the loop with what’s going on. The stakeholder is a critical part to shaping the way forward to a solution. Having involved stakeholders helps the event run smoother from the beginning all the way through approving implementing changes identified by the project teams.

AF CyberWorx does as much work behind the scenes as possible to make a design sprint run as smoothly as possible. Without cooperation from participants, however, that work is difficult. Be prepared with your end of the logistics and we will be that much more effective at designing a solution!

*The postings on this blog reflect individual team member opinions and do not necessarily reflect official Air Force positions, strategies, or opinions.

ADD NEW COMMENT

PRE-GAME PART FOUR: PARTICIPANT ROLES

Dissecting the Design Sprint Event

PRE-GAME PART FOUR: PARTICIPANT ROLES

Many moving pieces go into a successful design event at AF CyberWorx. Each person has a specific role to play: multiple roles, in some cases! While the most visible roles are the participants and the facilitator at the head of the room, the magic wouldn’t happen without everyone involved.

Stakeholders: Each event begins with a stakeholder. Some events have more than one; but the role is the same: to provide direction for the event and everyone involved. They know what the problem is, why it’s a problem, and what the end goals are. Without an involved stakeholder, the event is missing the backbone that provides structure and focus for the entire event.

Decision Makers: The decision maker isn’t always a stakeholder, and doesn’t always need to be 100% involved. When the decision maker controls funding and manpower, but doesn’t operate in the area on a day-to-day basis, they rely on the stakeholders to brief them about the event findings to decide on the areas to support.

Participants: As one of the most visible roles in the design event, participants are the vehicle for shaping the magic. They fill the problem solving process with relevant information and experience to arrive at unique solutions to the stakeholder’s problem. Nearly all participants are hand-picked because they can give the most benefit to (and benefit from) the event. The greatest impact participants make is being engaged as early as possible all the way through to the final outbrief.

Industry Partners: Non-government participants play an important role in an event, as well. AF CyberWorx invites industry specialists to join in problem solving according to their expertise. They provide key insight into the commercial world’s capabilities and direction of growth. The additional knowledge and experience they bring to a design sprint expands potential solutions beyond many current government abilities. They also add a diversity to the group that helps break down traditional military and organizational barriers to increase team effectiveness.

Facilitators: The other highly visible role in an event are the facilitators. They come in two flavors:

  • Strategist: The strategist is usually, but not always, the lead facilitator. They take the information the stakeholder provides and determines the structure of the event. Depending on how developed the initial problem statement is, they may spend more or less time on refining the problem or devote more time to having the subject matter experts fill in missing information. The strategist determines the general shape the event will take before the participants even finish registering.
  • Facilitators: There is the lead facilitator, who leads the problem solving team, explains activities and times breakout groups, and guides the entire event according to the plan the strategist outlined. The other facilitators provide support to both the problem solving team and the lead facilitator. They field questions, act as the eyes and ears of the lead facilitator, and ensure breakout groups have the support they need through information and materials. Most, if not all, of our facilitators are professionally trained UX designers.

Project Management Team: The project management team provides the support behind the scenes for the event. From logistics to security, access to secure facilities for classified information, and everything in between, the project management team works to ensure the minutiae are taken care of to let the problem solving team focus on the event.

Customer Relationship Owner: Last, but certainly not least, the customer relationship owner ensures that everyone involved gets what they need out of the event. The customers include the stakeholders, the industry specialists, the decision makers, and the organizations involved. They continue working even after the event is finished to connect industry and governmental organizations to make working towards a solution as viable as possible.

AF CyberWorx believes in the full concept of seeking and implementing improvement. The entire team works in their respective roles to best support finding and implementing solutions to the best of our abilities. Together, we can support the continued growth and superiority of the US Air Force in a rapidly evolving global theater.

*The postings on this blog reflect individual team member opinions and do not necessarily reflect official Air Force positions, strategies, or opinions.

STEP ONE: REFINING THE PROBLEM

Dissecting the Design Sprint Event

STEP ONE: REFINING THE PROBLEM

The first step during a design sprint at AF CyberWorx is refining the problem. Stakeholders have an idea of what problem they want to solve. They may want to save time, streamline or automate processes, fix a system showing bad metrics, or set up a policy for a new requirement. Initial problem statements may reflect this focus, but usually lack the specifics the problem solving team needs to be effective.

Larry Marine, lead UX designer at AF CyberWorx, explains why it’s so important to re-examine the problem statement. As he states, “If you don’t know what problem you need to solve, the best you can hope to do is solve the wrong problem very well.” Just like a mission statement gives direction for a business, an accurate problem statement gives teams a solid visualization of what they need to achieve. Larry gives an example of a poor problem statement from his previous experiences:

“A mortgage company needed to improve their processes to increase efficiency. A common problem in the organization was epitomized by one form which required twenty four separate signatures. Copies of these forms were stored in filing cabinets that took up an entire floor of their building. The solution seemed simple: digitize the forms. However, during problem analysis research, the team found that the form hadn’t been necessary since a procedural change 20 years ago! Though their problem statement in this case included digitizing the form, they ended up cutting costs and regaining resources by simply getting rid of the unnecessary form.”

This simple example shows why problem refinement is the first step in every AF CyberWorx event. To help develop solutions that are impactful, meaningful, and effective, facilitators first guide event participants through the process of analyzing the problem to redefine the problem statement to be more accurate to ensure they achieve their desired outcome. Larry explains that some of the most common issues found in an initial problem statement include (1) making a solution the problem statement, (2) fixing symptoms instead of the root problem, and (3) forgetting that a problem can evolve over time.

When the initial problem statement says something like, “we need to digitize…” or otherwise describe a specific action, it’s giving a solution, not stating a problem. People often come into a problem solving event with a solution already in mind. They think, “I know what we need to do,” especially when they have a lot of experience with the problem. A solution-based problem statement supports that and guides the team to do something specific, albeit incorrect. If the team has the solution already, why should they go through the problem solving process? They already have the answer. The mortgage company already had an answer, but the team soon found the answer wasn’t the best solution. Refining the problem statement gives the team a more solution-agnostic goal to encourage the free thinking which finds the right solutions.

Another common issue initial problem statements have is a focus on symptoms instead of a root cause of the problem. For example: when the problem statement says, “We need to reduce the rejection rate from 65%.” The rate is a symptom of a larger problem. A better statement is, “Customers don’t know what information to give us, leading to a 65% rejection rate,” but it’s still focused on a symptom. To avoid creating another band-aid that simply covers a symptom, finding the root cause of those symptoms leads to a more impactful set of solutions. An even more accurate problem statement using root cause analysis might read, “Customers are looking for a tool to tell them what information to give, but can’t find it so don’t give the right documents.” The problem needs to be redefined with root cause analysis to aim at a deeper level than surface symptoms.

A third common mistake with initial problem statements is believing that a “fix” for an old problem will work now with a little tweaking. Larry explains that when a problem is “solved,” that solution tends to change slowly through time, ignoring the fact that the problem itself is changing as well. Basically, “We’ve always done it this way.” The form with the mortgage company is a good example. The problem hadn’t been examined in so long that no one realized the problem source wasn’t even necessary anymore. Refining the problem in this case verifies what the current nature of the problem is to develop an effective solution.

When AF CyberWorx leads a team through re-examining the problem, they aren’t wasting time by rehashing work that’s already been done. They’re refining the problem to ensure it is accurate, correctly identifies what needs to be fixed, removes solution bias, and pinpoints the team’s focus on the most impactful problem. As Larry states, “We look at details that they gloss over or can’t describe. If the refined problem statement looks like the initial one, we’ve likely missed something.” Using specialized experience and best-practice tools, facilitators help teams refine not only the problem statement, but the mindset of the team to make their problem-solving experience more efficient and positive in the short amount of time allotted to a design sprint.

*The postings on this blog reflect individual team member opinions and do not necessarily reflect official Air Force positions, strategies, or opinions.

PRE-GAME PART TWO: EXPECTATIONS

PRE-GAME PART TWO: EXPECTATIONS

“Our thoughts about an event can have a dramatic effect on how we go through the event itself.” –Martha Beck, life coach

Any time a group of people are about to embark on a new goal, there are expectations. As much as motivational quotes talk about having no expectations, they still exist in one form or another. A major part of the initial event planning is expectation management. Stakeholders have in mind what they think AF CyberWorx can do and will do. At the same time, the facilitation team has specific things they hope the stakeholders and participants will do. Sometimes the mystery continues on until the event itself. We hope this blog will work towards solving that mystery by setting realistic expectations.

When stakeholders request an event, they know the status quo is not working. They and the users they represent all have ideas of what might “fix” everything. Dr. Dan Padgett, a user experience designer on staff with AF CyberWorx, explains that the facilitation team does not “validate solutions they’ve already thought of.” Instead, they help with a process of thinking differently that gets the team to an answer. The key word being process. A problem solving event does not start with the solution. That being said, some participants and stakeholders come with the expectation that the AF CyberWorx team is going to either provide the answer to their problem or enable the idea they already have.

Vel Preston, Head of Innovation Design, explains it this way: “You scope a problem one way, and a lot of people come to the sprint who haven’t had the same background with new ideas. The group decides, ‘Well, we hadn’t considered that. Maybe we should scope this differently than we thought.’” The process AF CyberWorx guides event participants through leads experts and industry partners to refine the problem and find an impactful solution.

What the team thinks they’re going to fix at first may not be what needs to be focused on. Larry Marine, Lead UX Designer, explains why it’s necessary to lead participants away from their initial expectations as soon as possible: “Folks come in with a strong tendency towards the symptoms without fully understanding the problem.”

That being said, the facilitating team members are also not subject matter experts themselves. As Dr. Padgett says, “sometimes it takes participants a bit to realize that we’re there to facilitate the sprint, and that we’re not SMEs ourselves.” As designers, their specialty is facilitation and guiding teams to consider the user experience in their own designs. They are not experts in every field, nor are they experts on exactly what the stakeholders need to fix their problem. That’s why a group of experts from the field are brought together to solve the problem.

What AF CyberWorx cannot do for stakeholders is solve their problem. They will not immediately verify initial solutions before the process is followed, because they don’t know the current system well enough to say “yea” or “nay.” What we can do is assist a special focus team towards finding a desirable and feasible solution. We can provide facilities with a workspace, tools, and facilitators to make problem solving easier. We also provide networking with industry partners to broaden the knowledge and capabilities of the DoD talent pool. We facilitate improvement and growth, but the subject matter experts in the field are the real heroes that do the work.

Of course, expectations go both ways. Jayleen Guttromson-Johnson, Program Manager, lays out the AF CyberWorx expectations succinctly: “We expect full-time commitment while [participants are] in the design sprint. No email, phone calls, or disappearances. Also, be open to living with the uncomfortable. Our process isn’t like what most people are used to, so just trust the process.”

Stakeholders request AF CyberWorx facilitation and capabilities. We’re here for the team’s success. Let us help turn problems into solutions that go beyond simple expectations.

PRE-GAME PART THREE: PROJECT LOGISTICS

PRE-GAME PART THREE: PROJECT LOGISTICS

Written By: Author

What do hotels, food, security, and video recording have in common? They’re all part of the chain of logistics that happens behind the scenes before a successful event. The AF CyberWorx logistics guru is Cheyenne Ellis. She does more than just gather and send out a hotel list and coordinate access badges and video recording of the event outbrief. She also lines up transportation into the secure location where events are held, builds baskets with supplies for each breakout team, coordinates with our support team for food delivery, ensures buildings and elevators are accessible, and a myriad of other small details to let participants and the team focus their energy on the problem being worked during the event.

For her to be successful, though, she needs the cooperation of stakeholders and participants involved in the event. She says the most important thing she needs is for participants to fill out the requested information as quickly and accurately as possible. Otherwise, she may be unable to help, constrained by security or other deadlines. “We’re very strategic on what we ask for. We’re doing this because we need to.”

The place to give information is through the portal every participant is directed to at registration. The information provided allows Cheyenne to acquire security badges, lets her know if there are any food allergies (or preferences), as well as gives contact information in case there’s a last-minute change or weather issues to ensure participant safety and comfort. Without the proper information, we can’t get you on base, get you access badges, and through security to attend the event.

It’s critical that participants read the information they’re given before arriving on base for an event. It may involve what to bring (and not bring), base visitor hours, directions to the parking area, shuttle transportation, and how to navigate the maze of hallways to AF CyberWorx.

For stakeholders, the most important thing is to be involved and responsive, even if they are unable to attend the event. The best results happen when stakeholders give fully fleshed-out directions including their goals and a fully formed problem statement. Not only do these give the problem-solving team direction, they keep the stakeholder in the loop with what’s going on. The stakeholder is a critical part to shaping the way forward to a solution. Having involved stakeholders helps the event run smoother from the beginning all the way through approving implementing changes identified by the project teams.

AF CyberWorx does as much work behind the scenes as possible to make a design sprint run as smoothly as possible. Without cooperation from participants, however, that work is difficult. Be prepared with your end of the logistics and we will be that much more effective at designing a solution!

ABOUT THOSE TPS REPORTS!

Photo: Shot from Office Space

AF CyberWorx is focusing on Human-Centered Design for the month of October. It’s the secret ingredient of all that we undertake and can be an extremely valuable addition to most processes. Please follow us on social media to gain more insight into the value of Human-Centered Design and enjoy this week’s blog post by our lead UX/UI designer, Mr. Larry Marine!

ABOUT THOSE TPS REPORTS!

Anyone familiar with the cult classic Office Space will immediately recognize the TPS report. In the movie, the TPS report represented a comedic nod to the ubiquitous report generator common to pretty much every office software system. But while they are common, report generators are one of the most poorly designed tools in the UX domain.

The next evolution of the report generator has been the equally common dashboard. That multifaceted screen festooned with neon progress bars; red, yellow, and green speedometers; and blinking lights; all shiny objects that attract your attention, but don’t really do anything for you. Though both of these tools have become common solutions in software and web design, they fail to solve the users’ real problems.

Ask yourself this simple question: What will the user do with the report or the dashboard? Will they read it? Look for something? What kind of something?

Users tend to look for two things in a report or dashboard: trends and exceptions. Why? Because these are the two things that demand attention and action. But what action?

A key design tenet that I promote at the Air Force CyberWorx is every design should focus on leading to a contextually appropriate action. Avoid relying on the user to understand the problem or figure out what action to take. Lead them to the right action.

Since every trend or exception may require a unique action, a good UX design would provide the right action(s) appropriate for each item. For instance, rather than merely reporting that a sales rep is not meeting his numbers, a sales management system could incorporate a codified sales formula and compare the rep’s actions to that formula, noting any deviations and alerting the rep to perform any missing steps that are known to improve sales activities.

Example: it may be known that 80% of all sales come from a rep’s top 10 customers, but only if the rep meets with those customers at least 3 times per year. The system may know that the rep has only met with 4 of those customers and then suggest that he meet with the other customers soon.

The point is that dashboards and report generators themselves don’t incite action. The users are left to figure out what to do on their own. That adds a lot of cognitive burden onto the users, and there’s little reason to believe that every user will have the same response to every anomaly. The real design challenge is to incorporate the knowledge to define the problem for the user and then perform the correct action to address the specific trend or exception and to promote the right action for each trend or exception.

Think how differently your job would be if your dashboard synthesized the data, presented actionable insights, and then provided buttons to effect the correct actions.

This action-oriented design approach is a key focus at AF CyberWorx. Good UX design is more than just putting a pretty face on a dashboard, it’s about inciting the right actions to solve a specific problem.

*The postings on this blog reflect individual team member opinions and do not necessarily reflect official Air Force positions, strategies, or opinions.

AF CYBERWORX KNOWLEDGE DESIGN

AF CyberWorx is focusing on Human-Centered Design for the month of October. It’s the secret ingredient of all that we undertake and can be an extremely valuable addition to most processes. Please follow us on social media to gain more insight into the value of Human-Centered Design and enjoy this week’s blog post by our lead UX/UI designer, Mr. Larry Marine!

AF CYBERWORX KNOWLEDGE DESIGN

A recurring sprinkler control problem for large spaces (parks, ball fields, etc.) involves adjusting the sprinkler schedule to accommodate special events. A 3-day baseball tournament requires more than just shutting off the water for 3 days. Watering at night makes the field soft and susceptible to damage, so that’s not an option, either.

A more successful approach involves a complex schedule of watering more than usual for 2 days prior to the event, sprinkling only a few minutes each night of the tournament, then watering heavily again after the tournament. Existing solutions require users to manually change the watering schedule each day in the complex irrigation control UI, which almost always results in a user error.

A knowledge-based approach would be to provide different watering templates for various types of events that could be invoked by the users. For instance, the user might merely indicate that a 3-day tournament will occur on such-and-such dates and then the system would automatically adjust the watering cycles before, during, and after the tournament, returning to the standard settings after the event. Moreover, the templates could be based on best practices gleaned from other users with similar field composition and irrigation equipment.

By providing a design that asks the user to indicate the event and the dates, we can provide cues that focus on the knowledge we can expect users to actually have. So rather than a complex set of features, the user only needs to select the event and the dates, and the system does the rest of the work.

As technology becomes ever more complex and pervasive, we cannot expect users to understand how to use every device with complete expertise. They may be familiar with some devices, but not all. Therefore, we must design device interfaces so that users can use them without having expertise for that device.

A common approach to UI design is to provide a cornucopia of features and expecting users to know which features to use and when to use them. Unfortunately, this is a failed premise evidenced by the frequency of user errors. This is even more true when users are distracted by other factors such as state of mind and physical limitations. For instance, a person can’t be expected to attend to a complex device with patience and clarity when faced with a panic situation or if they are temporarily impaired.

Beyond simple UX Design, knowledge design builds knowledge into a design to help the average user bridge existing levels of skill and knowledge to be more successful. The key is to identify the knowledge users need in order to succeed and finding ways to embed that knowledge into a design.

Successful techniques for designing knowledge into a UI include designing best practice approaches into the product, creating task-oriented designs, providing templates and intelligent defaults. These techniques require that the designer have enough in-depth knowledge of the domain such that they can provide salient cues for the users.

CyberWorx uses techniques specifically focused on identifying knowledge design opportunities within a problem domain. We would be happy to discuss these techniques with your team. Just ask.

*The postings on this blog reflect individual team member opinions and do not necessarily reflect official Air Force positions, strategies, or opinions.