Tag Archives: sdlc

The Wireframe Audiences

Information Architecture is a difficult field. Not only do we continually have to sell the importance of our field, but we also serve a role that most IT people do not. We walk the thin line between business analysts and designers; we also have the difficult job of translating functional business requirements into something our developers can understand and our customers can buy off on.

Because we often don’t fit well into a nice category we are responsible for a much larger part of designing information systems. Nothing makes this more evident than the process of creating wireframes, and I’m going to address the debate on interactive vs. static wireframes in the context of our role in the development process from the perspective of designers, customers, and managers. The time has come to more clearly define who we are, the role we play in the development process, and be sure that we satisfy all interested parties in the process.

The following quote from Rosenfeld and Morville in their IA magnum opus will be expounded upon:

Wireframes represent a degree of look and feel, and straddle the realms of visual design and interaction design. Wireframes (and page design in general) represent a frontier area where many web design-related disciplines come together and frequently clash. The fact that wireframes are produced by an information architect (i.e., a non-designer) and that they make statements about visual design (despite being quite ugly) often makes graphic designers and other visually oriented people very uncomfortable. For this reason, we suggest that wireframes come with a prominent disclaimer that they are not replacements for “real visual design.” The fonts, colors (or lack thereof), use of whitespace, and other visual characteristics of your wireframes are there only to illustrate how the site’s information architecture will impact and interact with a particular page. Make it clear that you expect to collaborate with a graphic designer to improve the aesthetic nature of the overall site, or with an interaction designer to improve the functionality of the page’s widgets. (pgs. 308–9)

Are We Interaction Designers?

The answer is yes and no. We certainly have a role in the overall user experience process, but we are not responsible for how a user actually interacts with an information system. Let’s face it our annotations don’t replace the role of a qualified interaction designer. I will be focusing on the fact that our value-added proposition is that we can effectively lubricate the evolution from a stiff business requirements document into something reminiscent of a usable system that is then passed onto the programmers, designers, and usability gurus.

Please understand that I understand that the field of IA, UX, and all other aspects of architecting interfaces often happens with just a single person. I don’t want to minimize that as I myself served all these hats. I’m simply pointing the role of a wireframe in the overall interface design life cycle.

There are an abundance of tools that purport to aid architects in creating interactive wireframes, but then what does that display to our team members? Does a designer want to be handed a garbled, poorly-coded, auto-generated layout with cookie-cutter interactions? I know when I was a designer I wanted at least some liberty in what the interaction and user experience ended up looking like. It’s true that in most design shops that the designer serves an IA role, but when we have dedicated information architects shouldn’t we stick to doing what we do best? Don’t we deliver more value in designing taxonomies, labels, navigation, and conceptual layouts?

The Customer’s Perspective

The customer will always prefer something interactive—that isn’t a question. Looking at a bland Visio document doesn’t exactly inspire someone, but what is the purpose of the wireframe? Are we not trying to get the customer to focus on the layout, labels, etc and not how the interaction will take place? When we design interactive wireframes doesn’t it also pigeon-hole the designers to design around the interactions from the IA’s wireframe?

Here is what usually happens when you give anything interactive to a customer when you’re trying to do IA and not interaction design/user experience. They will spend more time clicking around complaining about the pop-up windows and the way it looks and not what we actually want them to be looking at? The value in static, seemingly dry wireframes is that they have no choice but to focus on what we bring to the table in terms of IA and not user experience.

The Designer’s Perspective

Designers are artists in their trade. They make money, because they know typography, colors, interactions, and all the other unique challenges to being a designer. I can’t tell you how many times I’ve asked for wireframes when what I was given was a poor mockup. Let us answer once-for-all that a mockup and wireframe are not the same thing. The designer does not want to be given a mockup—that is the very thing they are experts in. The problem only escalates when an information architect tries to tread too much on what the designers are supposed to do.

When an information architect goes out and converses with the customer, interacts with the functional business requirements, and creates and receives buy off on a wireframe that it is almost invaluable to a designer and the other programmers. A programmer can then focus on database schemas, object orientation, while the designer can worry about the aesthetics of the interface. You will become a programmer/designer’s best friend if you can abstract the job of creating labels while not dictating how the interaction and how it will actually look.

