Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »


User Centered Design

Uxi recommends a user centered design approach when designing Kuali applications.  User centered design (UCD) focuses on the users of the application and their needs throughout all phases of the design process.  UCD can be applied on many different levels no matter what kind of development process you are using.

Determine the primary personas

The first step in the UXI design process requires the project teams to identify the generalized user(s) of the application.  We call these personas.  Identifying the personas as a team and choosing which ones will be the focus of the project helps the entire project team understand and become familiar with the primary users of the application, and it also helps the team determine priorities during the development of the project.

Identifying personas can be done in a number of ways.  Sometimes the subject matter experts (product owners, business analysts, etc) have enough knowledge about the system to identify and describe the generalized groups of users of the system.  When that knowledge isn't readily available, UXI will conduct ethnographic research and study the users of the system using contextual interviews.  This helps UXI understand the users in their own environment as well as how they use the existing system to get their job done.

UXI recommends choosing 1-3 primary personas during a project.  The needs of those primary users will be considered a priority when designing features and functionality.  Other personas may be considered secondary or tertiary.

Identify workflows and user stories

Identifying the existing workflows of users (either in the existing system or a different system) helps the UXI team understand the overall system as well as where improvements to the workflow can be made.  It isn't required to have workflows documented, however it is extremely helpful.  User stories, on the other hand, are required.  User stories can be in many forms, but in general, user stories should be a way for the project to communicate and document requirements for the project.  UXI recommends documenting the requirements in the form of user stories so that a feature or functionality will only be considered a requirement for the project if it helps the user accomplish a task or goal in the system.

User stories are often used in agile development teams because it is a way to quickly identify the user need without identifying the solution.  User stories can also be used in any kind of development process with less or more detail.





Process of modifying an existing component:

Phase 1 (Drafting)
  • Modifications to an existing component are requested
  • Designer determines changes needed to the component specification based on the previously documented component specification in the Kuali Design Guide
Phase 2 (Review)
  • Designer creates Rice KRAD Jira for component enhancement/bug
  • If it is a major change, the designer completes the review and approval process outlined above.  If it is a minor change, the designer will consult with UX colleagues and make an informed decision on the change (will bypass review team and KAI review).
  • UXI prioritization committee assigns JIRA

Phase 3 (Implementation)

  • Designer works with assigned developer on implementation of component if necessary. Designer communicates back to customer and design working group any changes necessary.

Phase 4 (Released)

  • UXI adds component documentation to Kuali Design Guide and documents the version change


  • No labels