Modernization Hub

Modernization and Improvement
Industry Day 8: Building the IAE User Experience

Industry Day 8: Building the IAE User Experience

>>Okay, we’re going to go ahead
and get started, everybody. Thank you all for joining us today. My name is Ken Goldman. I’m the communications lead for
the Integrated Award Environment. And we’ve got a good program for you today, for what is our eighth Industry Day
program that we’ve put on, so far. So I want to welcome everybody
to the conversation today. And just as a quick reminder,
if you are listening in on the phone, please mute your phone. There is some noise in the background, so
we want to make sure that the presenters and the speakers can be heard loud and clearly. So, welcome today. We look forward to a dialogue with you today. As all of our Industry Days have been,
this is a conversation between you, our interested stakeholders, and us. We certainly do not view this
as a one way conversation. With that in mind, throughout the presentation,
you will have the opportunity to ask questions by using the chat log on the Adobe Connect. As you type in questions,
we’ll be capturing those. And we’re going to save the Q and A
portion for the very end of the program. And we’ll try to get to as many
of your questions as possible. But, along with the rest of the
materials, we’ll be posting answers to your questions on our interact site. If you want the deck from today’s presentation,
you can select it here on the Adobe Connect by selecting files, and then
downloading that file. Then again, after the presentation, we will
post it on interact, along with the Q and A’s and any other related documents
coming from today’s presentation. As always, you can contact us anytime
you want at IAE outreach, at So for today’s presenters, first I’m
going to turn it over to Eric Ferraro. Eric is our new assistant commissioner,
here in the Federal Acquisition Service, and he’s with us in the Integrated
Award Environment. He’ll be giving you a sense of what
IAE is up to and where he comes from. And then Emily Gartland, she is
our user experience product owner. She will be walking you through today’s program. So, without further ado, I’m going
to turn it over to Eric Ferraro.>>Thank you Ken. Hi everyone, and thanks for joining us today. I’m Eric Ferraro, and I joined the office of
the Integrated Award Environment in July of 2015 to oversee both IAE’s operations
in modernization, as well as the common acquisition platform
program office, which you may know as CAP. Prior to joining IAE, I spent nine years at the
Department of the Navy, as the project director for the Navy’s E-Business Systems. Before my time at the Navy, I worked
at IBM and PricewaterhouseCoopers, where I supported the Navy’s standard
procurement system implementation and operations. Given that experience, and all my gray
hair in the photo that you see there, it probably comes as nice to you
that I’m also a Navy veteran, having served as a supply
corps officer for 20 years. I’m very excited to have joined GSA and IAE when the program is undertaking the
important work of modernizing our systems. And I look forward to getting to know all of
our stakeholders as I settle into my new role. I’m happy to be part of my
first Industry Day event today. Here at IAE, we think it’s extremely
important to have an open dialogue with all of our stakeholders, particularly
those in industry. Through our seven previous Industry Day events,
we’ve found this forum to be a great way to share updates on IAE’s work
and answer your questions. So far, we’ve reached more than a
thousand participants in 400 companies, and are happy to have had the
opportunity to answer more than 80 of your questions during these events. Industry Days are just one of many avenues
we use to reach out to our industry partners. And we invite you to engage
with us in other ways, including through joining
our interact community, reading our quarterly newsletter,
the IAE Digest. And to consider participating
in our focus groups, which you’ll hear more about later today. First of all, for those who
may be less familiar, I wanted to share what the Integrated
Award Environment, or IAE, is. IAE is a Presidential E-Government
Initiative, that, managed by GSA, that oversees the operations in modernizations
of ten federal award management systems. At IAE, we seek to use innovative processes
and technologies to improve the systems and operations for those who award, administer,
or receive federal financial assistance, contracts, and intergovernmental transactions. IAE is governed by the award committee for
E-Government, or the ACE, as we call it. And is co-lead by the Federal Acquisition
Service and IT groups within GSA. IAE has a broad scope, with 3.4
million users across our ten systems. In SAM alone, we have 1.8
million entity management records. 53 — excuse me — 538,000 of
which are active registrants. In fiscal year 2014, more than one trillion
dollars in federal assistance and awards, across 3.3 million transactions,
were reported in IAE systems. IAE systems average more than 500
million hits, or page views, each month. And SAM averages almost 1.25
million searches per week. Right now, IAE is in the midst of
a large-scale modernization effort, that will offer great benefit to our users. As part of this effort, we are creating a
single foundational Common Services Platform, that will allow for faster delivery of new
software, cost savings, shared security, increased software quality, and
data integration across IAE systems. We will be building user experience driven
applications on that Common Services Platform. This approach allows IAE to focus on meeting
business needs, rather than the plumbing of the platform, and will allow us to prototype
software with our users more frequently, to ensure we are delivering
a positive user experience as we build our modernized environment. At the conclusion of our modernization effort, IAE’s ten stand-alone systems
will be consolidated into one streamlined environment,
under the banner of This modernized environment will act
as our data factory, or app store, and will offer many benefits to our
users, including single sign-on, unified, built in security, open data, API’s,
standardized authentication and role processes, and standardized tools and business rules. As IAE works to modernize our environment, we are committed to delivering
a positive user experience. For those of you less familiar with web
development, user experience, or UX, focus on having a deep understanding of
users; what they need, what they value, their abilities, and their limitations. UX is part of IAE’s architectural
principals, which are a technical response to the business drivers that affect the
IAE program, and the stakeholders we serve. This particular principal is to provide an
effective user experience for all stakeholders. As I hope you’ve gathered by now, this
is a principle that we value highly. So with that, I’m going to turn things over
to Emily Gartland, to share more with you about how we are gathering user input,
and how we are putting it to work, and creating a positive user experience, as we
work continuously to improve our environment.>>All right. Thank you Eric, and hello everyone. Emily Gartland here, with IAE user experience. I’m excited to share with you today how we’ve
been collaborating with our stakeholders, and working towards the common goal of
building a user centric award environment. Also, I wanted to extend a special welcome to
those of you who I recognize from participating in focus groups and other user engagement. Thank you for joining us today. So, the expectation — to set
expectations for your time here with us, here’s a story of what we’d
like to discuss today. We’ll tell you about our journey to identify
the people we need to engage and consider, and why it’s important that we find
those people and connect with them. We’ll show you the vast and various
perspectives we’re working with, and what those people are asking for in
a practical application of user research, within the [inaudible]of
development methodology. You’ll get to meet our personas, the fictional
characters they’re representing are very real users, who we refer to constantly
in design and development decision. We aim to show you today how your
involvement could impact our development. When we first decided that IAE needed to
focus around providing a better experience — people who use our system —
our first big question was, who are we building the Integrated
Award Environment for? If we’re trying to be user centric,
who are we centering around? We asked ourselves, “Why do these
applications exist in the first [inaudible]? Federal regulation tells us, for example, that
some of the applications specifically exist to measure and evaluate spending across
the Federal Acquisition community. They exist to tell us where
and how federal money is spent, and what opportunities are available. Some of our applications exist to
increase industry participation, and [inaudible] various categories of
small business and obtaining award. Ultimately, the federal regulations that
govern our systems are in place for the benefit of the public, to establish community wide
federal spending practices that are good for our economy, that are fair and open,
and that are good for the general citizen. This is why our applications exist. So the next question towards
who was the environment for, is who actually uses our applications? We have millions of users with
a wide variety of jobs to do. From one person businesses to vendors
with billions of dollars in revenue. From [inaudible] state government
officials to small non-profit agencies. Some of our users have 20 plus years of
experience with federal acquisitions. And others just won their
first government contract. Some people spend a lot of time in our systems,
and follow well established procedures. Others come into our systems only a few times
a year, and have to get reoriented each time. With so many user types, and considering the
purpose of our environment is for the good of the public economy, who is the
Integrated Award Environment for? Our answer is to balance both. The goals of the public, and the needs
of the wide variety of system users. We are building user experience, and
our goal is a simple solution that: A — reflects the value our applications
provide in bringing a level of broad, community wide transparency to federal spending. And B — it thoughtfully considers the
people that interact with our system and helps them save time, reach their
goals more easily, and realize more value from their individual and collective effort. We’ll get back to the particulars of who
uses our — who our users are in a moment. [inaudible] level set with what is UX to us? The look and feel of an application
is definitely an important part of user experience, but there’s more to it. Yes, we want to minimize the number of mouse
clicks for an operation, to simplify the layout of our application, to make
our systems more user friendly. This diagram shows how usable, findable,
accessible — those are all pragmatic, practical attributes of user experience. But we’re equally focused on the hedonic
attributes; how you feel about the application, rather than what you can do with it. We’re asking the tough questions on it; how can
we make the award environment more credible, more valuable, both in perception
and in actuality? I’d like to focus on the
attribute in the center; valuable. In talking with people who populate the data
of our applications, we quickly discovered that a significant number of
people enter data into our system, in addition to maintaining records in
the systems in their own organizations. Supporting accountability across the
federal government, which is what they do in the IAE system, is a layer
of administration on top of the accountability they have in their job. These individuals interact
with the award environment, motivated by their high work standards, and
the integrity of the office they belong to. Even in spite of feeling detached sometimes
from the purpose of our applications. Often they don’t feel connected to
the value they are helping to create. They haven’t spoken with the
contractor, or the policymaker on the other side of the data they are entering. They don’t know how incredibly
valued their information is. So we listened. And we are aiming towards a user experience that allows them the clarity of
purpose for their data entry. People have asked us for more insight
into our application content and purpose. They want to know how to resolve issues
related to their work, using our content. In building the user experience for
the Integrated Award Environment, we want people to know the
meaning behind the data fields. How they and their colleagues can interpret
and use our vast supply of award data to connect users across — through the
value they are creating for each other. Can I please ask you to mute your phone. Thank you. All right. So, who have we talked to? We’ve taken a couple of different
approaches in talking to users thus far. We’ve held a series of focus groups
for five of our applications, eSRS and FSRS, CFDA, WDOL and FedBizOps. And these focus groups gives us
a foundation for user analysis. Then we followed up with interviews, to go
further in-depth, and to learn people’s stories. For example, we have shared screens with
people and they’ve walked us through their — how they find wage determinations in WDOL, and
how they create program descriptions, CFDA. They have shown us the reports they need, and walked us through the data formatting they
find most useful to meet their data goals. They have told us how they combine
the award information in FPDF and FDO, to create a stronger basis for
evaluating upcoming opportunities. We’ve talked to contracting
officers and to [inaudible], trying to help local businesses register in SAM. We’ve talked to representatives of state governments [inaudible]
recipients of federal grants. We’ve talked to congressional research
staff and small business advocates. We’ve talked to universities about finding
research opportunities and administering awards. We’ve been building a base of user stories to really understand these
people in the context of IAE. We collect, organize, and disseminate, so that our development team can
build for empathy to our users. So how do we get these people’s stories? When we talk to them, we encourage them to imagine how our applications might
look to them in a perfect world. We share that we are seizing the opportunity to redesign the award environment
from the ground up. And link data between our
applications in a meaningful way. We ask them to think about their work
environment, who they work with and how. What pressures they are under, and what
goals they are set out to accomplish. Because this is a complete rebuild, and
technology has changed a lot since most of our applications were first built,
and because expectations are high for website interaction these days. We have an important opportunity
for user experience. We have a chance to build valuable
connections between entities, award, performance, solicitation and other data. We have a chance to change the way that
people are modeled in the environment. How we determine what people can see and
do, how they keep track of their work, and how they are able to
connect and to work with others. We have a chance to think big, and
we want those big ideas to be driven by the people who use the system. Now, we don’t live in a perfect world,
and we do have real constraints, but we wanted to catch what people
consider ideal, to guide our direction and to measure our achievement against it. So, what have we heard from our users? First, I wanted to say that every
voice we’ve heard is important, and it is used to help form our picture
of what people would like to see. We are very appreciative of the
support and dedication we have received from the people we have talked to, and
who have told us their stories so far. In starting this journey, wanted to mention that
we knew IAE has a staff full of knowledge full of knowledge of federal acquisition. People who are experienced users of our systems and who have been involved in
supporting the applications. So we went into the user engagement sessions with some information about
what needed to change. We knew single sign-on was important. We knew we had to improve search. The people we talked to provided
us an affirmation of what we knew, and a wealth of specific detail on how
they search, what they want to filter by. What reports they want to run. Quantities and formats of data
they’d like to export from the site. Other systems they reconcile data against. And who they want to connect with across
organizations, businesses and agencies. Over the course of many conversations,
some themes started to develop. This list here contains an
example of ideas that we’ve heard from multiple focus groups,
and from multiple applications. Some ideas, such as consolidation of
reporting, require policy discussions, and perhaps modifications of federal policy. Items such as more seamless integration of
geographical information need to be evaluated and prioritized by our business team,
and then our governance organizations. For others, such as dashboard, we
have purchased tools that are a part of our common service platform, and we’re
now evaluating how to integrate them. In all cases, we are advocating
for the ideas that people give us. We consider our role to be listeners; to hear
and catch what people tell us; to organize it, and to disseminate people’s stories
appropriately through IAE strategic drivers. So now I’m going to introduce
you to our personas. So, talking about what we do with
the information that people give us, we have shifted through the data
multiple times at this point, analyzing it from a lot of different angles. And one of our earliest objectives was to
build personas to represent our user community. Our personas communicate who exactly
are the people we are considering as we prioritize requirements
and design features. Each of our personas represents
a broad group of users. We derived them by sensitizing the
input from numerous people who appear to have similar goals and
behaviors with the systems. We have a large and diverse user community. So our personas are simplified
versions of the people they represent. They give us the core team, the UX team,
the developers and everyone working on the project, a useful view of our users. Personas highlight common interests
of the people they represent. Personas give us a way to
tell stories about users, so that we can create best case scenarios. We ask ourselves, what would Rebecca want here? What does Julie need out of this feature? Wanted to mention that a single persona might
actually represent an entire group of people who have variances, and we do account for them. For example, you will see a persona for
financial assistance recipient on our list. Financial assistance recipients include state
governments, universities and hospitals, tribal government, local government,
non-profits and individuals. With an organization like a university,
one person might be responsible for pre-award activities, and another might
be responsible for administering awards. We don’t ignore these differences. We document them. We make people aware of them through
youth cases and persona artifacts. And we thoughtfully consider how
to apply personas to a [inaudible]. But, in adapting best practices,
in persona development for IAE, we kept our personas very broad. The neat thing about personas we identified
in this case, for the IAE, is that, like real people, they use
multiple applications. And the viewpoint we captured is [inaudible]
approach the environment altogether, not just one application. What you’ll see are holistic
representations of user groups telling us, how does Amy interact with both FDO and CFDA? How did Julian use SAM, CPARS and WDOL? This allows us a big picture perspective,
and we can save our whole environment around that whole type of
cross application user. So, some of the personas that are currently
in the works, that you won’t see here, include application integrator, those who manage
contract writing systems, and policymakers, which are relating to IAE systems. And I wanted to just mention that if any
of you in attendance have input to offer on application integrator, or policy personas,
then by means please get in touch with us. So, for those that are listed here, and
I’ll go [inaudible] set expectations, I’m going to show three slides;
so nine personas. And just quickly I will show you a highlight
of an exemplary concern of that persona, and then explain how that will
drive the award environment. Rebecca is our contracting officer. She uses almost all of the IAE
systems, including FDO, FPDF, the sub-award systems, path
performance, SAM, WDOL. Because Rebecca’s work touches to so many
different parts of the award environment, we’re referring to her story to help drive the
way we connect information across [inaudible]. The way we link entities to
past performance information. The way we link opportunities to awards. And agencies to opportunities. Julian is a small business owner. He has limited resources
to identify new business. And we use his story to drive the way
that people will search for opportunities. Amy is responsible for compliance and
system administration for a federal agency. She controls who has access to
records within her organization, and the department that falls underneath it. She monitors her organization and runs
standard reports to identify missed deadlines, to evaluate clients rates, identify data quality
issues and other performance related issues. We will be using Amy’s story as we are
building our dashboard capabilities. Paul is our federal financial coordinator, who
creates, and annually updates the descriptions, projections, and achievements of a large number of financial system programs,
current using CFDA. This process requires data
entry, [inaudible], and approval, both of the agency and the OMD levels. Paul’s story will be used to drive the
workflow experience for the award environment. Craig Wallace represents vendors; any
vendors other than small business. Craig represents pre-award users
who focus on business development, as well as administrative users
who focus on reporting compliance. Entity management is one of the areas where
Craig will strongly influence our system, as we are looking at the needs of
businesses that regularly buy, sell, and manage a large number of entities. Heather represents congressional staff
members, and many other types of researchers, who are looking for aggregate information
and trends across the environment. She will influence our cross application
and geographic reporting capabilities. Shivani is our financial assistance recipient. And I mentioned previously the diverse
groups of recipients she represents. Shivani will drive sub-award reporting, specifically sifata [phonetic]
reporting on the grant side. And we’re continuing research in this
process, with state agencies as well. Jonah represents foreign entities
and Jasmine represents public users. And both of these are current works in progress. We have been looking at the unique
needs for registering foreign entities in SAM, which Jonah will represent. As an outward facing environment
with a lot of public availability — publicly available data and features. As a system that serves public interest, we need to know how Jasmine will
consider the overall message and branding, and impressions of our award environment. Jasmine will help us to ensure a
sense of trust, professionalism, and ease of access to public information. All right. So, we’re going to switch gears a
little bit here, and give a big picture, and also dive a little bit deeper into
how we’re using the information we gather from user engagement. Earlier in our presentation, we
talked about user experience, and how our UX more than skin deep. To create a true value in system interactions. Getting just a bit more technical now,
since we are an agile development shop, we’ll discuss the areas and levels of decision
making where user input is an influence, and just how ingrained user
input is in IAE’s work. The diagram on the left here is a drawing
by user experience designer and strategist, Jesse James Garrett, describing
the elements of user experience. We read the diagram from bottom to top,
starting at the bottom with the strategy layer. This is where we look at our objectives. The purpose and value of systems, and we
determine who our users are and what they need. Here on the strategy level, we
balance the policies, which initiate and govern our environment, alongside
the needs of the people who use it. Strategic input from users at this level is
considered, such as big picture suggestions to consolidate reporting, or to
create an enhanced bid module to support contract proposal submissions. So the next layer up, is
where we determine the scope of what we’re building, from
one release to the next. The functional specifications, what features
we will provide, and the content requirement. What content we will include
are here at this level. At each level of this diagram,
we’re mining our raw data from user engagement to identify relevant input. And on this level, the scope level, what features people are asking
for is what we’re discussing. Here we consider suggestions, such as,
providing a comment feature for users when they’re updating financial
assistance programs. Which allows reviewers in the financial
assistance program to ask questions or get clarification before
they review a program. In the next layer up, we define
the structure of our system, and we validate that it will support
the features that people have asked for. Our information architecture must support
the volume of data that people want to export and the links between informants,
such as linking to performance data. The interaction design must align with
the way that people need information, and want it represented and formatted. For example, users have requested text fields
to be replaced with structured data fields. Here we look at how users are modeled
in the system and their relationship to the organizations they work for. What happens when responsibilities transfer
from one person to another, for example. We need to make sure that our information
model supports and enhances user relationships. The top two layers are the
skeleton and the surface layer. You can see that here, it’s not until we get
to this point, that we consider anything visual that you will see on the webpage. Information design is where we consider how to present the data, so that
it’s easy to interpret. Which fields are important to our users. How much information goes
together on the same page. What should we highlight? Should we display something in
simple text, or as a graphic. Site navigation is here. We designed behaviors of the interface
component as part of the skeleton. At the highest level, the surface, we’re
getting user input on this as well. We’re looking at the style of the website. How we will brand the website, such as logo
and color, and how we will use white space, or negative space, images, and font. So looking at this whole graph,
the user experience graph, you can see how imperative it is for
us and IAE to incorporate user input on all levels of development decision. Another perspective of user engagement relevant
theme, here, I want to quickly loop in all of this UX talk with something you might be
more familiar with: the agile methodology. It is a modern trend of efficient
development, which IAE has embraced. More specifically, the agile development for enterprise level systems called
agile at scale, or scaled agile. With agile, we are iteratively
delivering small pieces of functionality and building the environment incrementally. With scaled agile, we are breaking
those iterations into three levels, and you’ll see those here, right. Portfolio, program, and team. At the portfolio level, we’re looking
at long-term strategic planning and loosely defining where we’re headed. Here we’re talking about strategic
value of providing single sign-on, discussing whether we should have a bid module. Who benefits from it and what
value it needs to provide. And what policy changes would be required
to support consolidation of reporting. At the program level — and
these are just examples — we’re looking at the features that fall
into the scope of a quarterly release. What dependencies need to be considered,
and how we prioritize user features. Looking at how each feature
adds value, and who benefits. At the team level, we’re looking at
the details of feature planning — basically just two weeks in
advance, throughout our sprint. And considering what behavior
people expect out of the feature. This is where we go look in the
field at the number of mouse clicks and the fine-tuning of [inaudible] can happen. And iterative, rapid user testing. We make those choices. Another nifty way to demonstrate how we are
doing iterative nature of user engagement, is to show The Deming Cycle — you
guys might be familiar with it. The plan, do, check, act. Here we can show the cyclical nature of how
we plan, analyze user input, define features and schedule work, how we do or execute, create
wireframe prototypes and working software. And then, iteratively, in an agile way, we
collect feedback prior to moving forward. Going back to our users and making sure
that we’re meeting the original need. This activity is cyclical,
and it keeps us very busy. And then, on the next slide, you’ll see
that we have the same Deming Cycle displayed as kind of putting everything together. You can see the plan, do, check, act. At a scale to portfolio program and team level. At the bottom team level, following two
week sprint, we might have a new wireframe or a prototype functionality to show, and a
lightweight targeted user feedback session. At the program level, we are building
more robust user acceptance testing plans for quarterly software releases. We ask people to interact with the
actual data testing [inaudible]. And we provide feedback on that experience
to enhance the systems at that point. For long-range direction at the
portfolio level, we research and analyze what people need
from a strategic point of view. Discussing upcoming policy changes,
assessing value of big picture enhancements, and then discussing these with stakeholders. So, here is a visual of the
development process, in light of UX work. And there isn’t one splash
of color on this slide. That doesn’t reflect a need
for user interaction. Either through gathering your input, or
having users review and test what we create. We are so appreciative of the given
feedback that we’ve had so far. It’s been used to evaluate data models,
to craft wireframes, to create messaging. Every piece of input is taken seriously. We are always looking for key informants. Heavy users of our systems who are willing
to engage with us on a frequent basis, potentially through those two
week interactions in our sprint. And so, we wanted to highly encourage
any of you who have not participated, or who are not on our list of user
engagement, to please get involved. As you can see here on this slide,
there are a lot of different aspects of what we’re doing that
you could help us out with. All right. So, that concludes the base of the presentation. Here’s some contact information. The best way to contact the user
experience team, and to get involved, is through the email [email protected] And I encourage all of you to
join the IAE interact community. It’s an online community where you
can check out what we’ve been up to. You can sign up for updates, receive updates
about future events such as industries like today, and you can also sign up for
learning about the going-ons and the schedules and everything that we have to share
with our users and our stakeholders. So thank you all so much for listening. And, now I’m going to open it up for Q and A. And if you guys have questions, but you’re not
really sure how to phrase it yet on the phone — I guess — you guys are not really on the phone. All right. If you could please just
type your chats into the — your questions into the chat window,
we will approach them that way. If you give us just a moment,
we’re going to read them and get ready to answer your questions. And if you do have a question that you type in,
that does not get addressed in our Q and A here, we will be sharing the answers afterward.>>I’m not sure if everyone can see the
question, but the bottom line is the date — I’m not going to read the whole question, but. The — what specific steps is GSA
taking toward achieving complete and reliable data — is the
gist of the question. Because the perception and the
reality that the data that’s in our systems currently is
not complete and [inaudible]. Unfortunately, that’s somewhat shooting
the messenger in the sense of the data that we get, we’re the holders of the data. We don’t put the data in the system here at CSA. That’s up to the contracting officers, the
entities that register, and other government and vendor partners that enter the data in. The new system will have edits and the
capability to ensure that if we’re looking for a six digit number, that of course,
that it’ll be a six digit number. But if somebody types in
the wrong six digit number, I really can’t help that from a GSA perspective. There’ll be lots — of course
— interfaces and API’s, so that the data coming in
will be more automated. So the contract writing system, for
example, that a department uses, will feed automatically into
FPDS, like it does today. And so, with the new environment,
that’ll help as well. But in general, it’s hard for GSA
to be the enforcer, if you will. We just manage and operate the system. We can’t really ensure that people
are inputting it correctly, I guess, is the best way of answering that.>>Yep. And to add to that, that’s a very
— that’s a good response in general. And thank you Eric. And from the user experience perspective, the
only thing that I wanted to add at this point, is that when we are creating data entry
options, something that we’re going to be doing is helping users to really understand what they’re
supposed to enter into data fields. In order to reduce ambiguity, and this
is a user assistance type of thing, that is more available in modern systems. So we’re helping users to
walk through their data entry. And especially if you have
someone who’s new to a position. They might be entering the wrong data just because they don’t fully
understand what they’re doing. And we’re also trying to have
explanations of federal —

Leave a Reply

Your email address will not be published. Required fields are marked *