The UX Professionals’ Guide to Working with Agile Scrum Teams

Written by: Aviva Rosenstein

The adoption of Agile software development approaches are on the rise across our industry, which means UX professionals are more likely than ever to support Agile projects. Many UX professionals seem stymied by the challenge of effectively integrating UX within an Agile development framework–but there are others in our field who have encountered the same problems yet are finding effective solutions.

I first encountered Agile Development in 2005, when a team I supported was chosen to help pilot Scrum development methodology at Yahoo! Inc. There are variety of Agile development approaches in use, but Scrum is currently the most popular: over 70% of software professionals using Agile methodologies employ some variant of the Scrum methodology.

When I left the company three years later, more than 150 teams at that company were using Scrum for developing both infrastructure and product features. In 2009, I moved on to Salesforce.com, where Agile methods (including Scrum) were implemented across their entire research and development organization.

In my experience, when product development is managed with an Agile development approach, user experience professionals are expected to find a way to work within the Agile framework to succeed. But, while team members may be offered training or even certification on Agile development practices, the training rarely discusses best practices for integrating UX design into the development process. And though internal surveys posted by my employers indicated that most  employees were satisfied with Agile development practices, some of my UX colleagues privately expressed frustrations with the challenge of  delivering a high quality user experience in Agile’s incremental release framework.

So, I decided to interview my UX colleagues for their perspective: What Agile practices were working well for them, and what specific pain points had they identified in the Scrum development process?

I reached out to seventy colleagues and received detailed responses from twenty UX professionals (including interaction designers, user researchers, and visual designers) who were actively supporting Scrum development teams. Many of the problems they reported indicated that both UX professionals and technical staff lacked a shared understanding of each others’ team roles and responsibilities. And other problems stemmed from UX practitioners feeling disconnected from the daily life of the development teams they supported.

Fortunately, for nearly every specific issue an informant raised as a pain point, some other colleague independently described an approach they had used to successfully resolve it with their team. By reading their responses, I learned that effective relationships between UX and technical staff could be created and sustained by actively involving scrum teams in the UX process, by active participation by UX professionals in team activities, and by frequent communication with team members about UX issues.

Here’s a summary of what what worked well for UX professionals supporting Agile development teams, as well as some of their common pain points. At the end are recommendations for individual UX contributors, UX managers, Scrum Masters and product owners, based on my colleagues’ responses and my own experiences with Agile development.

Opinions on what’s working

Informants were asked: “Thinking about how you and your UX colleagues are working with your scrum teams, what’s going well?” Their answers included the following themes.

Trust and earned respect

Both designers and user researchers shared techniques for keeping product owners and developers informed and aware of their progress. Their practices included presenting information about their roles to teams, inviting teams to observe user research sessions, and sharing documents to track progress on usability issues.

Being transparent about the UX process helped some respondents foster trust between themselves, their product managers, and the technical staff on their scrum teams.

“I have a close relationship with the product managers I am working with, the dev manager for the scrum team and the developers themselves… I am transparent about my progress and share design iterations to get their feedback and opinions. In return, they trust me and accept the value of my expertise as a designer.”

Respondents also reported creating successful relationships with their product teams by  involving their scrum teams in the UX process–especially by collaborating on UX issues with technical staff.  Giving all ideas and contributions equal consideration regardless of the role of the originator, inviting all team members to give feedback on designs, and inviting them to participate in user research all helped promote developers’ ownership of design decisions.

“One of my teams has a lot of ideas and contributes a lot to the UX of the product. Sometimes they come up with ideas that I didn’t think of and it greatly improves the product’s usability.”

Be present in the life of the scrum team

Several respondents credited active team participation (beyond UX-specific activities) with their success in building relationships and fostering trust, and with achieving more of their user experience goals. Due to conflicting schedules across multiple teams, some UX professionals were often unable to attend all scrum meetings, but one called out the value of attending scrum meetings at least once a week.

“Being a constant voice in the development lifecycle helps keep the UX vision in line.”  

“Partaking in blitzes & logging bugs helps the team know you’re there and trying to help.”

Co-location was preferred, but those serving remote teams cited use of tools like Skype and IRC to maintain close connections.

“Being available and in the aisle to be a part of the conversations that happen spontaneously.”

“I’m on skype and talk to them all day long”

