Knowledge vs. Intelligence

About a week ago, I was running into major issues during development of one of my side projects. After a few nights working to resolve whatever was breaking, I was getting frustrated with my lack of progress.

The next night, I was video chatting with Olivier Lacan, and we started discussing the problem. Since he’s a good friend, he suggested sharing my screen and helping me work through it. I was working in Laravel, the new era PHP framework, which Olivier has never worked with (nor does he work with PHP). But he’s intelligent and a great developer, so I quickly took him up on his offer.

We pored through the codebase together—I walked him through the application and the framework, and he asked probing questions about what was happening internally. Since Olivier isn’t deeply familiar with Laravel, he asks different questions than I do, and those questions led us to interesting parts of the framework that I wouldn’t have gotten to alone. After about an hour of debugging, we identified the root issue and fixed it.

I’ve talked about “switch programming” before—trading computers with someone and working through each others’ issues separately—but this is something different. It’s more akin to traditional “rubber ducking,” except with a trusted, intelligent friend.

The difference between knowledge and intelligence is key here. Knowledge is the collection of skills and information a person has acquired through experience. Intelligence is the ability to apply knowledge. Just because someone lacks knowledge of a particular subject doesn’t mean they can’t apply their intelligence to help solve problems.

Knowledge is wonderful, but it fades as techniques and technologies come and go. Intelligence sustains. Its borders extend beyond any technique or technology, and that makes all the difference.





from A List Apart: The Full Feed http://ift.tt/1zUjg5s

via IFTTT

Five Things They Didn’t Teach Me in School About Being a User Researcher

go to article

by Chelsey Glasson

September 16th, 2014 4 Comments

Graduate school taught me the basics of conducting user research, but it taught me little about what it’s like working as a user researcher in the wild. I don’t blame my school for this. There’s little publicly-available career information for user researchers, in large part because companies are still experimenting with how to best make use of our talents.

That said, in the midst of companies experimenting with how to maximize user researchers, there are a few things I’ve learned specific to the role of user researcher that have held true across the diverse companies I’ve worked for. Some of these learnings were a bit of a surprise early on my my career, and I hope in sharing them I’ll save a few from making career mistakes I made in the past for lack of knowing better.

There’s a ton of variation in what user researchers do.

In my career, I’ve encountered user researchers with drastically varying roles and skillsets: many who focus solely on usability, a few who act as hybrid designers and researchers, some that are specialists in ethnography, and yet others who are experts in quantitative research. I’ve also spoken with a few who are hybrid market/user researchers, and I know of one tech company that is training user researchers to own certain product management responsibilities.

If you take a moment to write down all of the titles you’ve encountered for people who do user research work, my guess is that it will be a long one. My list includes user experience researcher, product researcher, design researcher, consumer insights analyst, qualitative researcher, quantitative researcher, usability analyst, ethnographer, data scientist, and customer experience researcher. Sometimes companies choose one title over another for specific reasons, but most of the time they’ll use a title simply because of tradition, politics, or lack of knowing the difference.

At one company I once worked for, my title was user researcher, but I was really a usability analyst, spending 80% of my time conducting rapid iterative testing and evaluation (RITE) studies. When I accepted the job at that company, I assumed–based on my title–that I’d be involved in iterative research and more strategic, exploratory work. I quickly learned that the title was misleading and should have been usability analyst.

What does this all mean for your career?

For starters, it means you should do a ton of experimentation while in school or early on in your career to understand what type of user research you enjoy and excel at most. It also means that it’s incredibly important to ask questions about the job description during an interview to make sure you’re not making faulty assumptions, based on a title, about the work you’d be doing.

Decisions influence data as much as data influences decisions.

I used to think the more data the better applied to most situations, something I’ve recently heard referred to as “metrics fetishism.” I’ve now observed many situations in which people use data as a crutch, end up making mistakes by interpreting “objective” data incorrectly, or become paralyzed by too much data.

The truth is that there are limitations to every type of data, qualitative and quantitative. Even data lauded by some as completely objective–for example, data from website logs or surveys–oftentimes includes a layer of subjectiveness.

At the beginning and end of any research project there are decisions to be made. What method should I use? What questions should I ask and how exactly should they be asked? Which metrics do we want to focus on? What data should we exclude? Is it OK to aggregate some data? What baselines should we compare to? These decisions should themselves be grounded in data and experience as much as possible, but they will almost always involve some subjectivity and intuition.

I’ll never forget one situation in which a team I worked with refused to address obvious issues and explore solutions without first surveying users for feedback (in large part because of politics). In this situation, the issues were so obvious that we should have felt comfortable using our expertise to address them. Because we didn’t trust making decisions without data in this case, we delayed fixing the issues, and our competitors gained a huge advantage. There’s obviously a lot more detail to this story, but you get the point: In this circumstance, I learned that relying on data as a crutch can be harmful.

What does this mean for your career?

