2501 Barclay Dr
Nashville, TN, 37206
615-418-8225
tagline
615-418-8225 • wrgregg@gmail.com
615-418-8225 • wrgregg@gmail.com
I was asked to come up with several concepts to address several problems with the design of the firm's intranet site, DeloitteNet.
The most frequently mentioned (and somewhat contradictory) complaints about the current design of DeloitteNet are that (1) the interface is too cluttered (2) things are hard to find (related to number 1) and (3) the users would like to have access to more functions in one place.
It seemed the only way to allow users to have everything in one place and avoid serving up a massive page of links was to allow for customization of the home page. The bare minimum would be a settings menu or page that allowed the user to turn certain sections or types of content on or off. A more ambitious and flexible design would allow for easy, on-the-fly customization as certain tasks were completed or begun.
Both designs assume the users' ability to permanently turn certain kinds of content on or off. Design 1 explores what an interface that allowed content modules to be docked would look like; design two depicts a UI consisting of collapsing and expanding content modules.
The other challenge was to find a way to tame a navigation structure that was in places seven-levels-deep. The designs explore whether some combination of tabbed interfaces, pop-up windows and user filtering could be used to flatten the site structure.
The DeloitteNet home page as it existed in May 2012 didn't allow for a lot of user customization. The center column displayed news and features. The left and right columns featured long lists of links, an inefficient use of some very prime screen real estate.
Since one problem was the sheer depth and complexity of the website's structure, I put some time into coming up with ways to simplify it.
Mobile and desktop wireframes for design 1.
Design 1 attempts to declutter the home page by allowing modules to be docked on the left edge of the screen. Some frequently used functionality (settings, search and favorite links) is housed in the rounded, green buttons, which are permanent fixtures on the left side of the page and sprout flyout menus. Content modules can be minimized, turning into the white tablike buttons which mimic the appearance of the modules themselves.
1. Settings.
2. Search.
3. Links.
4. Minimized applications.
5. Maximized application. Maximized applications are draggable and resizable.
6. Notifications.
1. Links pop-up showing first- and second-level links.
2. Tabbed news channels.
1. People menu.
2. Filter controls allowing users to customize content displayed on Industries page.
Design 2 explores what a home page based on collapsible, rearrangeable content modules might look like.
1. Links.
2. DeloitteNet settings.
3. Search.
4. Minimized application.
5. Notifications.
1. Links megamenu.
If a company undergoing a Deloitte audit owns securities, someone has to come up with a reasonable estimate of their value. Roughly 50 analysts with Deloitte’s National Securities Pricing Center field these pricing requests from Deloitte auditors in the field.
When we started this project there was an existing NSPC web application used to process these requests, but it had some problems:
• The most-accessed info was buried behind a home page dedicated to announcements and boilerplate messaging.
• Information on users’ pricing requests was split into separate tables according to the type of security and the status of the request, making the search for a specific request difficult if it wasn’t where the user was expecting it to be.
• The screen used to intitiate new requests was a third-level screen accessed via a not-very-visible link.
• Users were also asking for an integrated messaging system so that important request-related communications weren’t lost in the clutter of Outlook inboxes.
The application had three user groups: auditors, analysts and a handful of system admins, a group that partly overlapped the analyst group. At this time it was expected that requests would be created and answered on desktop computers.
The four main user types on the NSPC site.
Not quite the final version of the site...the Notifications screen and several admin screens were added a bit later as the site evolved.
A detailed wireframe of the first New Request screen, Overview. It's part of a four-page flow that captures all the info necessary to initiate a pricing request.
By hiding as many fields and sections as possible until they were required, especially the "add" modules, we managed to make the form much less daunting. Selections made in the Request Type menu change some of the fields displayed below.
I created a full set of wireframes for the project, some of which were eventually turned into full-color comps.
The home page serves as a dashboard, surfacing data from the three most-accessed sections of the site. The three tables present summaries of recently modified recent requests and new notifications and messages, with links to their corresponding screens. Reserving a third of the page for NSPC-related news and announcements was a stakeholder requirement.
A view of the My Requests screen showing a request row that has been selected and expanded, revealing detailed info. The rest of the table has been disabled until the row is deselected. Clicking either the request ID or the MORE link takes the used to a page dedicated to that request. Clicking any of the hyperlinked names takes the user to a contact page for that person.
Just prior to the start of coding, I documented the site for the offshore development team.
The website design for Deloitte's new educational facility in Westlake, Texas, outside Dallas. After a couple years of designing applications and website that strictly adhered to the firm's branding standards, I was asked to come up with a design that looked more like a resort or hotel website than a standard Deloitte website.
In the early stages I had to help determine what features the site should offer. Certain pieces of functionality were givens: a system for creating events, sending event invitations, and for invitees to accept or decline. Also critical was a dashboard-like page or pages for guests to see all their room reservation, transportation and event info. In addition, pages with info about the onsite amenities, DU news and events, local attractions, campus layout and ways to contact the university were a given.
But there were a lot of ideas for other pages and features that we weren't so sure about. Online chat? Guest reviews? Interactive tour? Online ordering of meals? To help separate the features a business traveler would expect from those we could safely omit – at least in the 1.0 version of the site – I created this feature grid.
My Post-it-based IA diagram. Not exactly the final hierarchy, but close.
An attempt at a predictive map of the DU experience created nine months before the facility opened. Organized by four key user groups and five phases.
We determined that since event attendance was to be based on invitations, and since invitations with links to the online registration system were to be sent via email, most visitors probably would not enter the site by means of the home page. Still, for those who did come to the site through the "front door", and for anyone else who clicked on the Home tab out of curiosity, we wanted to convey the feeling of a recreational destination, not a business conference center.
One early misstep was splitting guest information (room reservations, transportation arrangements and event details) into three or four pages because of concern over load times. When this IA was criticized for requiring too many clicks, we settled on a design that consolidated all guest info on one page (My Agenda). Event sections are closed by default, with the exception of pending events. Within each event section there are separate tabs for each type of data. Each event section’s data loads only when it’s expanded, and each tab’s data loads only when it’s selected and made visible. Together these two strategies kept load times and system calls manageable.
A mobile app that brought the key functionality of the Deloitte University website to smartphones.
A wireframe flow created to help visualize the user's experience in making a DU reservation after receiving an email invitation to an event. The user's taps are marked by orange circles.
The application home screen, displaying the six functional areas of the app.
The second-level screen listing all events (typically classes or conferences) that a user has been invited to. Events are color-coded by status (blue = accepted, yellow = pending, gray = declined).
The third-level screen with all the user's travel and lodging information related to a particular event.
A tablet enterprise risk management application. Threats and opportunities turned up in automated web searches and filtered by human analysts are presented to Deloitte partners for consideration and possible action.
I was asked to contribute visual design ideas for the application after the high-level design had been decided on.
Displaying the 14 risk metrics, each color-coded according to risk level. The number of calls to action in each category are displayed at the top-right corner of each chart.
Basically alerts...risks or opportunities significant enough to rise above the noisy data. A collapsed summary view of each "call-to-action" is displayed by default, but can be expanded for more detail.
A detailed view of one risk metric, Talent Landscape. Each level is independently selectable in the hierarchy on the left and viewable as a chart or a spreadsheet on the right.
Deloitte's electronic document retrieval and management system. This design replaced an earlier, much simpler SharePoint site.
The main design consideration for this site were (1) accessing and distinguishing among the huge number of similarly named archives users might have access to and (2) the loose and randomly accessible nature of the main flow, Archive Working Papers. While an archive would mostly move through the steps in the flow chronologically, audit team members needed the ability to edit data on or add data to any step right up to the time of final submission.
The site had an interesting structure, encompassing three separate flows and a number of ad-hoc pages. An archive first has to be initialized in the Initialize Archive Flow, usually by the archive manager. This requires entering some basic information and creates what is essentially a digital container for future use. The archive normally sits empty for some time while an engagement progresses, but eventually the audit team begins adding documents in the Archive Working Papers Flow. When the archive manager think the archive is complete, they submit it to the archive approver, usually a director or partner, kicking off the Approve Working Papers Flow.
The My Archives screen served as a home page for the site. Here archives can be located and accessed via a table view, saved favorites, a dynamic list of recently viewed archives, or search functionality. Favorites, recents and basic search are also available from the menu bar throughout the site.
Clicking the Go to Page, Items per Page or Filters buttons causes the required fields and buttons to be displayed. Archive numbers are linked to archive pages and and client names to client pages.
Clicking the info button displays more detailed archive information. The amount of archive data exposed here is more than is shown in the table, but less than is available on the dedicated archive page. Many users have access to thousands of archives, so having multiple ways to access and search for archives was critical. Previewing data is useful for quick reference purposes and for distinguishing many similarly and sometimes confusingly named archives.
Clicking on a hyperlinked archive number takes the user to an archive landing page, and from there they can click into any step of the flow. Multiple people can contribute material to an archive and the contributions aren't always made in a predefined order, making for a very loosely structured flow.
My proposed redesign of Deloitte's internal social network. Mainly a visual design job, the goal was to come up with a more inviting, contemporary look for the site. Secondary goals were better space utilization and making the most-used content more prominent.
An existing (as of May 2012) DStreet profile page. Lots of boxes.
An early version of the profile page, mobile and desktop versions.
A desktop view of the proposed profile page redesign.
A desktop view of the proposed home page design with a news feed and some featured content.
A utility that allows users to select and add printers in any of the 100 or so Deloitte offices nationwide. I designed the interface and wrote the front-end code for the Flash-based app.
If the user's location can be determined by IP address and the user is in a Deloitte office, the initial screen is the default floor in that office. If neither of those conditions is met, the national map is the initial screen. From here the user can select an office, a floor in that office, and a printer.
The floorplan graphics are loaded onto the stage and the printer icons placed dynamically via coordinates. The icons denote printer attributes: color or black and white, single-sided or double-sided, secure or nonsecure, etc.
The thing I was proudest of may have been the autocompletion feature in the Search by office or city field, which I coded.
In this early design, the user selected a region and the national map shrank into the corner while a regional map appeared on the right side of the interface. From there the user could select an individual office. Eventually we discarded the regional map in favor of a regional pop-up menu that appeared when hovering over the national map.
Hovering over an icon displays the printer info box. From here the user can install the driver for that printer. Selecting the printer on the menu at left selects the corresponding icon on the floorplan and vice versa.
Mousing over a region causes an office menu to appear. Offices with more than one floor have submenus. The Southeast Region required a three-level menu because of the number of offices.
A website giving partners and directors the ability to track activity involving prospective and current clients.
Also showing the flyout navigation.
Essentially a mobile version of the Client Central website.
This interface evolved over the course of the project. Once we talked to users of the website we realized that the vast majority of usage would take place within the Client screens, and it made sense to treat that screen as the starting point for the app. We ditched the concept of a screen named "Home", and three of the buttons shown here, Clients, Alerts (renamed "Notifications") and Reports joined Settings at the bottom of the screen. Search fell out of scope, and the client menu, recast as icons, became the defacto home screen.
Each client button leads to a menu of options for that client. Notifications and Reports take the user to screens that contain info for multiple clients, and Settings to screens that set preferences for the whole app.
Drilling down into client info...
One of many client reports provided, Opportunities by Stage.