Being present also made it possible to take advantage of opportunities to educate scrum teams in the moment when they raised relevant questions:

“Gaining interest to discuss UI topics can often go well when the scrum team has a particular question or is unsure on a particular thing.”

Frequent communication outside of standard agile interactions

In addition to participation in regular scrum meetings, UX colleagues shared that adding meetings specifically devoted to coordinating UX activities with the team were successful in increasing ownership  and a shared vision of the design direction.

“Regular design review meetings are helpful in keeping both the scrum teams and researchers in the loop with decisions that seem to change every 2 minutes. Regular check-ins with product owners are also helpful in knowing priorities.”

Types of meetings called out as particularly effective included regular check-ins with product owners for both user research and design, regular design review, or design initiative meetings with scrum teams, and weekly meetings with those working specifically on front end development (or even more frequently when preparing for usability tests).

Opinions on what wasn’t working

Informants were also asked to answer the question: “Thinking about how you and your UX colleagues are working with your scrum teams, what’s NOT working so well?” Answers included the following themes.

Conflicting expectations around quality, fit, and finish

Most of the concerns raised were related in some way to delivering a quality user experience–a key concern for everyone in UX regardless of role. Some people raised issues related to these conflicting expectations, specifically around a perceived lack of commitment to quality by developers and product owners. Perhaps because our view of the product is through the lens of the user experience, UX professionals pay more attention to fit and finish than product owners or other members of a scrum team when judging whether a release is ready for launch. Some informants felt that developers ignored specifications and resisted improvements, or that insufficient team resources were devoted to executing specifications aimed at improving product quality.

“The greatest obstacle is convincing the team to go the final mile to deliver a great experience.”

“The opinion that ‘This is good enough.’ Design implementation always goes to the bottom of the priority for the sake of MVP… Pushed to the next release and stay in the UX bug list forever.”

Lack of holistic planning and prioritization for the user experience

Informants raised concerns about designs being bolted onto existing products incrementally without concern for the overall product experience. Design managers who responded complained that too often they were brought in too late to the process, were left out of the loop on strategic planning, or were not adequately exposed to the product roadmap.

“No time is considered for design of the overall framework. Scrum teams jump into feature releases. They’re building inside out instead of outside in or holistically.”

Unclear expectations about the role of UX on the team

Many frustrations expressed by informants were due to a lack of clarity around the role of UX members on the scrum team. In some cases, people felt as though product owners and technical staff members did not have a clear understanding about the skills of UX practitioners, their overall role in the development process, or that they were a shared resource dividing their attention between multiple scrum teams. In other cases, the expectations held by different members of the scrum team about the timing and relationships between design and development activities appeared to be out of alignment.

Some informants raised concerns about  product owners or developers thinking of design only in very tactical terms and not recognizing the value that UX brings to the product ideation process. UX team members expected to be included in developing product strategy, but some reported that they weren’t brought into the process until after requirements were set and coding had started, leading to problems with the overall user experience delivered:

“…when it comes to designing a new product or larger holistic experience, design doesn’t get looped in until after the idea is sold and a launch date is picked and devs start working. Design needs to align earlier and sooner with the business owners to ideate and come up with a great design.”

UX team members may expect ownership of the design of the user interface, including decisions about overall  information architecture and interaction models–but this expectation will not necessarily be shared by members of the technical staff on Agile teams, who may perceive the role of the designer as simply “skinning” the user interface. This creates difficulties when developers code elements of the user interface ahead of, or at odds with, UX work and specifications still in progress.

“UX was seen as pixel pushers who made things look nice after the developers built their features”

“Developers build whatever UI they think is appropriate while a designer is working on design iteration or testing.”

Perception of UX as less valued than development

Some informants raised concerns about how UX was valued as part of product development. In particular, one respondent perceived his organization as having a “developer-centric culture” that often dismissed UX input, resulting in usability and utility deficits in the product.

“They valued developers over everyone else, to the expense of everyone else being productive. PMs and Dev managers had an exclusive relationship with a few key developers and worked on product direction and user experience direction without any involvement from the UX team… Needless to say, the product they deliver has a lot of usability problems.”

Perception that technical staff is disinterested in users’ needs

In addition to dismissing of the value of UX team members’ contributions, some informants characterized technical team members as lacking empathy with the needs of their end users:

“Sometimes engineers are thinking of the solution without understanding the need. This is understandable, but it is taking a lot of education to get the idea of understanding the need and then building a solution to fulfill that need in the minds of our engineers.”

Being disconnected from the regular activities of the scrum team

Being separated from other team members either by distance or by allocation had a negative impact on UX team members. This included difficulties navigating time differences and exclusion from remote meetings as well as missed opportunities to bond with their scrum teams.

“Difficulty in being aligned with the engineering team which is mostly in India. Timing is difficult. Stand ups are near impossible to join as they are late evening for us in the US.”

Informants who served multiple teams reported difficulties with managing time and workload, and also were concerned about managing their teammates’ expectations about their availability. User researchers, who were often supporting three or more teams, were most likely to report problems with time management and team integration, but this problem could impact any UX team member with responsibilities for more than one scrum team.

“The challenge is that supporting two teams that are both on nearly identical timelines creates a time crunch. Some of that ideal process gets cramped and I end up just getting the basics done, just in time.”

Recommendations

A few of the respondents were generally unhappy with the Agile approach to development and expressed nostalgia for waterfall development. But when I looked closely at their responses, it seemed their dissatisfaction with Agile related to uncertainty about how to integrate UX into their scrum teams’ development processes or their discomfort with discussing technical topics.

Helping new UX team members with time management skills, with improving their estimation of UX work, and with understanding the roles and responsibilities of everyone on the project team may help improve their satisfaction and effectiveness with Agile teamwork.

Although UX managers can begin improving relationships between technical and design staff by offering more training in Agile techniques to UX team members, real change will require participation from product owners, scrum masters, and technical leadership. As one participant wrote:

“The culture and attitudes really have an impact whether UX-scrum team relationships can be successful. It’s a two way effort and it doesn’t work when one of the parties is unwilling.”

The suggestions below are targeted at specific roles in Scrum and on the UX team (product owners, scrum masters, UX managers, interaction designers, and user researchers) as well as at those responsible for the employee on-boarding process (including Agile trainers and coaches). Some recommendations are relevant to more than one role, so they may appear in multiple sections.

Employee onboarding (development as well as UX)

To encourage an atmosphere of trust and understanding between UX and development staff, and clarify the role of UX for everyone on the team, consider:

  1. Explicitly training people to recognize that including specialists on teams may be necessary for some projects or sprints, and to reject the old Agile dogma that openly denigrated specialization.

  2. Including training about UX practices and process in organizational training for developers, scrum masters, and product owners (including the relevant recommendations below).

  3. Setting clear expectations for involving UX in team activities.

  4. Setting expectations early that developers and product owners participate regularly in customer contact opportunities and ideation sessions around user needs (such as design studios).

Scrum masters

To encourage an atmosphere of trust and understanding between UX and development staff and clarify the role of UX for everyone on the team, consider:

  1. Team intros at project kickoff. At the beginning of each project, give each team member a brief chance to introduce themselves and explain what they will be doing and how they need to integrate with other team members. Allow team members to ask questions and clarify answers as needed. If there are serious disconnects between the expectations of different team members, use this time to achieve consensus about the role of everyone on the team.

  2. More in-depth definitions of each role on the team.  Give a member of each discipline a chance to deliver a presentation or talk to the larger team about their skills, their background, their experience, and the tools or techniques they use in their role. This will help developers understand what UX team members do plus help UX team members understand the roles of different members of the technical staff.

  3. Including UX team in synchronous and asynchronous communication channels (such as Skype, IRC or other chat systems.)

  4. Including UX goals and needs in sprint retrospectives.

To create shared team ownership of expectations for fit and finish, consider clarifying the definition of ‘done’ to include UX criteria.

To enhance project planning and prioritization, consider improving estimation for UX efforts by:

  1. Adding knowledge acquisition activities and design exploration work to the product backlog.

  2. Separating design effort on each story from implementation effort in product backlogs.

  3. Experimenting with tools and practices that have been used elsewhere to improve estimation and tracking of UX work across the feature lifecycle or within the context of a particular release, such as story mapping, design spikes, and UX matrices.

To foster understanding and empathy for the needs of users, consider hanging appropriate persona posters in the team’s work area or scrum room.

Product owners