Our job as user researchers is not only to deliver insights via data, but also to make sure people understand the limitations of data and when it should and shouldn’t be used. For this reason, a successful user researcher is one who’s comfortable saying “no” when research requests aren’t appropriate, in addition to explaining the limitations of research conducted. This is easier said than done, especially as a new user researcher, but I promise it becomes easier with practice.

You’re not a DVR.

Coming out of school, I thought my job as a user researcher was solely to report the facts: 5 out of 8 users failed this task, 50% gave the experience a score of satisfactory, and the like. I was to remain completely objective at all times and to deliver massive reports with as much supporting evidence as I could find.

I now think it’s old-school for user researchers to not have an opinion informed by research findings. Little is accomplished when a user researcher simply summarizes data; that’s what video recordings and log data are for. Instead, what’s impactful is when researchers help their teams prioritize findings and translate them into actionable terms. This process requires having an opinion, oftentimes filling in holes where data isn’t available or is ambiguous.

One project I supported early in my career involved a large ethnography. Six user researchers conducted over 60 hours of interviews with target users throughout the United States. Once all of the interviews were completed, we composed a report with over 100 PowerPoint slides and hours of video footage, summarizing all that was learned without making any concrete recommendations or prioritizing findings. Ultimately we received feedback that our report was mostly ignored because no one had time to read through it and it wasn’t clear how to respond to it. Not feedback you want to receive as a user researcher!

What does this mean for your career?

The most impactful user researchers I’ve encountered in my career take research insights one step further by connecting the dots between learnings and design and product requirements. You might never be at the same depth of product understanding as your fellow product managers and designers, but it’s important to know enough about their domains to translate your work into actionable terms.

Having an opinion is a scary thought for a lot of user researchers because it’s not always possible to remain 100% objective in bridging the gap between research insights and design and product decisions. But remember that there’s often always limitations and a subjective layer to data, so always remaining 100% objective just isn’t realistic to begin with.

Little is accomplished when data is simply regurgitated; our biggest impact is contributing to the conversation by providing actionable insights and recommendations that helps decision makers question their assumptions and biases.

Relationships aren’t optional, they’re essential.

As a student, my success was often measured by how hard I worked relative to others, resulting in a competitive environment. I continued the competitive behavior I learned in school when I first started working as a user researcher; I put my nose to the grindstone and gave little thought to relationships with my colleagues. What I quickly learned, however, is that taking time to establish coworker relationships is just as important as conducting sound research.

Work shouldn’t be a popularity contest, right? Right–but solid coworker relationships make it easier to include colleagues in the research process, transforming user research into the shared process it should be. And trust me, work is way more fun and meaningful if you enjoy your coworkers!

What does this mean for your career?

Take the time to get to know your coworkers on a personal level, offer unsolicited help, share a laugh, and take interest in the work that your colleagues do. I could share a personal example here, but instead let me refer you to Dale Carnegie’s book How to Win Friends and Influence People. Also check out Tomer Sharon’s book It’s Our Research.

Expect change–and make your own happiness within it.

Change is a constant for UX’ers. I’m on my eighth manager as a user researcher, and in my career I’ve been managed by user researchers, designers, product managers, and even someone with the title of VP of Strategic Planning. I’ve also been through four reorganizations and a layoff.

What does this mean for your career?

Change can be stressful, but when embraced and expected, you’ll find that there are benefits to change. For example, change can provide needed refreshment and new challenges after a period of stagnation. Change can also save you from a difficult project or a bad manager.

I remember a conversation with a UX leader in which he shared he once quit a job because he couldn’t get along with a peer who just didn’t get the user experience process. A few months after he quit, the peer was fired. If only he had stuck around for a while.

The U.S. Navy SEALs have a saying: “Get comfortable being uncomfortable,” which refers to the importance of remaining focused on the objective at hand in the middle of ongoing change. Our objective as user researchers is to conduct research for the purpose of improving products and experiences for people. Everything else is secondary–don’t get distracted.

For more detailed recommendations on how to deal with change as a user research, I highly recommend watching Andrea Lindman’s talk “Adapting to Change: UX Research in an Ever-Changing Business Environment.”

Concluding thoughts

I’ve been happy to see in the past two years that the user experience community has stepped up in making career advice more readily available (we could do even better, though). For user researchers wanting advice beyond what I’ve shared in this article, here are four of my favorite resources:

• Judd Antin’s talk in which he covers many opportunities and challenges of doing user research:http://vimeo.com/77110204.
• You in UX, an online career conference for user experience professionals.
• Tomer Sharon’s book It’s Our Research.
• A special issue of UXPA’s UX Magazine, with the theme of UX careers.

Enabling a Career Shift from User Experience to Service Design

via UXmatters http://ift.tt/1isSMRC

By Laura Keller

Published: June 23, 2014

“Services function effectively only when an organization orchestrates all elements of the service—including the people, communications, processes, time, technologies, space, objects, and information—holistically.”

