Forgent's Scheduler - Web User Interface - January 2004
Click here for an overview
in power point on the design evolution of the entire Forgent suite of
products.
See the Alliance Demo (in Flash with Sound). If you do not have the free Flash viewer, you can easily download and install it by clicking here.
Forgent provides a suite of enterprise and personal products that automate
and manage all aspects of the meeting process from audio and video conferencing
to catering and personal availability.
This product manages resources and schedules for both rooms and services
managers. This product also enables automated video, audio and web conferencing,
catering, equipment and/or technicians. When using Alliance Scheduler,
all a meeting owner would have to do is walk in the room and all of
their video conferences would be launched and the appropriate amenities
would be delivered. These interfaces are all configurable to the enterprise,
individual user, and the group to which that user belongs. 
When the user clicks either the "New Meeting" button or on a space in the calendar, the new meeting details page comes up by default. The user can choose either to fill out this first page and simply hit "schedule," or to click the tab appropriate for the style of meeting they are scheduling, or to hit "next" to be guided through each step in the process. The next page in this dialog combines both the rooms and the attendees' availability. This is for people scheduling in environments with highly constrained resources or across time zones.
Like 95 percent of my work, I had the ability to lead this product design
from start to finish, creating every word, icon and interaction in the
product with extensive input from customers, support, sales, marketing
and the development team. The interface is done entirely in html, xml
and css. It sits on an asp engine on an SQL Server Database.
Overview of the Process
- Marketing Requirements Analysis - review and discussion of the requirements with the marketing team. Defining our target user, market, and the problem we are trying to solve.
- Competitive Analysis - what is out in the marketplace that was perhaps missed, what are key design patterns in existing products?
- Product Gap Analysis - performed and shared with the key developers on the team for staffing, schedule building and planning purposes.
- Ideation on Whiteboards - this was done with the key developers on the team in order to have them involved to discuss what we think the product is and how we would conceptually divide the information.
- Paper Prototypes - done as a response to the whiteboard and discussion sessions, typical turn around of about 2 days depending on the scope of the product.
- Review of Paper Prototypes - performed immediately with all the key stakeholders to be sure that the product direction is correct. Developers are often researching technologies and architectures to pursue and dividing up key coding areas. It is preferable to also review these with users, but due to time and money constraints we waited until the Photoshop prototype to test the product.
- Screenshot Prototypes (Photoshop or Fireworks) - once the paper prototypes are approved by the team, then I spend about a day to come up with a design that most appropriately captures the product market and functionality. Depending on when the meeting is to be scheduled with all the key stakeholders, I prototype 3-5 key screens.
- Review of Screenshots - This can done either in a formal meeting or over email discussions, luckily the team really liked the design that was posted and the official meeting lasted about 2 minutes. This is an important step because at this point on, all of the further screens are based on that design.
- Updating Screenshots - I begin applying the design to the major interactive flows in the product, giving a good outline of the product.
- User Testing of Screenshots with both Europe and the United States - either the developers or myself, depending on the size and skill level of the team starts to build the prototype framework for the product while user testing happens. This is an iterative process where I gather the feedback and digest it for the team as a whole to decide if we are going to make changes or not. Because of the upfront paper prototype work and user testing happened early enough in the design of the product, we integrated all major user suggestions.
- Updating Designs - As user and developer feedback comes in, we update the designs and further define finer interactions. This is usually the time that functionality is cut because of time, functionality is added from either sales or marketing, and interactions have to be changed due to development constraints. I am also preparing materials with documentation and marcom to release the product. Often I begin on the next product while development is still coding the previous product. About 20% of my daily time at this point is spent on the old design, however when major changes happen I am pulled back often for several days.