To improve holistic planning outcomes, consider:

  1. Drawing on the expertise of design managers and leads. Invite them to participate in early strategy and product ideation sessions.

  2. Identifying and validating core needs of target users before initiating development (and capturing that information in product personas.)

  3. Using prioritized personas to groom the backlog.

To foster understanding and empathy for the needs of users across the team, consider:

  1. Associating user stories with specific personas.

  2. Scheduling and participating in a persona development process if appropriate personas aren’t available.

  3. Encouraging team participation or observation in user research activities. Consider making this participation explicit in the backlog so it doesn’t negatively impact velocity estimations. Opportunities may include joining site visits, speaking to users at events and observing usability studies.

To clarify expectations for fit and finish, consider:

  1. Including UX criteria in the definition of done.

  2. Setting clear UX goals for each sprint.

UX managers

To enable more holistic planning, set expectations with product management and executives for UX participation in product strategy meetings at all levels.

To increase team communication across business areas or large projects, create and support mechanisms for communication about priorities, design themes and patterns, and design efforts in progress.

To enable stronger relationships to form between designers and scrum teams: consider:

  1. Limiting the number of teams each designer supports during any one release.

  2. Improving estimation for UX efforts across business areas by tracking velocities for UX across each area with a UX matrix, or maintaining a master backlog of all UX activities in conjunction with scrum masters. This data will eventually help support your requests for additional headcount.

To clarify the role of UX for everyone on the team, provide regular Agile UX training for new hires.  This training should cover:

  1. Known effective tools and practices, including design studios, story mapping, design spikes, RITE studies, and unmoderated usability tests (including click tests, cardsorts and tree testing.)

  2. Techniques for estimating and tracking design work.

  3. Explicit training about the role of UX within the Agile development process and expectations for how UX team members interact with technical staff.

Interaction designers and user researchers

To improve involvement of scrum teams in the UX process, consider:

  1. Inviting all team members to give feedback on design directions and listening to design ideas from everyone on the team, regardless of role. Design studios, product walkthroughs, usability test debriefs and user research data interpretation sessions are all effective ways of soliciting this input.

  2. Inviting teams to participate in user research activities such as joining site visits, speaking to users at events and observing usability studies.

  3. Leveraging opportunities to provide more information about your role and about UX in general whenever a team member asks questions about your work.

To improve relationships and trust with stakeholders and team members, consider:

  1. Increasing your visibility in the life of the scrum team.

  2. Calling meetings outside of the standard agile interactions when necessary.

  3. Providing access to works in progress in a collaborative workspace.

  4. Listing UX issues and tracking their status in a shared document.

To foster understanding and empathy for the needs of users, consider:

  1. Reviewing appropriate design personas with the product owner and scrum team at the start of each release, and assign priorities to each.

  2. Hanging persona posters in the Scrum room as reminders.

  3. Associating user stories with specific personas.

  4. Including the product owner and scrum team in the persona development process if appropriate personas aren’t available or complete.

Conclusion

The Agile Manifesto was written to promote better ways of developing software–but the twelve principles behind it are relevant to everyone involved in the process of software delivery, not just those who code. Better integration of UX specialists will result in better outcomes for the business and for developers who work with UX.

In the words of Scrum Alliance founder Mike Cohn, “Agile does not at all require individuals to be generalists, but individuals are expected to work together as a team.”

For Scrum and Agile to live up to its full potential, it must address the needs of all team contributors, not just software developers. Giving support and trust to UX contributors will help motivate them to do their best work and leverage more of their skills in the pursuit of excellence.

Going Beyond “Yes – and…”

Written by: Amy Marquez

My first experience in improvisational comedy was in 1989. I was a freshman at Texas A&M University. Some of the students in the theater department decided to get an improv troupe started and somehow talked me into joining them.

In the beginning, I was petrified to perform without a script. Looking back now, I can see just how much improv has taught me and how it informs the decisions I make when working with a project team to create a cohesive user experience.

There are a multitude of “rules” to improv. The one most people are familiar with is the rule of “Yes – and.” The principle behind “Yes – and” is that for a story to be successfully crafted, all players involved must agree on the premise. So if a fellow actor points at you and says “your face is green,” you accept that and move the scene forward with a green face.

What we don’t often hear about are all of the other rules of improv that can be pulled into daily work as an experience designer. What happens after you’ve said yes? What comes after the “and”?