Having managed UX professionals at various levels for many years, I find that, after five to seven years working in user experience, they often ask, “What’s next?” in their career. Some become managers of UX groups, while others, who continue to enjoy doing the work, advance to the most senior level of their current role.

But there’s one group of UX professionals whose path is less obvious. They’ve likely been working in a UX Architect or Information Architect role, doing a mix of user research and design activities. These people often reach a point where they’re feeling less challenged—and that the work they’re doing is the same, day in and day out. Even the discovery of new ideas, concepts, and methods that is part of working in user experience—for example, responsive Web design or Lean UX—and would previously have ignited their interest or presented new challenges has ceased to do so. They have likely gained strong leadership skills and, when working on projects, tend to think more broadly than the user-interface design solution currently at hand. If this sounds like you, you may be suited to a career in service design.

In my first Service Design column for UXmatters in 2011, “Why UX Professionals Should Care About Service Design,” I defined service designand began to explain how it’s conceptually different from user experience. As a reminder, services function effectively only when an organization orchestrates all elements of the service—including the people, communications, processes, time, technologies, space, objects, and information—holistically. A core difference between digital UX design and service design is that great service experiences acknowledge the equality of the service provider and the service recipient—or customer—so service design looks at the service as a system of elements with equal weight rather than a single channel that has priority.

Since I wrote my first column, many UX professionals have expressed interest in knowing more about the differences between digital UX design and service design in the hope of understanding how they can begin to shift their own careers. Thus, in this column, I’ll outline how UX professionals can evolve the way they think, how they engage in projects, and what work they must do to have more strategic outcomes—and, ultimately, define their own career path.

Shifting the Questions That You Ask

“To shift from doing digital UX design to doing service design, you need to be unremorsefully analytical and inquisitive. Questioning the value and the context of what you’re doing represents a great first step toward broadening the scope of your work.”

To shift from doing digital UX design to doing service design, you need to be unremorsefully analytical and inquisitive. Questioning the value and the context of what you’re doing represents a great first step toward broadening the scope of your work.

For example, let’s say you’re about to start a project for a human resources (HR) portal. The portal will consolidate all of an organization’s currently separate and antiquated HR-related systems—including timesheets, time-off requests, benefits, and insurance—into one cohesive, self-service Web site experience. On a digital UX design project, you would focus primarily on how to create the best portal experience and would likely consider some related aspects of the experience such as email messages, mobile access, and intra-site links.

Your questions regarding the optimal user experience for the portal and its related digital elements remain important, but to create the best experience possible, you must also have a broader understanding of the overall employee service experience because that’s an employee’s context of use for the portal. What if an employee uses the portal for some aspects of HR services, but decides to call the HR call center for others? What if an employee is new and isn’t aware of what he or she needs to do to make a request? When you’re thinking about designing this new portal, think of it as more than just a Web site. Think of it as a centralized, self-service HR experience with broader strategic considerations that are important to creating the best experience:

• What other channels exist to fulfill the same requests? Call center? In-person support center? Local HR representative?
• Why would an employee choose the self-service, online channel versus some other channel?
• Would employees go back and forth across channels for a single service request?
• What should the overall service delivery experience look like?
• Are there services that employees can get only online or only offline?
• What feedback can employees provide about their current service experience—both online and offline?
• Are the stakeholders for the portal the same as those for the offline channels?
• What else does HR do to support employees beyond the current online services that won’t be part of the portal? How do employees access those? Are they related to the proposed services for the portal? What do employees think about that?
• How would a new hire experience the portal differently from a long-term employee?
• What would be the most effective way of changing employees’ behaviors—getting them to go from to the existing sites to the new portal?

These are the types of questions that UX professionals who are evolving to take on a more strategic role should begin to ask on their projects.

Shifting Your Engagement

“Ask stakeholders to involve you in project discussions earlier—prior to scoping—so you can influence what the project ultimately becomes. Early involvement is key….”

Equally important to the questions that you ask are the circumstances in which you ask them. You should ask stakeholders to involve you in project discussions earlier—prior to scoping—so you can influence what the project ultimately becomes. Early involvement is key because, when you’re designing a service experience rather than just a digital user experience, your decisions relating to the end-to-end experience have a broader impact.

Returning to the HR service experience example, let’s say you discover that, while employees are likely to use the HR portal for most service requests, when issues become complicated, they’ll call the HR call center or visit the in-person support center. Through more discovery, you realize that HR representatives follow scripts for various types of calls that they receive at the call center and the applications that they use need to support that script. After even more digging, you realize that the current experience is broken where the HR representatives’ scripts and applications don’t sync with the information that employees have. These insights impact the requirements for not only the new HR portal, but also for the current call center tools and scripts. Only through early involvement on a project can you influence its scope to include design decisions that deliver the best service experience across all channels.