The Project Manager’s Perspective

Project Manager’s are often the hardest to sell on the value of IA. They look at IA as something the designer does, and that only contributes to the difficulty of selling the importance of our field. They are likely to look at the designer and say: give me a mockup to send to the customer, and when money becomes an issue in the project they’ll cut IA’s always before designers. I have never heard of a designer being cut in place of an IA. It has never happened.

We need to carve out what we do best. Designing information systems amongst different skill sets is not reminiscent of some measure of unrelated diversification—everything we do as IA’s is related to everything else. We just need to be sure that what we do we do as well as we possibly can while enabling our fellow designers and programmers while appeasing our customer.

Conclusion

The thesis of this essay was to define what our role is in the wider scope of the development process, and address just one small part of our value added proposition in the development of wireframes. We have so much to offer, but we must be careful on where we tread because we fill such a political position in the development process.

2 Replies

A Primer on Information Architecture: Introduction

Information Architecture (IA) is one of the most important and exciting concepts in designing applications, but it also one of the least understood by a majority of designers, programmers, business analysts, etc. Hopefully through the following overview of the major concepts and benefits you can immediately improve both the utility and finabitliy of information in your application. After all, content (information) is the most important thing to any application so doesn’t it deserve some foresight?

Defining Information Architecture (IA)

The Findability Flower

The Findability Flower

The Information Architecture Institute has the following definition to begin our study. They define IA as:

  1. The structural design of shared information environments.
  2. The art and science of organizing and labeling web sites, intranets, online communities and software to support usability and findability.
  3. An emerging community of practice focused on bringing principles of design and architecture to the digital landscape.

Information architects, from this working definition, play an important role in not only ensuring the usability and utility of information but it also goes to the level of discovering the optimal way to do physical layouts inside applications. From beginning to end, IA has an important role our design work.

Relation to Other Disciplines

Findability truly is the center of all applications we design. If information is not findable, then the value-added proposition from our applications doesn’t amount to much. Information Architecture is an important component to achieving maximum findability in our applications, but it has a very symbiotic relationship to other disciples in designing interfaces.

  • Interaction designers/user experience gurus are very interested in how our applications are actually used by the end user and therefore take a keen interest in how we label, describe, and layout our information.
  • Usability experts love IA for ensuring that our applications actually have information structured in such a way that makes it both usable and provides utility for the user.\
  • Graphic designers need IA before ever applying CSS, DHTML, or any other element to add to the aesthetic and function of the interface.
  • Business Analysts/Executives are concerned with ensuring that the product they sell and/or information they provide is understood by the target market. They see a tight relationship between IA and an application’s return on investment (ROI).

The list can continue, but it’s very apparent that many different stakeholders have a keen interest in IA. Because of this, information architects straddle an important line between the business objectives, customer needs, and application designers. They truly serve as the “glue” that makes projects stand or fall.

Understanding Information-Seeking Behavior

Before we continue with the various aspects of IA we first need to clarify how users actually seek information. If we can’t understand this vital aspect than all our IA will amount to a waste in time and money.

Too many designers design interfaces on the premise that search takes a linear form. In other words, the user comes to our application, searches/browses in a simple manner, finds their information, and leaves. Truth is, seeking information is an involved process. Think of how we search for information on sites: Sometimes we attempt to navigate the site, other times we go straight to search, but usually it’s a combination of both. We need to keep this in perspective when designing our information architectures.

A Diagram of Typical Information Seeking Behavior

A Diagram of Typical Information Seeking Behavior

Here are some important articles outlining information seeking behavior.

Next in series

Leave a reply

The Value-Up Paradigm

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

  • Per the requirements documentation, we have completed 1.A, 1.B, and 2.A.
  • Your new requirements are not in the original document so we will have to stop and revisit the documentation.
  • We have successfully completed the project according to the requirements.

Value-Up Terminology

  • With the completion of this iteration, you can now dynamically edit your content, customize the layout, and you can start to see how it will function as we finalize the user interface.
  • New requirements are a natural part of the process, and we will focus on your new requirements in the next iteration.
  • We have successfully completed the project in light of your desired capability.

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.

3 Replies
  1. Pages:
  2. 1
  3. 2