I’ve combed through my books and through various improv websites to pull out rules I started taking for granted about 20 years ago and was surprised at just how much the regular practice of these rules has shaped my perspective when creating designs with a team or client.

Add new information

The follow on rule to “Yes – and” is add new information. Have a plan when you say “and.” You can’t move the scene forward without it. And there will be times that saying yes is very difficult. What the team or client wants is not always what you will feel is the best aesthetic, so delicately phrasing your yes’s is important.

So, if a stakeholder is telling you they want a monochromatic blue palette for their website, you answer “That sounds great – and we can use complementary color accents, like yellows or oranges, to highlight important calls to action.”

Don’t negate or deny

The opposite of “Yes – and” is “No – but.” When a project kicks off, don’t start with what the system limitations are, don’t start with the baggage of knowing that the experience needed will break corporate standard rules.

Negating is also referred to as blocking. Take time to think when your first reaction is to deny, negate, or block someone else’s ideas.

If your product owner says “we want to add social media buttons to this,” don’t tell her that’s a dumb idea. That’s a knee jerk reaction, with the operative word being jerk. Explore the idea. Think about what benefits social sharing may bring to the customer and the business.

Always check your impulses

Checking your impulses isn’t limited to cases where you want to negate or deny something. You also have to check your impulses to see if what you’re thinking aligns with the product goals. If you have design principles set out for your project, measure your impulse against them to see if it aligns with those principles.

You may have a fantastic idea, but if it’s not part of the goals of the project and doesn’t align with scenarios, personas or design principles, table that thought. Write it down for a future project where it may be a great asset.

Look beyond the words

If you’re designing experiences, you have either become or are becoming a keen observer of human interactions. Look at physical cues of people you’re meeting with. Is someone uncomfortable or unusually silent? Maybe they aren’t good at speaking out in a group setting, but if you chat with them afterwards they may offer you a wealth of insight you would have otherwise missed out on.

The same goes with usability testing. Don’t just look at how easily or efficiently the participant is getting through your flow, look at their body language. Look at their forehead – is the brow furrowed? Are the eyebrows raised? Are they tapping their feet nervously? Or are their shoulders relaxed?

Aside from just the physical, there may be underlying motivations for the way people are behaving. Try to get to the heart of the meaning behind their words and actions.

Never underestimate or condescend to your audience

Underestimating your audience is a diva move to make. That doesn’t mean you should throw around words like “affordance,” or refer to “Fitt’s law” with people who aren’t design professionals, but it does mean that you need to be careful not to talk down to them. Talking down to someone tells them that you think you’re better than they are. And guess what? You’re not.

We all have roles to play in our daily work, and one is not necessarily more important or more clever than the other. Give your “audience” respect, and you will get respect in return.

Work to the top of your intelligence

This is the flip side of not underestimating your audience. Don’t underestimate yourself. Working to the top of your intelligence means not taking the easy way out. If someone says “but that’s how we’ve always done it,” challenge the status quo.

Push yourself every day to do something better, to learn. Keep up with the blogs and articles about UX practice and theory. Engage your colleagues in meaningful, actionable discussions about the work you’re doing.

Trust your partners

Every project you work on comes with partners: front end developers, project managers, stakeholders, information architects. Trust them to do their jobs. They got where they are for a reason.

In return, you should expect them to trust you to do your job. If they don’t, then that’s an important conversation to have with your partners. Help them understand why they need to trust you.

And most important of all, trust yourself. Your experience and your expertise led you to where you are today. You need to trust in your own talent and skill. Because if you don’t trust in yourself, you can’t possibly expect others to trust you.

Do try this at home (or work)

With every new venture you have to start somewhere. I was petrified as a teenager trying improv for the first time. I can remember it very clearly. But now improv is second nature to me. Public speaking is not an issue. I was never a shy or quiet person, and improv has given me more confidence and tools to work with.

That didn’t happen over night. It happened with repeated practice. Take these rules and try putting them into practice in your daily routine. Three months from now, see what changes this has brought to your projects, clients and project teams. You’ll be pleasantly surprised.

Information Architecture’s Teenage Dilemma

Written by: Jeff Pass