Realistically, you may not currently be involved in making early decisions about project scope. Gaining the early access that lets you influence such project decisions can take time. Nevertheless, even if you’re involved later on, you can and should ask similar questions to show that you’re thinking about the more strategic aspects of the project. How you phrase your questions and statements is key. For example:

• “I know you want to take this design approach and that’s certainly an option, but I’m wondering whether another approach might solve the same issues and be better for employees?”
• “It’s important that I understand what else employees are doing before and after using the software. Can you tell me what they’re doing before and after?”
• “I know the team has already solidified the requirements, but I’m wondering how this would be different from the existing solution?”

What might happen?

• Sometimes you’ll actually get to change small aspects of your current project for the better–with minimal impact on timing or budget.
• Often you’ll create opportunities for longer-term or later-phase work—whether relating to the design itself or to relevant change management or training activities.
• Your broader team and client stakeholders will realize that you ask hard, but valuable and important questions. They’ll begin to see you as more than someone who just “does UX design”—as a strategic partner who wants to do the right thing for them and the organization.
• You’ll become more confident about asking questions—and more importantly, know the best time to ask them and who you should ask.

When you do all of this on your current projects, your earlier involvement and greater influence on projects will become stronger possibilities over time.

Shifting Your Approach to Up-front Research

“As you begin to ask these broader questions…, you’ll need to shift your up-front insight gathering techniques to answer them. One of the first adjustments you’ll have to make as you take on more strategic work is to include more diverse stakeholders in your discovery activities.”

As you begin to ask these broader questions and gain earlier access to projects, you’ll need to shift your up-front insight gathering techniques to answer them. One of the first adjustments you’ll have to make as you take on more strategic work is to include more diverse stakeholders in your discovery activities.

For example, in the HR portal example, when thinking about the end-to-end service relationship between employees and HR, in addition to speaking to the people responsible for HR services who are accountable for the digital versions of those services, you would need access to the stakeholders who are responsible for the call center, in-person support center, training, change management, and communications. And, as you involve more people across the HR department, touching multiple aspects of HR, you’ll likely need greater visibility to and buy-in from the head of HR, under whom all of these groups reside.

Another adjustment you’ll need to make involves your up-front research with users, customers, and employees. Early insight gathering on a digital UX project would have the following characteristics:

focused—The topics that you cover in any research sessions focus on outcomes that impact user interface design decisions such as navigation and content. While you can certainly ask users about the broader context of the experience, the focus of your discussion is on the user interface.

targeted—When gathering user needs for a UX project, you can strategically identify and recruit the participants with whom you conduct your research, so you can ensure that you include the most relevant participants in the process.

simulative—Research often simulates what someone may do in a user interface. While it’s usually based on realistic scenarios with which you know users are familiar, you’ll typically ask participants to simulate situations that they may have encountered in the past or may likely meet in the future.

planned—You plan your research sessions and, accordingly, prepare a discussion guide to ensure that your conversations are productive and result in actionable outcomes.

In contrast, more service-oriented research has the following characteristics:

natural—Often research captures the actual use of a live service—for example, listening to calls to the HR call center—so you can see how people interact with the service naturally. It’s not planned, and callers may not even know they’re part of a research study.

open—Up-front research tends to be open ended, with the intent of discovering how people experience services today and what they would find valuable in the future. While you can certainly plan general categories for your observations, you’re just noting what people do and how they do it.

complex—Because of how broad a service can be, you likely need a few research approaches so you can triangulate the results and get a full view of the current and ideal service experiences. In the HR example, you may need to conduct more structured and formal interviews with employees, then complement those insights with your observations of HR representatives in the call center and in-person support center.

flexible—Because of how open and broad service-oriented research is, you must go into your research without any real assumptions, be able to start deducing insights in the middle of your research, and be prepared to shift your approach on the fly. For example, you may start out observing people using a service, then decide that you need to ask them a few questions to probe for more information on issues that you noticed during your observations.

Shifting Your Design Deliverables

“Personas illustrate who will interact with your designs. … Throughout a project, they serve as a consistent beacon against which to validate your thinking and keep you realistic about the value you’re providing.”

It’s not surprising that, if your questions and early insight-gathering methods broaden in scope, so do your deliverables. For the sake of simplicity, I’ll focus on three core digital UX deliverables—personas, prototypes, and scenarios—and illustrate how their counterparts in service design are, at their core, the same.

Personas

Personas illustrate who will interact with your designs. Whether for a digital user interface or an end-to-end service, they show the needs, preferences, behaviors, and attitudes of your target audience. Throughout a project, they serve as a consistent beacon against which to validate your thinking and keep you realistic about the value you’re providing. They also help to illustrate opportunities, ideas, and ways of designing that, without going through the exercise of creating the personas, you might not have considered.

The primary difference between digital UX design and service design with regard to personas is simple: the quantity of data and the number of personas. When defining a service, you’ll just naturally have more content to shape your personas. For our example HR service experience, personas would show behaviors relating to all channels, with no single channel—for example, digital—as the assumed focus of a persona.

