I recently gave a presentation by this title at the Dayton [Ohio] Web Standards Group Meetup. Here are the slides that I presented as well as my references for the presentation. We also have a new Google Group for all designers interested in standards-based development regardless of location.
The paradigms I’m going to contrast are how we view the entire development process. I will refer to two different paradigms: the first is the “work-down” approach which I will contrast with the “value-up” approach. I read about this in Software Engineering with Microsoft Visual Studio Team System concerning the new Microsoft approach to software development including an introduction to the Agile SDLC. However, I’m not here to promote Microsoft Team System or Agile methodology; instead, I’m here presenting a paradigm that is pertinent regardless of your chosen SDLC or technological platform.I will start by defining both the work-down and value-up approaches (and I will use “approach” and “paradigm” interchangeably), outlining the effects of both paradigms, and I will finish with ensuring that this paradigm becomes practical in your daily development tasks.
The Old, Work-Down Approach
Most of us are very familiar with this approach. We meet with the prospective client, define requirements as much as possible, and approach the development task as marking off completed requirements until completion. This methodology works fine when you have no scope creep, have low risk, and well-defined requirements; but unfortunately this doesn’t describe most of our projects. This is especially true for us that freelance as the risks involved for us are much higher.
A project manager typically has three variables to use in the work-down approach: time, resources, and functionality. What has happened is that a fourth area needs to be recognized-namely, quality. Due to this and the truth that most of our project managers don’t take quality into account as one, if not the, most important attributes of successful software development from the very beginning.
The Value-Up Approach
When approaching this paradigm we need to remember what most satisfies us when we make a purchase. Even though we might not consciously think of it, when we make a purchase we are intending the purchase to return value to us in one form or another. I am most satisfied and suffer less cognitive dissonance when I see the value received from my purchase.
In the never-ending process to ensure that our customers are satisfied we should view their investment in us as a desire to receive value of some kind. Concentrating on a consistent flow of value to the customer should be a paradigm that will utilize, but we must not internalize as we must also convey that emphasis to our customer.
Software development is also different than other forms of development. For instance, when building a bridge there is no intrinsic value in a bridge that is only half-way done! But in opposition to this, software development isn’t build along the same vein. My customer can receive benefit by starting to use an application even though the interface is not yet completely finished. The earlier our customers see value being delivered to them the happier they will be throughout the process. Even though I’m not endorsing an agile approach to software development, this approach, when combined with agile iterations can help you effectively deal with the inevitable scope creep.
Contrasting the Paradigms
The book lays out a table to visually see the impact of using the paradigms (of which I will use the majority of the table), and the information is verbatim from the book (pgs. 6–7). While not exhaustive, it will help us to see tangible results of making such a change.
| Core Assumption | Work-Down Approach | Value-Up Approach |
|---|---|---|
| Planning and change process | Planning and design are the most important activities to get right. You need to do these initially, establish accountability to plan, and monitor against the plan, and carefully prevent change from creeping in. | Change happens, embrace it. Planning and design will continue through the project. Therefore you should invest in just enough planning and design to understand risk and to manage the next small increment. |
| Primary measurement | Task completion. Because we know the steps to achieve the end goal. | Only deliverables that the customer values (working software, completed documentation, etc.) count. |
| Definition of quality | Conformance to specification. That’s why you need to get the specs right at the beginning. | Value to the customer. This perception can (and probably will) change…don’t specify too much too soon. |
| Approach to Trust | People need to be monitored and measured to standards. Incentives should be used by management to reward individuals for their performance relative to plan. | Pride of workmanship and teamwork are more effective than individual incentives. Trustworthy transparency, where the whole team can see all the team’s performance data, works better than management directive. |
The first thing to realize is that in a value-up paradigm we embrace that changes happens throughout the software development process. I’m sure we have all had our fair share of frustration when we complete tasks according to the original specifications, but when we from the beginning perceive change throughout the process as inevitable-and ultimately positive-then it makes the process much easier for us.
Notice as well that the only true values of progress measurements are items that actually give value to the customer. In other words, our Gantt Chart should reflect tasks that actually give value to the customer not only tasks completed. In the context of a web application, that might be the installation and/or customization of a content management system, maybe it might be the ability for the user to customize the interface, or it could be a litany of other items. The only thing our customer should hear from us is that we are delivering value and utility to them throughout the process. This also helps when our customer comes to us and says something like: “This doesn’t do what the requirements outlined.” Well, in our perception it might be what the requirement stated, but if value is not given to our customer then we haven’t made any progress.
I do understand that there is variance that, no matter how much you try and avoid, conflict happens over what requirements. But the adage, “the customer is always right” is still very applicable to software development.
Moving from the Ethereal to the Practical
Now that we have outlined the philosophy we must ask how this can be of practical value to us in our everyday work. The best way to bring this back down to earth is to share a practical example.
I get to do software development with government agencies (Air Force, USAID), and if any of the readers share that experience then they understand my pain and frustration. More than any other clients, government agencies are some of the hardest to work with. The paradigm for development in general, whether software or weapons development, is the traditional (non-agile) methodology of outlining all the requirements from the beginning down to the type of paper you’ll submit to them.
These government agencies are familiar with only seeing something when the developer feels it’s presentable, and updates are traditionally provided in terms of a work down paradigm. I had to, with some very conscious thought, change the way I conversed with my customer. Here are some examples of changes I made in conversing with my customer. The first list will be the traditional way of conveying progress, and the second list will be the verbiage I changed from a value-up paradigm.
Work-Down Terminology
Value-Up Terminology
Conclusion
The value-up paradigm is a powerful way to approach software development, but change is something that needs conscious focus. The value of changing paradigms will become evident nearly instantaneously as the relationship improves between you and your customer, and the reputation of your company as one that delivers tangible value early grows and supplies a constant flow of work.
You can view the slides for my original presentation on SlideShare.
At work we are currently re-doing the architecture of our user interface (UI) layer. We sat down to discuss what our objectives should be in doing this initiative, and I found the objectives so compelling that I think it could apply to any user interface. Below are the major objectives in constructing a UI: consistency, usability, navigation, visual appeal, interoperability, performance, and accessibility.
I should first say that this list and its corresponding description are not intended to be exhaustive. I realize that there are many layers of complexity in this endeavor. Also, you’ll see how inter-dependent they are on one another. If you do one poorly it shows up in the others.
Two Levels of Architecture
Before I get into each of these points I want to talk about the two levels of architecture that are involved in the UI layer. The first is the information architecture (IA) of UI. Here is a great definition for IA.
“Information architecture is the design of the structure and navigation of an interactive product: software, a web-based application or a web site. An effective information architecture assessment bridges the gap between research and analysis and the visual design of your interactive product…The intent of an information architecture assessment and strategy is to properly define effective, goal-oriented interaction between your users and your application or web site.”
The second layer is the technical architecture. Technical architecture is basically how we choose to implement our information architecture programmatically. This would be decisions such as: what is our stylesheet architecture? How much abstraction do we want in our implementation? In summary, it would be how we design our presentation, structure, and behavior layers (what Jeffrey Zeldman called the “Trinity of Web Design”).
Consistency
If I were to say that there was a foundation to others it would be consistency. Without consistency such things as usability, navigation, etc. couldn’t exist. Consistency applies to every aspect of the user interface. Some things to keep in mind when thinking about this:
Usability
Usability is the endeavor that is often skipped during development due to resources, which is a shame, because many errors could be discovered earlier. Usability brings the application to the people that will actually use it. How many requirements meetings have you been in that revolve around your end users? Most of the time, whether intentional or not, we tend to project our personal preferences onto this mythical “iUser” that doesn’t exist. If your application is not usable then guess what? No one’s going to use it.
Navigation
Navigation is to an application as table of contents are to a book. At a glance I should be able to know where I’m at, where I’ve been, and where I’m going. In other words, navigation should answer the question: Where Am I? I see this as being the aspect that we tend to have the tendency of projecting our preferences onto a design. Navigation should also encompass the taxonomy you have for your site so I know the content of your site.
Visual Appeal
The fact that we want to design something that is in fact visually appealing is not a bad desire to have. The only problem is when we design interfaces for visual appeal at the expense of the others on this list. We also need to separate the thought that visual appeal corresponds to filling the entire page. One of aspect of “Web 2.0 style” (yep, I said it) is a proper use of white space. Your design shouldn’t look like you applied some “Make My Logo Bigger Cream”.
Interoperability
Web standards have, at their core, a focus on increasing interoperability. Wouldn’t it be nice that if we followed a standard that regardless of browser our design would look the same, and regardless of device our content will be delivered? Sometimes it is appropriate to design for a specific demographic, but most of need to consider at least the major players in the browser/OS market. I should never again see a “this page is best viewed in…” message again.
Performance
Remember the good olé’ days of dial-up? Ya, I’d rather not remember that either. We live in a broadband world now, but we still have to be conscientious that our application doesn’t make us cook dinner while we wait for it to load. Standards-based design helps in this regard. With cleaner, semantic markup and abstracting the presentation from the structure we reduce the performance concern?
Accessibility
Accessibility usually all had to be pushed from a social responsibility perspective (which many managers outside of the government could care less about) until we could start masking it under the guise that Google’s spider was the #1 blind web user. The truth is that accessibility is important, and even CSS 2.1 added markup to help with screen readers. Remember that you don’t want to alienate anyone from viewing your content. And yes, it’s true that accessibility does help your SEO if you need another reason to sell it.
Conclusion
Developing user interfaces is a complex process that deserves a lot of foresight and ability to adapt to your users, industry trends, and changing technologies. If you keep these considerations in mind you will be well on your way to creating an application that is usable, flexible, scalable, and so much more!
Leave a reply