Imagine if you will information architecture as a pimply-faced, malcontent teenager.  IA is eager to express and redefine itself. It wants to be an individual yet accepted by its peers. It is simultaneously aggravated and apathetic about its parents, mentors, and role-models. It is a bit of a mess, but a wonderful, beautiful mess with endless opportunity and potential.

The IA Summit (and information architecture) enters adolescence

The first IA Summit was held April 8-9, 2000, in Boston, MA, and was titled Defining Information Architecture. Now, fast forward to this year’s 13th IA Summit held April 3-7 in Baltimore, MD, in which the Summit entered the awkward teen years against the slogan “Observe Build Share Repeat.”

Taking the slogan to heart, a number of Summit workshops, sessions, keynotes, and discussions focused on reframing information architecture as a practice and as a field. Granted, IA is closer to 40 in chronological age (many date back to Richard Saul Wurman’s 1976 declaration “I am an Information Architect,” though personally I subscribe to Andrea Resmini’s Brief History timeline), but it is also experiencing adolescence thanks to a rapidly transforming digital landscape that makes puberty seem pretty innocuous. Consider, for example, the proliferation of:

  • Big data and open machine readable datasets (e.g. DATA.gov, and AWS Public Data Sets)
  • Content syndication, especially approaches like COPE (Create Once Publish Everywhere)
    • Plus increased use (and occasionally understanding) of taxonomies and metadata
  • Free and open-source:
    • Blogging and content management systems like WordPress
    • Content management frameworks like Drupal
    • Design tools like Twitter Bootstrap and hosting services like GitHub
  • HTML 5 and CSS3 with their improved capabilities especially around design and media
  • Mobile devices and technologies
  • Responsive web design in its various approaches and permutations

Like a teen whose body is changing faster than it realizes, so too is information architecture stretching and growing and developing. But information architects (at least most of them) have gone through puberty and should be able to adapt their practice and usher their field through this tectonic change.

Remaking information architecture

Coming of age is always difficult. It requires patience and introspection. It is uncomfortable, unpleasant, awkward, and is in many ways unending. But, it offers a unique opportunity to remake and improve information architecture in the face of change and to prepare for the next tools, technologies, and even modalities altering both the digital and physical landscapes.

This means making hard choices and invariably suffering missteps and setbacks. But when the IA community comes through it, it’ll be older and wiser with a better understanding and control of its body (the practice and field of information architecture). Then IA can start realizing the unmet potential of its youth. So what is the path ahead?

Define information architecture not as a concept, but as a practice and a field

For me, the highlight of the 2013 IA Summit occurred before the opening keynote. It was the pre-conference workshop, Academics and Practitioners Round Table: Reframing Information Architecture, moderated by current Information Architecture Institute president Andrea Resmini. The all-day session consisted of 30+ information architects working to identify the requirements that would lay the foundation for a common language, grammar, and poetics for IA.

While the proceedings of the workshop will be published in the Journal of Information Architecture, the real work will begin when the larger community comes together to define and formalize itself. This necessarily includes:

  • Defining what is and is not information architecture
  • Identifying and documenting the major IA schools of thought
  • Mapping out and understanding how IA relates to sibling (such as usability, information design), parent (such as architecture, library science) and extended-family (such as psychology, linguistics) fields
  • Agreeing on a basic timeline for information architecture’s intellectual history, including formative events that pre-date the emergence of the field as well as key technological and cultural events that shaped it
  • Codifying information architecture best practices and developing standards around key artifacts
  • Formalizing the requisite background, training, skills, and certifications for practitioners and then defining the various roles within IA, noting which overlap with other fields and how

Here it should be noted that individual IA practitioners, organizations, and programs have made strides in addressing the above. But until there is a confluence from across the information architecture community, these will be little more than outposts in the wild and may even promote schisms within the community.

Accepting some basic truths about the practice of information architecture

The larger discussion around remaking information architecture also includes coming to consensus around some important concepts that every information architect needs to understand. These are discussed in my April 17, 2013, Aquilent (my employer) blog post 2013 IA Summit Themes but are summarized here:

  • You cannot control device usage. Device usage will change and evolve faster than we can keep up, and it is a fool’s errand trying to predict or determine how users access content.
  • You cannot control content. Syndication and content reuse ensure that content takes on a life of its own, so it’s essential to understand and leverage taxonomy and metadata.
  • You cannot control meaning. It is not inherent or discrete and can’t be turned on and off; information architects can only share meaning and should consider a meaning-first approach.
  • To serve the users you must serve the content. Understand and leverage syndication, promote content longevity and usefulness, and consider targeted, accidental, and future audiences.
  • Sometimes you’re the architect, but often you’re the builder. We cannot always do dramatic and innovative work, but remember, the best information architecture is invisible.