In addition to your gathering more content for each persona, you’ll create more personas. Remember, you’re not designing this experience just for the employees, you’re equally considering the needs of the HR representatives who are providing the services. Therefore, you may have three to five personas representing employees and another three to five personas representing HR workers.

Prototypes

“Prototypes visualize the spacein which our personas move.”

Not so simply, prototypes visualize the space in which our personas move. In UX design, prototypes could be static wireframes or clickable, high-fidelity user interfaces. Regardless, their intent is to communicate how users or customers can interact with a digital space. In service design, service prototypes are often three-dimensional, physical environments that illustrate the various service channels and types of users who are involved in the service. This means learning to use new tools like Lego Work Play or creating physical paper prototypes.

Scenarios

Scenarios articulate the linear process in which our personas move through space. They show the steps that people take in going through the experience. Similar to personas, the exercise of creating scenarios helps uncover potential problems, as well as opportunities. The primary difference between scenarios for UX design and service design is their scale and scope. UX scenarios focus on illustrating a single persona’s steps through the relevant digital interfaces. Service design scenarios, often referred to as service blueprints, capture the service as a system, noting handoffs and interactions between service recipients and service providers across all channels.

Shifting Your Approach to Validation Research

“Service design research is more complex and … more theatrical. … You need to simulate the interactions between provider and recipient in the new service experience.”

When getting feedback on your in-progress design concepts, the differences between UX design and service design are similar to the differences characteristic of up-front research. In UX research, you might conduct a usability test whose focus is on getting feedback on the interaction design for a digital user interface from a sample of the target audience. Service design research is more complex and, as I mentioned in my original 2011 article, more theatrical.

First, you need to simulate the interactions between provider and recipient in the new service experience. Therefore, research would include samples of people in both types of roles, and participants need to act out the experience. In UX research, people may already feel awkward because they feel that they’re being tested, and it’s our role to make them feel comfortable. In service design research, the potential for people feeling awkward is even more pronounced. This means you may need to set the expectation that it’s going to be fun and interactive. So, rather than creating a discussion guide for your research, you’ll actually create a script for participants to follow, stopping at appropriate points to allow them to give feedback.

Second, because of the potential breadth of a service—across various channels and touchpoints—it can be very difficult to simulate a future experience realistically. While you may have a digital prototype that you can test, you’ll also need various props and even sets—such as those paper prototypes I mentioned earlier—for the participants to interact with.

Third, services often happen across a longer time period than a user’s interactions with a digital user experience. During a usability test, you can ascertain whether the time it takes to do certain tasks is reasonable for participants. But during service design validation research, it’s difficult to simulate time because it could extend over many hours, days, weeks, or even longer. In the HR example, consider how long it takes to get your insurance ID card after going through your HR’s benefits enrollment. How can you best understand whether that’s a reasonable timeframe? The truth is that, for some discovery objectives, you simply won’t be able to get any observable feedback—and will have to simply rely on asking whether the timeframe for or between interactions is reasonable.

Conclusion

“The design of digital user experiences and service design are not mutually exclusive. … Significant overlap exists between the two disciplines, with the only difference often being a question of scale or quantity.”

As I mentioned earlier, the design of digital user experiences and service design are not mutually exclusive. As I have hopefully illustrated, significant overlap exists between the two disciplines, with the only difference often being a question of scale or quantity.

UX design and service design are essentially two practices on the spectrum of experience design, not wholly separate practices. What this means is that UX professionals who are no longer feeling challenged by or content with the work that they’re currently doing and who aspire to do more are perfectly suited to designing great service experiences. If you want to move on to service design, all you need to do is expand your existing skillsets that you use in designing digital experiences.

- See more at: http://www.uxmatters.com/mt/archives/2014/06/enabling-a-career-shift-from-user-experience-to-service-design.php#sthash.QotqGJJr.dpuf

Web Development Skills for Information Architects

via UXmatters http://ift.tt/1sBbwme

By Judith Wusteman

Published: June 23, 2014

“Some information architects can merely propose information architectures, but the most useful information architects have skills that enable them to be actively involved in Web development.”

Some information architects can merely propose information architectures, but the most useful information architects have skills that enable them to be actively involved in Web development.

What Web skills does a good information architect need? In this article, I’ll propose a set of Web skills that a graduate with a Masters in Information Architecture would ideally possess.

Why Do Information Architects Need Web Development Skills?

“Get well-rounded individuals. Go for quick-learning generalists over ingrained specialists…. We’ll never hire someone who’s an information architect. It’s just too overly specific. With a small team like ours, it doesn’t make sense to hire people with such a narrowly defined skillset.”—from Getting Real [1]

