Digital Web Magazine

The web professional's online magazine of choice.

Rethinking Application Design : Comments

By Dirk Knemeyer

November 7, 2005


Brett Merkey

November 8, 2005 4:58 AM

Where is the value added here? The article should be retitled “Subjective Pronouncements on Application Design.”


November 8, 2005 5:59 AM

call me crazy, but I thought this was common sensus post dot com blow out? Big fat overpaid whitecollar consultancy teams get nothing but a lot of buzztalk and generally redundant paperwork done.

John Labriola

November 8, 2005 6:39 AM

Dirk, engaging remarks there. I have never worked for an agency per se, so it was interesting to see what goes on there. Typically I work on internal teams within large corporations or institutions. Thus far I have found that too much project management complicates and slows our overall development process. However, the UI team is usually small and unhindered. I am not sure if this is because lack of care or lack of knowledge of UI design. My guess is that it is probably a combination of both.


November 8, 2005 8:10 AM

Brett – of course the article is subjective, its my opinion!

John – good point about the effects of overmanagement. Project management is tricky, because it is a really critical part of successful design, but it can get in the way if taken too far. You mentioned that your UI team is small and unhindered: can you share a little about how many/what roles are participating on it? And are we talking about apps or a more informational site?

John Labriola

November 8, 2005 11:42 AM

We have three User Interface Designers. Each one is assigned to a different application. However, we often consult one another and have produced style and user guides to maintain consistency of the overall user interfaces.

Typically Business meets with Users to gather requirements. They then meet with Project Management and Technology Management to scope the work. Project Management then writes up a schedule of works and Business produces a Functional Requirements Specification. At that point Business sits down with the UI Designer to generate how the application will look and flow. Business then puts this into a Functional Design Specification (FSD). The UI Designer then creates a working prototype (screen shots are added to the FSD) and the User analyzes the prototype. If everything is okay, the FSD is formally approved and development of the application proceeds, otherwise changes are made and the process runs through accordingly. In Development the UI Designer develop the front end while tying in the back end with the Developers.

I can not complain about are process too much. But what usually happens is the approval processes are drawn out as there are many parties that must sign off. From our perspective we are allowed to make suggestions for improvement. For example, the company is in the middle of rebranding, so as we rebrand the older applications, we have the opportunity to tune them up with current web standards.


November 8, 2005 9:38 PM

Thanks for sharing your structure and process, John. Do you have a general idea of how many different people are involved from Business, Users, Project Management, etc. How large are your applications? Or better, approximately how many engineers are working on each application? Who is the final decision maker? And what company do you work for?

Sorry for the 20 questions; I’m just interested in getting a clear picture of your situation and talking about it intelligently.

Geof Harries

November 9, 2005 7:57 AM

I believe you’re starting to see this happen, at least in small parts, because of the industry’s gradual transition from waterfall to iterative project management.

John Labriola

November 9, 2005 8:46 AM

I can only share with how our group works. Because it seems that different groups within the Technology Division are operated differently, I am not sure why. It probably is better I didn

Andrey Smagin

November 11, 2005 11:50 AM

Great article. I absolutely agree on negative effects of decentralization of decisions in UI design. But to centralize it you need highly experienced and skilled individuals. And because of lack of them companies are forced to lower risks of making wrong decisions by spreading them between many centers. It’s not working great, but many corporations would prefer to avoid failure than to have a chance at success.
With growth of industry we will have more distinguished experts and that will partly help to solve the problem.

Peter Yee

November 11, 2005 2:18 PM

I totally agree with your article. Massive teams lead to super extended project timelines in which a front-end/server-side developer would get bored. The coordination of multitude of specialists to insert their own piece of code or approach only complicates things and make the application into a terrible code mess to the point that new features are hard to implement and maintability becomes fragile. Furthermore, no one wants to touch existing code because of fear of breakage. QA hates regression testing period.

Another thing I am totally frustrated about is overbloated architectures and overbloated engineering efforts just because an engineer thinks that something that is simple to implement is not a good thing!

I believe efficient application means:

1) Excellent user experience – without this, who would want to adopt your product?
2) Ability to adapt meet new features/requirements quickly
3) Costs

Chris Peters

November 13, 2005 7:54 AM

Thank you for the interesting article. I’ve worked for a couple organizations where nobody has had a clue about how to develop a successful application. I’ve noticed that the teams I’ve been on who keep it simple tend to be far more successful. This article helps reinforce my notion of keeping the UI team simple and with final authority.

I currently work for a government data center. Our software development division is pretty segregated. We have a mainframe/Java development team, a Web team (which I lead), and a Windows development team. Each team owns its own applications

The Web team is by far the most experienced in developing intuitive interfaces in a Web environment, but the other teams continue to develop their own Web-based applications without much direction from the Web team. Some of the interfaces are pretty horrible and definitely look like they are developed from the perspective of a programmer, not a designer.

The Web team is in high demand but only has three members. One member is really strong at writing code, but the other two are better at the design and more of the “front end” issues. The back-log of requests from agencies is quite overwhelming, especially when it comes time to implement the inner workings of an application (beyond the interface).

Since I’ve started, I’ve began trying to pull in members from the other teams to help with writing the code. This seems to work pretty well. I envision the Web team becoming the defacto UI team for all applications and Web sites.

Jeffrey Jones

November 13, 2005 11:32 PM

Wow, what an amazing waste of time this “article” was. I just have one question for you Dirk, how many people were on the team that put together your site at I’m loving the photo-based nav, and the effective use of open space, mwah!


November 23, 2005 12:07 PM

Thanks for the constructive feedback, folks.

John – thanks for the great information. It sounds like, structurally, your team is pretty well staffed and organized.

Andrey and Peter – thanks for adding good insights to the conversation.

Chris – it sounds like your group is doing things the right way and enjoying success because of it. Maybe they’ll ultimately shift more and more of their budgets over to you and let you build an effective team that has enough resources to effectively become the de facto UI team you envision.

Sorry, comments are closed.

Media Temple

via Ad Packs