This is a brief recap of our Webinar that was hosted with Annie Lovendahl from Vanderbilt University on 7/31/2023
Identifying the process you want to replace in Build
How do you identify which processes will work in Build?
Criteria
Form complexity
Impacts user experience – What kind of demands are you placing on the submitter? Weigh this against your audience.
Impacts production support – If something went wrong, how easy would it be for you to identify breakage points and troubleshoot? How about for a teammate to troubleshoot in your absence?
Workflow complexity
Has a significant impact on development and testing time, is often heavily influenced by form complexity – weigh these two together carefully
Also impacts production support – If you built it, you understand it, but the person who comes after you to take on support for this App needs to be able to follow it and identify breakage points.
Stakeholders in the process
How many people or parties need to be involved in reviewing and approving the development of this App? Beware of too many cooks in the kitchen.
Maintenance needs
Is the form or workflow going to contain information that needs to be updated periodically? How much and how often?
End users/Audience
Who will “own” the App when you’re done? What access rights do they need to the App and/or its documents? Do they want to export document data out of Build?
Many of our customers are looking for robust data reporting on submissions that we’re currently unable to provide, and they may not be able to effectively use the Documents spreadsheet export for their external processes. Be upfront about what exporting from Build looks like.
Who are your submitters?
How do you need to restrict access to submitting in this App?
Example: Office of Undergraduate Admissions needs student workers on their team to be able to submit an Admissions Data Access Request, but opening the form to all students means any student not an employee of OUA can submit.
Integration needs
Security and sensitivity of data in and data out
Who owns the data you want to integrate? What conditions might they have for allowing you to access this data?
Can you trust your end users and App owners to use this data responsibly?
PII or protected information: Kuali’s security protocols are robust, but always check with data owners and stakeholders—comply with institutional policies!
Planning the Project
Demo project request form
Questions I ask myself when deciding if an app will make sense in Build
The Car Question: Does the customer want a functional vehicle to get from point A to point B? Do they want a Tesla with some bells and whistles? Or do they want a magical flying car?
Be a realist. I often encounter customers who have heard great things about Build, but haven’t seen it themselves, and they have extremely high expectations for the product.
Build can do many things, but you and your resources may not be able to make it all happen the way the customer envisions it.
There may be parts of the process that are a good fit for Build, and some parts that may have to take place outside of Build. Is your customer willing to accept that, or will they accept nothing less than magic?
Using other tools to map out your process
Miro whiteboarding, flowchart diagramming
Project Management with Monday.com
Demo Kuali Build project board on Monday – Item Type Automation
Planning
Identified database objects needed
Milestone planning
Execution
Integrations
Form building
Workflow building
Other data structuring needs outside of Build
Launch
Reviewing App with major stakeholders for approval
Building Integrations
How do you figure out which integrations you need?
Risk of user error – Would errors in user-submitted data create problems for your workflow or business process? Is it safer to have that information retrieved from a trusted data source?
Quality of life: Is a requested integration necessary to maintain or improve on QOL for the business process and its users? Or is it a “nice to have” request?
Organize requested integrations or integration ideas into a matrix of difficulty x impact – identify the low-hanging fruit, high cost/low reward, and “Goldilocks” options
Building the App
Mapping Out Integrations
Understand your user experience first
What is the user going to do with this integration? Identify primary business case.
How will submitters encounter this integration on a form?
Identify and analyze data sources
Legibility of data
e.g., codes and abbreviations that may be legible to some audiences but not all
Identify your ID and label keys early
Does your ID key effectively distinguish one set of results from another?
Does your label key provide useful information to the user? How will they know they got the right results? For List integrations, does the label key provide enough information for users to distinguish between options?
Look for additional opportunities
In what ways could you manipulate the setup of the same integration to satisfy different business needs?
Example: Course Catalog Search integration manipulated to produce Independent Study-Eligible Course Search; Student Enrollments integration intended for Course Withdrawal manipulated for Computer Science grader application eligible classes
Hooking integrations together: Do you have integrations with related datasets? Can you use the output of an existing integration as the input for a new one?
Collaborating with developers
Summarize the business case for the integration
Refer to available documentation – Kuali endpoints & GraphQL
Provide visual examples, e.g. sample JSON, Excel table
Testing
Got a 200 response? Great! Now test in context—are you getting the response the user actually needs?
Build an App in STG—doesn’t have to be the whole product—but try to establish the context in which the end user will encounter this integration
Are you hooking up the outputs of one integration into another? Build them both into your test app!
Planning Groups in Form and Workflow
How can you categorize your different types of users (form submitters, workflow reviewers and approvers, document reviewers, admins, etc.)?
Find the “natural” divisions – e.g., school, academic department, business unit; faculty, staff, student, etc.
Workflow reviewer/approval groups and roles
Job title vs. process role
Creating a group role that corresponds to a job title makes it clear what business areas are stakeholders in a process, and can help clarify which roles need to be updated in the event of employee turnover
Creating a group role that corresponds to a role or responsibility for a specific business process makes it easy to find the role needs to be assigned to a particular workflow step, and it may clarify the function of different points in a business process
Originally published on Aug 3, 2023
Comments
0 comments
Article is closed for comments.