This quote is from Getting Real, the popular book on how to build a successful Web application, which goes on to say, “Small teams need people who can wear different hats” and “Everyone should have an idea about how to architect information (whatever that may mean).” [1] These are controversial statements, but I suspect that many information architects (IAs) would agree that there’s some truth in them.

Within the information architecture community, there’s an awareness that IAs need to avoid becoming precious about what they’re prepared to do; that they need to be ready and able to get involved in activities beyond the basic information architecture work of organization, labeling, and navigation. The question is: how much more should they be able to do and in what areas?

Donna Spencer [2] suggests that, in addition to defining information architectures, many information architects also “do strategy, content writing, interaction design, and production.” So it’s not just in the area of Web skills that IAs need to be flexible.

But what about Web skills? Which would be the most useful and why? In this article, I’ll suggest the Web development skills that I think would make IAs most employable. My proposals earn’t based on a formal study, but on my understanding of the field of information architecture and on informal communications with former students and potential employers.

Of course, metadata and Webometrics are of central and growing importance to all aspects of Web development in general and information architecture in particular. However, these topics are beyond the scope of this article.

Some Pragmatic Proposals

“Many graduates with a Masters in Information Architecture will end up in roles in which they’ll design some information architectures, but that may not be their main focus.”

My proposals are pragmatic and take into account the fact that many graduates with a Masters in Information Architecture will end up in roles in which they’ll design some information architectures, but that may not be their main focus. I’ve also attempted to take into account the broad range of backgrounds and technical abilities among typical students in information architecture programs.

For example, the ENS-Lyon Masters “is open to students from all disciplines … also available as part of continuing professional development to: persons performing managerial functions wishing to acquire expertise in both IT and digital documentation; persons performing technical functions and wishing to move into positions of engineer or project manager in information architecture.” [3] While this is very broad, teachers of information studies / science are familiar with trying to convey technical Web development skills to students with very varied technical abilities. Most of the time, it works; sometimes it doesn’t. What I’m proposing won’t suit all students, so flexibility is necessary. My proposals also assume that a student is studying for a Masters degree in Information Architecture rather than just taking a single information architecture course in a larger program of study.

HTML 5

“HTML5 is highly dynamic, highly interactive, and often, highly social and collaborative.”

With the advent of HTML5, there is an awful lot more to understanding HTML than just being familiar with the concept of markup. HTML5 is a lot bigger and a lot more complex than XHTML. Many sites are still using XHTML or even HTML4. The typical XHTML site involves HTML, some CSS, and a few JavaScript calls. We’re still in the early-adoption cycle for HTML5, but it’s already clear that the Web sites and applications that we’ve become familiar with over the last decade don’t represent the future of the Web. Prior to HTML5, Web sites have largely been information-dissemination conduits; most of the content on such sites is similar to that in an organization-based magazine or brochure.

But HTML5 has exploded beyond those bounds. Its focus is no longer static markup. HTML5 is highly dynamic, highly interactive, and often, highly social and collaborative. Although HTML5 is a lot bigger and more complex than XHTML, in some ways, HTML5 is easier than XHTML. No longer having to explain HTML4 or XHTML doctypes will be a relief to many teachers. Choosing to continue designing Web sites the way we always have would be business as usual, but would miss the point of HTML5 and related Web standards and ignore their potential. Old approaches to Web development are really not what we should be teaching the next generation of IAs. Instead, we should be promoting the use of related Web standards, including the following:

• Web Workers
• Drag and Drop
• File API
• Connectivity: Web Socket/Server-Sent Events/PeerConnection
• Geo Location
• postMessage
• Web Storage, IndexedDB, Web SQL Database
• Web Audio
• Full-screen Web Components (HTML Templates, Custom Elements, Shadow DOM, HTML Imports)
• CSS—FlexBox, Animations, Web Fonts, Multi-column, transformations and transitions, regions and exclusions, media queries, calc()
• Microdata, form fields, form validation
• Web Intents
• Canvas, WebGL, advanced SVG & SMIL support
• WebRTC
• EventSource <menu>, <meter>, <progress>

HTML5 = HTML + CSS + JavaScript + Related Standards

“The seismic waves that are the mobile Web and the social Web are bound to ensure that it’s not business as usual in the Web development world.

The seismic waves that are the mobile Web and the social Web are bound to ensure that it’s not business as usual in the Web development world. HTML5 = HTML + CSS + JavaScript, but it’s also all of the related standards that I listed earlier. Initially, it was assumed that all of these extra features would be part of the HTML5 standard, but as the full extent of the new Web emerged, it became clear that there was far too much to encompass in one standard and the W3C began splitting things off from HTML5. So now there’s an entire family of standards. A good IA should understand this family of standards and fully realize the implications of what they make possible.

IA as Change Agent

The best IAs are change agents, helping others to move forward. If they’re to adopt this role, IAs must be completely au fait with what’s possible in Web site design. HTML5 is—and should be—a huge challenge for everyone in Web development. The world of Web development is changing exponentially.  Inevitably, some people are going to be left behind. The challenge is to ensure that the students emerging from academic information architecture programs earn’t among this group.

