 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
E-Marketplace Case
Study
Privileges Matrix
Spring 2001
Background
- Tool: Microsoft Excel
- Input: Functional Specifications document; wireframes; and cooperation from the development team
- Primary Author: Anthony Hand
- Download: Privileges Matrix (25 KB)
As far as personalized sites go, this one is probably less complex than others. As every user is tied to his or her employer's organization account, there's a two-level system for site privileges. At the organization level, E-Marketplace assigns certain global sets of privileges to an organization, such as the ability to post or view business opportunities. In turn at the user level, a Master User at Organization X can assign to a specific user the ability to create or publish postings (taking into account the limited workflow we built into the system to support oversight processes within customer organizations).
In practice, what this means is that the system dynamically builds each page based on what an individual user's privileges are and what organization he or she works for. What this meant for me is that for each page I needed to identify the hypothetical case where a user and organization had all privileges assigned, and therefore what content and controls (links, buttons) the system would present on the page. Using a combination of wireframe notes and callouts on the wireframes themselves, I identified the display contingencies based on privilege assignments. This worked reasonably well on a page level, but we still needed a global view of privileges to understand the design philosophy behind them so the technical team could build the system logic properly and the Quality Assurance team could test.
Here's an example of how to read this document. In the E-Marketplace site, we have a Portfolio feature where users can save references to intriguing business opportunity postings. However, it only makes sense for the system to present the Portfolio on the user's My E-Marketplace home page if the user (and his or her organization) has been given the privilege of viewing postings in the first place. Similarly, on the posting detail web page, the button for saving a posting shouldn't be displayed unless the Portfolio feature has been enabled for the user. So these come as a package with the privilege for viewing business opportunity postings: using the search engine to find new ones, the Portfolio feature for bookmarking promising postings, and the eAgent feature on the home page which dynamically presents new postings matching preferences set in your user profile. These three features don't make any sense unless the user (and his or her organization) have been given the privilege of viewing postings. You can see this set of privileges documented in the sample Actor description, the Member Analyst.
Take a few minutes and look over the privilege matrix. (I hope I got all of the inconsistencies out!) There may be other approaches which work better for the purpose of documenting privileges, but I'm glad to say that this approach worked well for us.
Other Links in this Case Study