Re-imagining KNET

The current iteration of KNET is designed as a clearinghouse for HKS information. In a recent interview, Jane Finn-Foley outlines the typical user journey: students, faculty, fellows, and staff are sent emails with links to standalone KNET pages. While curious new students might peruse HKS’s various pages, the site is not designed to be “explorable.” In imagining what a more user-friendly KNET could look like, it may be tempting to recommend a top-to-bottom transformation. For starters, the current Sharepoint 2013 infrastructure could be modernized to allow more flexibility and an improved mobile interface. However, the time and investment would be massive. Rather than starting the next round of updates with an overhaul of the architecture, the KNET team should start by tweaking and testing its user interface. One hypothesis would be that segmenting KNET’s interface by user would be a time and cost-effective way to yield significant improvements.

Why should we segment KNET?

Different user segments have different tasks, goals, and pain points (defined in the Value Proposition Design Book). Designing a site for multiple user segments might artificially force trade-offs between the gains and pains of one group versus another. As we see with the sheer volume of information hosted on KNET, maintaining such a wide audience can also cause pains in itself. Tailoring the KNET experience to specific segments would allow more breadth to delight each audience and reduce frustrations.

What would change?

Imagine this addition to the KNET login screen:

Future versions might automate the process by matching the user’s HUID to their user type on the backend

Once the user has identified which segment they are in, they would be brought to a tailored version of the existing KNET site. In the first iteration, the structure and format would be identical — the only difference being that information not relevant to the user group would be removed. Subsequent versions might tailor the overall site structure to the user — for example, a faculty member might have their research center or course site as their homepage, while a staff member would see an admin dashboard to the pages they have edit access for.

One item that would not significantly change immediately is the admin interface. While the user-facing sitemap will change, the process to edit information throughout the site will stay the same. This reduces the immediate need to re-train staff.

We might consider my.harvard as an example of a site more narrowly tailored to the user. The student dashboard, shown below, only contains functions and information that are relevant to students. In addition, features such as dynamic tabs and clear announcements/to-do’s help to declutter the page while elevating critical information.

How should we test this hypothesis?

We can adapt the Lean Startup approach to this process:

  1. Set vision: Align on clear metrics for desired outcomes — e.g. 90% user satisfaction, or an average time on 5 seconds spent to find information.
  2. Translate vision into falsifiable hypotheses: Start with the aforementioned proposal: segmenting KNET’s interface by user would yield [desired outcomes] while adhering to time and budget constraints such as [].
  3. Specify MVP tests: Design streamlined tests of a segmented KNET interface. You could begin with focus groups using paper print-out versions of the homepage — each group could circle or cross out pieces of the website they do and do not use. More advanced versions could be an online sandbox version of the website.
  4. Prioritize tests: Sequence the tests such that they build on one another. Consider running parallel tests for different user groups.
  5. Run tests and learn on them: Use the tests as an opportunity to refine the customer profile and value proposition as you gather more information about users. Meet as a team to discuss the takeaways from each test, and how to improve future iterations.
  6. Continue learning: Assess the hypothesis, test additional hypotheses, and continue iterating until there is sufficient confidence to build a scaled solution. Even after the “new” KNET is rolled out, keep finding opportunities to improve and learn — automated user testing, for instance, could be a good way to continually track the user journey.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store