It’s not just the IAs who must up their game. HTML5 is a challenge for everyone in Web design and development. For example, visual designers have, in the past, concentrated on how things look. But with new, highly interactive Web pages, they’re going to have to extend their focus to how things behave. In other words, their role is morphing into that of interaction designers. Indeed, as the number of skills that Web development requires increases, fewer and fewer organizations will be able to afford a different member of staff to cover each role. So every employee has to wear even more hats than they do at present. (Having said this, I would not suggest that IAs take on the role of project managers—or, in agile parlance, Scrum Masters. In most cases, that wouldn’t be the best use of an IA’s skills.)

If an IA understands this sea-change in the roles of Web sites and applications, as well as Web development team members, they can support and advise other members of their team, leading the team toward the use of more dynamic interactions. IAs should sufficiently understand the potential of HTML5 that they can at least suggest to developers and visual designers what is possible for them to achieve. Alternatively, they should be able to work constructively with interaction designers, if the team includes someone with that title. You might think that all of this is someone else’s job, but it’s impossible to separate the information architecture from the way users interact with it. And, as I mentioned before, we need to be pragmatic and train IAs to be as flexible and useful—and therefore, as employable—as possible.

Learning Web Development Skills

“A Masters in Information Architecture now needs three courses in Web development skills: … HTML5 and CSS3 markup; object-oriented JavaScript—plus a popular JavaScript framework such as jQuery or Dojo; [and] the standards in the HTML5 family.”

So, in practice, what does this mean for the syllabus of a Masters in Information Architecture?

While, until recently, you might have gotten away with one course on Web publishing, in which students would learn the basics of XHTML and CSS markup and possibly a bit of basic JavaScript, I propose that a Masters in Information Architecture now needs three courses in Web development skills—each worth five ECTS (European Credit Transfer and Accumulation System) credits: [2]

• HTML5 and CSS3 markup
• object-oriented JavaScript—plus a popular JavaScript framework such as jQuery or Dojo
• the standards in the HTML5 family

Course 1: HTML5 and CSS3 Markup

First, considering the course on markup, I propose that HTML and CSS be taught from scratch. Avoid using WYSIWYG Web-page editors. Instead, stick with text editors like Notepad or more powerful Web code editors. In my experience, this is the only way to ensure that students really understand the markup—and they’ll need to understand it in the workplace. If the JavaScript course requires the use of an integrated development environment (IDE) such as Netbeans, students can use the same IDE when editing HTML and CSS.

This module should also cover the basic tenets behind HTML: document hierarchy, how to identify that hierarchy through markup, how to document hierarchies using trees, the separation of presentation and content, and building content for reuse. Focusing on these tenets in this course ensures that the students build transferable skills that will outlive the current versions of popular Web code editors.

Of course, familiarity with a Web code editor is useful—particularly if the use of that editor is ubiquitous—such as for Dreamweaver, which has a sufficiently steep learning curve that it’s helpful to have spent time getting to know it before using it in a work setting. But, in my experience, if you want to ensure a deep understanding of HTML and CSS, there just isn’t time to include how to use a Web code editor in the same five-credit course. Besides, students often can’t resist using such an editor to avoid having to come to grips with the complexities of markup. So, if you want to cover editors, do it in a separate course.

For those of us who have been teaching HTML for years, it’s tempting to save time by simply tacking a lecture on HTML5 onto an XHTML course. But doing this would prevent your teaching HTML5 as a coherent whole. Of course, it’s also important for students to appreciate where HTML5 has come from, and they will likely need to understand and edit legacy documents in earlier versions of HTML and XHTML.

Course 2: JavaScript

Many Web sites of the future will use JavaScript heavily. So budding IAs need experience in hands-on development of object-oriented JavaScript, plus at least one of the key JavaScript frameworks. A good choice for the latter is jQuery, currently the leading JavaScript framework. An alternative is Dojo. Familiarity with the composition of effective user interfaces using widgets—for example, jQuery widgets—is very useful. Even more important is an awareness of when you’d need to develop a custom widget to meet user needs. An acquaintance with the issues surrounding graceful degradation, shims, polyfills, and liquid design is important. A quick introduction to CoffeeScript might also be useful.

Course 3: Related Web Standards

“The third of our three Web-development skills courses should provide the expertise that would allow IAs to discover the potential of the continually evolving family of Web standards.”

The third of our three Web-development skills courses should provide the expertise that would allow IAs to discover the potential of the continually evolving family of Web standards. Earlier, I listed some of the main non-markup specifications in the HTML5 family. They’re all essentially client-based standards. So this course could focus on client-based standards rather than server-side development. Next, I’ll describe just a few examples that show the potential of these standards.

The Canvas

The canvas, the HTML5 drawing surface, is one of the central features of HTML5. It can be in 2D or 3D, you can use JavaScript to draw on it, and the visual results can be stunning.

