IBM’s AS/400 User-Centered Design team establishes a direct link between the AS/400 customer and the IBM development teams. They use the input from real customer experiences so that developers do not need to make assumptions about what the customer really needs and wants.
Have you ever threatened bodily harm to a software designer? After the grief that some developers have put you through, perhaps your threats were justified. After all, in the standard software development model, products must be quickly conceived, coded, tested for bugs, and released to customers. As a result, many of the “enhancements” that arrive in these products are really just bells and whistles that do not really help you get your job done. Finally, the technical support line is your only channel for feedback to the developer. Often, this single channel comes at the cost of your frustration.
IBM Senior Vice President of Technology Nick Donofrio believes that it is time for a change. “Many people who grew up in our industry want to keep things complex because they see it as their private turf. They don’t like the fact that our technology has reached the masses. They want to keep things hard because that is what they know. That is a mentality that needs to become history.” According to Donofrio, the time has come for User- Centered Design.
User-Centered Design is a technique for bringing customers into the beginning of the software development cycle. Instead of creating new products and then waiting to see the customer’s reaction, it starts by engaging the customer in the actual design process.
To put the concept of User-Centered Design into practice, IBM’s AS/400 Division has staffed a group of Human-Computer-Interaction specialists, of which I am a member. Charged with the mission of establishing a direct link between the customers and the development teams, our team has set out to deliver on IBM’s commitment to meet our customers’ wants and needs. We provide you with the opportunity to speak with developers directly and tell them what you really want.
User-Centered Design is more than just usability testing. Before we can make things usable, we really want to make sure that they are useful. Our primary goal is to ensure that products meet customer requirements. Once we determine what you want, we take great care to manage the entire customer experience, verifying that the products are easy to obtain, easy to set up, easy to learn, and—most important—easy to use. We believe our products should be engaging, intuitive, and integrated. How do we do this?
Answering the Hows
When we begin a new project, our first step is to form a multidisciplinary team. In addition to regular developers and engineers, members may include marketing representatives, information developers, GUI designers, human factors experts, and service representatives. All members are responsible for representing concerns in their fields of expertise from a customer’s perspective. For example, information developers will be responsible for how customers deal with documentation. They ask the question, “What can we do to facilitate learning about this product?” This ensures that all user-product interactions will be considered in the overall design of the product.
Our team then sets out to identify and prioritize ideal customer requirements. We typically accomplish this through a series of structured brainstorming activities. The team recruits between 15 and 20 interested customers to discuss some of their good and bad experiences with related products. The participants break into small groups to define the perfect product, ultimately producing a list of ideal attributes. At the end of the session, each individual has the opportunity to select the properties that are the most important personally and describe why they are important. We repeat these sessions in different locations until a consensus is reached about the important attributes.
An example of this process is how we’re developing the IBM HTTP server for the AS/400. Several structured brainstorming activities were conducted this past spring. Each session generated over 70 ideal attributes. One user from Los Angeles said, “I want to be able to back up while my server is running.” Another user from Pittsburgh told us, “I want to have the Web server active while applying PTFs.” In Cleveland we heard, “The Web server should be partitioned from the rest of the AS/400.”
Addressing the Whys
At first, these sound like very different demands. However, if we were to start designing now, we would overlook a very critical aspect: Why are these attributes important? The users describe their reasons as “I have a very small window for downtime” or “I can’t afford to have any process stop the Web server” or “I need to leave my Web server up as much as possible.” The one true requirement voiced in these statements is that the Web server should approach zero downtime. If our development teams can understand why something is important to you, they can design products that are better suited to your needs.
Our teams go through a similar process for all of the requirements we gather. For the HTTP server, we consistently found approximately 20 attributes of the ideal product, including the following:
• It must handle e-commerce securely.
• It should support efforts to diagnose problems in a timely manner.
• It should have an easy-install setup and configuration process. Only after the requirements have been gathered does the development team put together a design package.
Applying the Polish
Even though our plans set out to address a majority of the user requirements, chances are that the product will still not be quite perfect. There are likely to be some discrepancies when we interpret the requirements. For example, look at the ideal attribute, “The Web server supports efforts to diagnose problems in a timely manner.” What does
“timely” mean? What does “supports” mean? What is the scope of the “problems” being referred to?
To stay in sync with the customers’ needs, we proceed with an iterative design process. The multidisciplinary team encourages the designers to create a good prototype early in the development process. This prototype can initially be as simple as a paper mockup. As soon as possible, we invite customers to use these prototypes in a simulated work environment to evaluate the product in terms of their goals. We monitor and capture the users’ activities, their comments, and their attitudes. The developers then continue to work with the users to create better and more elaborate prototypes. As the prototype continues to grow, new users are constantly added to evaluate the changes and to help it evolve into the final product.
The Domino team recently went through this process when developing the interface for configuring an AS/400 Domino server. User input told us that some of the defaults we planned to use were inconsistent with the way servers are typically configured. Furthermore, some trivial parameters were intermingled with ones that were essential for success. As a result, the blueprinted configuration process was redesigned to operate according to user specifications. Another issue that arose was that users were repeatedly asking for a way to change an existing Domino server configuration. Considering those requests, our developers are currently working on a new Change Domino Server (CHGDOMSVR) command. These alterations allow you to interact with products the way you would expect. The overall effect is that you can not only get the job done, but also do it in an easy and efficient manner.
Before releasing a product, we hold a final evaluation. Since real users have been involved in the entire design process, this feedback should simply validate that the product is effective at meeting the requirements that were addressed.
An Open Invitation
The User-Centered Design team would like to invite you to become involved with our activities. Some of the key projects that we are currently investigating include the following:
• Domino for the AS/400
• HTTP server for the AS/400
• DB2 interfaces
• Management Central
• Security management
• Operations Navigator
• Initial install (Out-of-box experience)
• Hardware setup/customer installable features
• Network Stations If you are interested in influencing the design of these or other areas, please contact our project coordinator at RCHUCD@ us.ibm.com.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online