projekt202 takes a user-centric approach to software design. What a concept

Although engaging users during the design phase of an application should be the normal way to do things, it isn't. Not by any current standards, at least. The philosophy at projekt202is different than normal. The developers and the design team for an application extensively engage, interview, and observe users before entering a single line of code. CEO David Lancashire and I spoke about projekt202's unique application design and build philosophy is the exact opposite of "standard" application development. I found it refreshing to know that his teams take user feedback, work habits, needs, and desires into the core of the application design process. What a new and exciting concept it is when a programmer asks a user how to do something. It's called "Experience-Driven Software Development" and it's the modern approach to user-centric design.

Maybe this is the new normal for building applications.

Unfortunately, application development usually takes the following path:

• Initial client meeting, which might or might not include a developer.
• Requirements gathering for the application covering the type of app, number of users, platform, etc.
• Developers go into "silent" mode while programming the alpha release of the product.
• Periodic update meetings to check progress.
• Alpha release; much fanfare.
• Feedback on alpha release.
• Periodic update meetings to check progress.
• Beta release; much fanfare.
• Feedback on beta release.
• Periodic update meetings to check progress.
• Excuses as to why the product is delayed.
• Missed milestones.
• Periodic update meetings to check progress.
• Conversion of old data into the new application format.
• Excuses as to why 60 percent of the data will be lost or munged.
• 1.0 release, much long-awaited fanfare.
• User complaints, bug reports, application crashes, data loss.
• Data re-entry.
• Long overdue patches and updates.
• Lather. Rinse. Repeat those last three steps.

I'm sorry that this list was painful to read through. It was painful to write. It's equally painful to live through when having an application built. I didn't include the pain of dealing with your typical vendor's offshore (cheap labor) programmers. That's a whole other painful tale that includes time zone problems, language problems, cultural differences, and misunderstandings of business requirements. There's no greater joy than to spend an hour (or more) on a phone call and to feel that you've accomplished nothing from it.

The end result is that you never get the application that you've paid for and your users never get an application that truly works for them. In all, you've wasted how much time, labor hours, money on something that really doesn't work for you.

There is a better way. The projekt202 way.

"The perspective and processes projekt202 is focusing on and perfecting will, over time, become standard operating procedure for any application development project."-- Gartner

Revealing Reality - Fact gathering involves understanding the constraints of the project and then engaging in an observational process to develop a full understanding of the user. The company seeks to fundamentally answer the following question: "What should we be building?"

Focused Innovation - With data points extracted from user observations and other evidence sources, the company puts insights into action and creates a grounded vision for the product and design principles for building it.

Building & Evolving - Cross-functional teams are used to build the software. Scrum-like processes are engaged to plan and execute on the discoveries made in earlier phases.

As you can clearly see, projekt202's approach is different than the accepted practice of creating applications on the fly with release/trial/error/reprogram/release, etc. The accepted model doesn't work. It doesn't work for users. It doesn't work for companies that pay for the development and it doesn't work for the application programmers. Missed deadlines, poor application design, low user acceptance, and high maintenance costs are but a few of the reasons why the accepted model doesn't work.

The user-centric model that projekt202 has developed over the years works. It's a detour from the normal way of doing things. When you see the projekt202 team working, you might not understand the method behind the madness, but your users will and that's really what you're paying for: user acceptance. To empower users in the design and development phases of application development ensures buy-in from the user community because they have had a voice and a hand in creation.

It's not a culture of complaints; it's a culture of progress toward a goal--a common goal among designers, developers, and users. It's a brilliant application development method and one that should be far more common than it is.

Another unique projekt202 feature is that they'd like not only to talk to you, but also to see you. That's why the team freely publishes their addresses and phone numbers in Addison, Texas; in Austin, Texas; and in Seattle, Washington.

What do you think of projekt202's user-centric application development strategy? Talk back and let me know.