Web Audio

The Web Audio standard facilitates the creation and modification of real-time audio. Web Audio provides a good example that illustrates the nature of the new HTML5 world: There isn’t a single HTML tag or CSS property associated with it. It’s composed entirely of browser objects and JavaScript.

WebGL

It is important for IAs to understand the WebGL standard because it is central to the development of the next generation of realistic 3D games and visualizations. The move from Flash to HTML5 is happening at a fast rate. For a short period, we’ll still need to develop shims in Flash for browsers that do not support HTML5. But, in general, new information architects can simply skip the Flash generation.

Local Storage

HTML5 Web sites can store large amounts of data in the client. For example, Google Calendar lets users access calendar events even when they’re disconnected from the Web. This new local-storage capability is a big change from the model to which Web developers have been accustomed until now, where any user data generally gets uploaded to the server.

Web applications that remain useful even when they’re disconnected from the Web are becoming increasingly important with the growth of tablets. Indeed, it’s the explosion of HTML5-ready mobile devices and tablets that has been responsible for the rapid move to HTML5. The mobile Web is also having great impact on the evolution of information architecture. As companies reimplement their Web sites for optimal presentation on mobile devices and tablets, and new sites target these devices, the work of the next generation of IAs will increasingly focus on such devices.

Server-side Development Environments

In addition to learning the new generation of client-side HTML5 standards, IAs also need to be aware of modern server-side development practices—such as the use of client-side widgets that are bound to server-side RESTful services—instead of traditional JSP-style dynamic Web pages. It would also be advantageous to have a general awareness of common server-side development environments such as Java, .NET, LAMP (Linux Apache MySQL PHP/Pearl), and node.js. Where should this topic fit into my three proposed courses? Perhaps just one lecture at the end of the JavaScript course.

Agile Development Processes

“An understanding of agile development processes should permeate all of the courses for a Masters in Information Architecture.”

An understanding of agile development processes should permeate all of the courses for a Masters in Information Architecture.

While more traditional development methods ignore the possibility of changes in a project’s requirements, agile development methods attempt to respond to changes. They involve a rapid succession of incremental software releases, or iterations; early coding, lean documentation, close collaboration between developers and users, and rapid feedback. Agile teams avoid defining fixed roles for specific team members as far as possible.

The five-credit Information Architecture course that the UCD Dublin iSchool [4] offers is based on a project in which a student imagines that he or she is an information architect on a team that’s creating a Web site using agile methods. This allows students to gain an appreciation for and familiarity with agile methods.

While in an agile development environment, developers may focus on development issues 100% of the time and visual designers may focus on design 100% of time, to really understand what’s possible and keep their skills fresh and up to date, IAs should do some Web development. They may take on just some of the simpler development tasks, for perhaps only 10% of their time, but their being actively involved in development is the ideal.

Life-long Learning 

“The Web is rapidly and constantly evolving, and IAs need to keep up with these changes. Part of life-long learning in relation to Web development skills involves keeping abreast of the latest best practices.”

People who want to be IAs need to understand that earning a Masters in Information Architecture would just start them on the road to becoming excellent IA practitioners. They need to be prepared for life-long learning in all aspects of their craft, but particularly in terms of their Web development skills. The Web is rapidly and constantly evolving, and IAs need to keep up with these changes. Part of life-long learning in relation to Web development skills involves keeping abreast of the latest best practices.

IAs need to know what’s possible and have at least a general idea of how to go about making it happen. In other words, they need to understand everything that a developer understands. But they also need to be aware of many other issues—notably everything to do with usability—so must know more than anyone else on their team. This is a huge demand and, inevitably, at the start of their career, IAs won’t know more than everyone else on a Web development team. But they should recognize that their career path should, ideally, lead them in that direction.

Note—This article is an updated version of an invited lecture that I presented at Architecture de l’Information - Colloque International, Écoles Normales Supérieures de Lyon, November 19–20, 2012.

Endnotes

[1] Fried, Jason, David Hansson Heineken, and Matthew Lieberman. Getting Real: The Smarter, Faster, Easier Way to Build a Successful Web Application. Chicago: 37Signals, 2006. Retrieved May 19, 2014.

[2] Spool, Jared M. “Four Essential Skills for Information Architects: An Interview with Donna Spencer.” User interface Engineering, August 27, 2008. Retrieved May 19, 2014.

[3] Master en Architecture de l’Information, ENS de Lyon. Retrieved June 9, 2014.

[4] Wusteman, Judith. “Learning to Be an Information Architect.” Journal of Education for Library and Information Science, 2013, Vol. 54, Issue 2. Retrieved May 19, 2014.

Topic: Information Architecture | Professional Development | UX Development

- See more at: http://www.uxmatters.com/mt/archives/2014/06/web-development-skills-for-information-architects.php#sthash.5iuXJutr.dpuf