Our past shapes how we see the future.
It's easy to forget how far we've come as application builders. In 1994, my strongest programming language was a dBase variant called Clipper. In fact, I was able to do such great things with Clipper that they called me “The Wizard.” (OK, one person said that one time, but it was still pretty great.) For those who have never been a Clipper wizard, here is a quick rundown of what Clipper could do:
- It had a powerful syntax for defining data entry screens and validation logic.
- It had a built-in database with support for fast data retrieval using indexes.
- It was compatible with several 3rd party report writing tools.
Basically, our applications collected data, performed some validations or calculations, and stored the results in tables. Then when needed, our users would run reports to get that data out in detail or summary form.
That doesn’t sound very wizard-like looking back at it, but compared to the alternative (which was either a basic spreadsheet or other manual tracking system), our solutions did amaze people, and they did a great job of improving the work lives of people who had to keep track of things. Around that time, tools like PowerBuilder emerged to build these exact same applications for the new client-server/Windows platform, and they did it so well that, I think for a lot of us, this model became our default understanding of what an application could do.
New technology, same systems.
Flash forward ten years to 2004: The Internet had become pervasive, and many of us had begun developing our first business applications to utilize it. There were plenty of tools, but the market was dominated by Microsoft's recently released .NET framework and Java / J2EE tools which enabled us to:
- Build UI's that would allow data collection and validation logic in a web browser through the use of “server-side” components and frameworks.
- Utilize powerful database servers from Microsoft, Oracle and others.
- Use the data in these databases to produce reports, integrate it back into legacy systems, or populate data warehouses.
Although there were notable exceptions, in many cases we were repeating the same model we established with those old Clipper and PowerBuilder applications, except replacing the rich, flexible UI of a PowerBuilder application with the complex and hard-to-use browser-based UI! And given how hard it was to develop browser-based applications with those tools, you practically had to be a wizard to get it all to work.
How do we need to see things differently today?
So what's different in 2014? We still build systems to collect information, and people still generate reports to support daily operations. What makes this period unique? We have a bunch of new development frameworks and tools that make development more efficient and our solutions more scalable. Is that the difference? Today's developers understand the patterns needed to build applications that run on PCs, tablets, and phones, but is that really what makes this era different?
In my view, the major change that is disrupting the common understanding of application development is the rise of “Customer Experience” as a business discipline, and more specifically, User-Centered Design as a means of defining an application. The “wizard” developers of 2014 are developing applications that define their companies’ corporate brands. They are putting innovative solutions into completely new contexts, driven by Customer Experience and User Experience (UX) theory and leveraging new devices to solve problems that go beyond capturing and reporting on data. They're using “outside in” thinking (a great book on this is Outside In, by Harley Manning and Kerry Bodine – on Amazon) and User Centered design approaches (excellently described in Jesse James Garrett’s The Elements of User Experience: User-Centered Design for the Web and Beyond – on Amazon) to figure out and take into account what motivates a customer. And they are developing cool web portal, mobile, tablet and Customer Interaction Management (CIM) applications that meet corporate objectives by providing customer solutions.
An example of a customer-centric solution to a classic problem: Telecom Moving Wizard
I like to use the following example to illustrate user-centered design: the common telecom scenario of moving a customer from one residence to another. Each line of business (LOB) (Telephone, Internet, Wireless, etc.) would have a back office process that needed to occur in order to successfully transfer service to the new address. Each LOB employs a data collection application, and reports would drive operations staff to complete the service moves. Knowing who to call, when you needed to call by, and how to follow up if there was trouble required a customer to do their homework in advance; and, if they made a mistake, they could end up without service. From a business unit perspective, these systems work pretty well; they gather the right information and supply that information to the people doing the work. But from a customer’s perspective, moving is stressful at the best of times and it is complex and frustrating to need inside information to know what to do, and to have to tell the same information to multiple departments.
Our 2014 application developers would build the application to support the goals of the customer: seamless transition of services on a given date. UX designers of the application would not start with the data requirements for the service transfers – they would approach the problem the way the customer sees it, gathering all the information once via a “Moving Wizard” for example, taking them step-by-step through the process of planning, executing and monitoring their service moves in a simple and reassuring manner, all the while gathering the information that the back office will need to get work done at the appropriate time.
New thinking = better solutions and more value.
We've come a long way in the past 20 years, not only in our technology, but also in how we utilize it for the benefit of our customers and our organizations. When organizations think about how they can maximize their investments in IT and software development, they’re going to need “wizards” who are application development leaders who understand user-centered design and are who not hemmed in by the patterns of the past.