There are, of course, many other concepts that are essential to the practice and field of information architecture will be identified and defined as its adolescence continues.

The time is now…

With the IA Summit turning 13 and information architecture in a time of adolescent turmoil and transformation, it seems clear that the timing is right to define and formalize both the practice and field of information architecture.

Heading into the 2014 IA Summit, members of the community need to open their minds and roll up their sleeves for the difficult, awkward, and emotional work ahead. And they should do so knowing that once information architecture enters its adulthood, it will open up new world of influence and opportunity.

Put another way – and paraphrasing B&A founder Christina Wodtke – be bold, take risks, and fail spectacularly. Now is the time to clearly define and state the communities’ vision for information architecture then set out to realize it.

The Shallow Dive

Written by: Mark Richman

At a recent job, my department faced large budget cuts. When the dust had cleared, I found I had become a UX group of one. This didn’t come with a corresponding slowdown in work – in fact, following a major rewrite of our call center application, our department was already struggling to keep pace with a backload of business initiatives. Cuts slashed our BAs, our development group, and our QAs, yet everyone remaining was being asked to speed up.

I needed to find a way to work faster and smarter and decided to address inefficiencies in my design process. As I did so, a couple of key concerns stood out for me:

Get critical design decisions made as early as possible: To go from an exploratory design to a final solution, numerous decisions needed to be made by the client. To elicit those decisions, I needed to give the client wireframes or prototypes that provided a clear context. The earlier these decisions were made, the faster I could complete the detailed design.

Reduce the client’s dependence on high-fidelity wireframes: I had routinely been asked to make painstaking changes to an early set of high-fidelity wireframes, only to discard those pages as we moved towards a final solution. Frustrating? You bet. Instead, I wanted to drive the design in the manner that Bill Buxton described in Sketching User Experiences: The fidelity of a prototype or wireframe should reflect its stage of refinement. This meant introducing low-fidelity items into the process.

Diving In

The concerns above dovetailed nicely, and to address them I formalized an early design stage I call The Shallow Dive.

Instead of attempting to achieve a final design solution, The Shallow Dive is an early UX analysis phase that is solely concerned with identifying design issues. The aim of this phase is to identify key elements and decisions that will influence the detailed design of the project.

Rough draft wireframe
A first, rough draft of wireframes is refined with the development group and then discussed with the client.

To start, the BA and I do a first-wave analysis of all of the screens and workflows that might be affected by the project. Then I create a first, rough draft of wireframes. We then refine these with the development group.  After discussing the wireframes with the client, the resulting decisions are carried forward into the detailed design.

The types of things that we look for might include:

  • What is the optimal hierarchy on each page?
  • What information is required to be carried from step-to-step of a multi-step flow?
  • What options need to be presented immediately, and what can be hidden?
  • Can we remove some non-critical information from the initial display?

Goal #1

The sole goal of The Shallow Dive is to speed the transition into a detailed design phase.

A number of things could slow this transition down. Lack of clarity in requirements may confuse translation into screen designs. Requirements that look good on paper may suffer when visualized. Without proper insight into the context of use, direction and priorities may be unclear.

To this end, within The Shallow Dive we also:

  • Identify and resolve key decision points affecting the detailed design.
  • Resolve any ambiguities encountered when the requirements are translated into screen designs.
  • Identify and document any usability issues that may appear.
  • Identify any user research needs.

Outcomes

This approach has worked well. It gets the client’s project manager into the spirit of iterative design right away. Since the first set of wireframes is deliberately rough and clearly emphasizes one or more design issues, the PM ‘gets it’ and understands the process of chipping away towards an ultimate goal. The PM shows those rough wireframes to their management, who become acclimated to using them to address a few key points, rather than solve all aspects of the project. If suggestions are made about an item that I don’t think is important at the present time, I make a note to ‘fix it in the mix’ and address it in the final design phase.

The Shallow Dive has some key advantages. Critical decisions are made earlier in the project, reducing the need for multiple iterations of detailed wireframes. This eliminates wasted time and shortens the design effort. Targeting the entire project allows us to present a comprehensive list of questions to the client at once, allowing for more effective use of the valuable face time with management. As well, the client gets experience in evaluating rough designs, making it easier to share ideas.

But most of all, the client accepts that design takes place in stages and doesn’t demand a comprehensive solution from the get-go. And that, my friends, is a little slice of heaven.

Site Speed and Usability

Written by: Toby Biddle

Did you know usability tests have shown that the maximum number of seconds a user is willing to wait, on average, before abandoning a web page, is 8.6?

If that number surprises you, it should. The study took place in 1994.

The bar is exponentially higher now for people involved in website user experience design and development when it comes to load speed. Here’s a quick look at the state of affairs.

Slow speeds are a real usability challenge. According to software and monitoring experts at Gomez and Akamai, most users (up to 73%) have encountered a site that was too slow, crashed, froze or otherwise didn’t perform.

Your visitors’ expectations are high. A sizeable 47% of consumers expect a page to load in 2 seconds or less, and 40% of people will abandon a page that takes more than 3 seconds to load.

Slow load speed can be a costly challenge. These sources estimate that a 1-second delay can lead to a 7% drop in conversions, meaning that an e-commerce site doing $100k daily would experience a $2.5M loss in sales on an annual basis tied to 1 second in load speed.

If you’re curious about the impact of load speed on conversions, and want to learn about users’ expectations for mobile browsing vs. desktop browsing, KISSmetrics has built a stellar infographic on the topic.

Mozilla ran a study to test a similar concept: what happens if the development team combines files and rearranges the source to make the Firefox home page load 2.2 seconds faster? You guessed it. Conversions increased dramatically. Firefox saw a 15.4% lift in browser downloads.

If all of this weren’t compelling enough, you should also know that organic search results can be negatively affected by slow load times. If you run search engine advertising, you’re familiar with quality score—Google’s determination of how ‘relevant’ your ad is—and you know it impacts the per-click price of your ad. Landing page speed is part of the quality score determination, too.

You get the point. The need for speed is great, and there’s a lot at stake.

What can you do to improve load speed?

There are a lot of solutions for improving how quickly your site loads. Some are simple and quick to implement, and others are tougher to tackle. Here’s a strategy to start moving your site in the right direction.

Run speed tests. Use Google’s PageSpeed Insights tool. See what easy-to-implement suggestions it spits out and heed the recommendations.

Then run your site through the Pingdom speed tool. How many requests have to be done to load your site? Are there tracking scripts that might be outdated or aren’t needed anymore? Can you consolidate any of the other requests?

Knock out the low-hanging fruit changes. Some of the recommendations you might receive include things like:

● Minimize HTTP requests.
● Resize and optimize images.
● Optimize multimedia.
● Convert JavaScript behavior to CSS.
● Use server-side sniffing.
● Optimize JavaScript for execution speed and file size.
● Convert table layout to CSS layout.
● Replace inline style with CSS rules.
● Minimize initial display time.
● Load JavaScript wisely.
● Create a dedicated landing page for mobile.

Install plugins to simplify your process. Your content management system might have plugins available that’ll make your life easier. For example, here are a couple of popular WordPress plugins that help with load speed in various ways.

W3totalcache improves site performance by improving caching with respect to the browser, page, objects, database and more. To learn more about this, you can read up on configuring the W3 total cache plugin.

WP Smush.it—Especially if you’re a blogger, you probably use plenty of images, and images can take considerable time to load. This plugin reduces image file sizes and improves performance by compressing the files.

WP Optimize—This plugin allows you to clean up and optimize your database, especially if you’re a blogger with significant archives.

When in doubt, simplicity is key. Don’t be afraid to gut components that increase load time and A/B test simpler versions of the page against their predecessors. You may be surprised at the impact of a faster loading page, even if it suddenly has less of the stuff you once considered critical.

Toby Biddle is a seasoned website usability expert and CEO of Loop11, a tool for unmoderated online user testing.

Footnotes and sources

1 Nielsen, J. (1994). Usability engineering. London: Morgan Kaufmann.
2 You can learn about the Mozilla site speed case study here.