Boxes and Arrows: Comments by Melissa Robison

Melissa Robison — Thu, 23 Aug 2007 18:28:23 GMT

Good article Kyle.

I agree that the PDF Prototype is not right for every project or team. However, I will also continue to keep this method in my toolkit.

As an account manager I am pitching, leading, and/or overseeing several interactive projects at once. Our designers, programmers, and UX leads are shared across multiple projects and are pretty busy. Sometimes, during the brainstorming/scoping phase of a project, I can best utilize my experienced team members by just bringing them all in a room and sketching ideas on a whiteboard.

Using these initial sketches and producing a rough conceptual model in PDF form is an easy way for me to document these brainstorming discussions. This document, in turn, can inform an initial scope and budget.

As others have mentioned above, clients (and even fellow team members) are less inhibited when criticizing a rough prototype than they are criticizing a more finalized one.

I do understand that even a rough prototype can bake an infeasible, programmatically complex idea into a client’s head. I probably will only use the PDF method for higher-level concept discussions.

This article and all the following comments have been great food for thought. I’ve never used denim and will give it a try.

Thanks!

Melissa Robison — Thu, 13 Sep 2007 17:28:00 GMT

Great and useful article!
I do, however, agree with the last commenter. As stated in your article, IA, content, and design are integral to grabbing a users’ attention and enticing them to scroll down for more. However, I believe that user familiarity with the brand/content also impacts user behavior. I would venture to guess that most of the users coming to the sites mentioned above were familiar with the AOL brand and the content being delivered. I’m curious to know if there is similar research where the users are not familiar with the type of content, the subject matter, or even the brand.

On a separate note, I’m also curious to find out how the iPhone and similar portable devices are impacting acceptance of the scroll.

Thanks again for your article!

Melissa Robison — Thu, 30 Aug 2007 05:32:00 GMT

Thanks for the article! A form may not be the most exciting page to design and implement. However, as you pointed out, its success can make or break a user’s experience on a website.

Form design and usability is often overlooked by the development team during a site redesign. I’m looking forward to reading your views on the designer’s role in part two of your article.

Melissa Robison — Mon, 03 Sep 2007 09:28:31 GMT

Thanks again for the article Afshan,

Creating usable forms is a process that continually evolves with user expectations, a company’s brand/goals, technological advancements, best practices, etc…

As mentioned above, user-friendly forms can be integral to a site’s success. However, these less sexy pages can often be overlooked in a full-on site redesign when the team is focused on branding, colors, flashy features, etc.

Your article and several comments have mentioned some great things to consider when developing/designing individual form elements and functions.

Before any work starts, it’s also important to make sure forms get the proper attention in the budgeting, scoping, and planning stages. This way, forms are on everyone’s task list before the redesign ball is rolling fast down the hill. To do this, I always create a separate section for each form in all my planning documents. This helps ensure that all teams are thinking about form requirements early on and not just two weeks prior to launch. This may sound like a no-brainer, but, often this portion of the project is not chunked out in planning.

Forms are the responsibility of all departments:
• Management for budgeting, scoping, and planning
• Requirements and UX group
• Design team
• Content team (including error messages, branded thank-you pages, email notices, etc)
• Development team
• QA
• Etc…

If the team has time budgeted and scheduled to concentrate on the site forms, that is the first step to success.

I’m looking forward to reading more about best practices and considerations to keep in mind when designing and testing forms.

Melissa Robison — Thu, 06 Sep 2007 12:36:17 GMT

Afshan,
In the form planning process, I usually try to scope out a ballpark number of forms needed per site and plan for these types of activities/deliverables:
- Identify and prioritize form users
- Create success metrics/benchmarks
- Create a short user scenario or user story per user, per form
- Create sketches or annotated wireframes per form (includes draft content)
- Review with design/tech team to discuss technical/design strategy and data relationships
- Prioritize functionality if necessary and distribute functionality into “must haves” and “future wish list”
- User testing or prototyping
- Review user feedback and revise form requirements/user flows
- Apply aesthetic to forms
- Create content including error validation, thank you pages, e-mail messages, etc
- More prototyping and user testing
- Design fixes and QA
- Implementation
- Measure against metrics and repeat any steps above as necessary

The actual order, format, and content of each activity/deliverable above depends on the project’s budget, scope, objectives, etc. Also, Keep in mind that this list assumes that the other brand/site strategy work has already been done or is being done in parallel.

Reviewing samples of individual planning documents out of a project’s context may not be helpful.

Can anyone point to any articles that step through a planning process behind currently successful forms? I’d love to see any “making of the form” case studies with sample documents or document screen grabs. It would be a plus if we had cases studies for successful forms that follow best practices and also for those that are innovative or utilize new technologies. Perhaps this can be another article on this site…

Melissa Robison — Sun, 16 Sep 2007 23:59:13 GMT

Thanks Shiv,
Good article.
I remember seeing a LinkedIn visualization tool that displayed a user’s connections in a graph or illustrative format. And, as we all know, there are also other data visualization tools for social networks out there. For instance, Mashable includes a few in this list: http://mashable.com/2007/05/15/16-awesome-data-visualizat….

What are your thoughts on these types of tools? Are they accurate? Which ones do you find the most interesting or helpful?

Melissa Robison — Fri, 29 Feb 2008 14:13:30 GMT

Excellent article. I’ve created many different types of site maps and content inventories in my day. It’s often a struggle to graphically represent the proposed IA in a stakeholder or client-friendly way and also tie that representation to all other phases moving forward (including maintaining a content inventory, development, and site evolution). And, of course, the actual conceptualization and ironing out of the IA/content structure can often be hindered by the very format we’re trying to use on a tight deadline.

The metro map stencil seems to be an excellent way to break out creatively from what I call “format jail” and build an IA and content inventory in a more flexible, free-form manner. I do agree with Jamie in that Visio elements and capabilities can be used to create other visual metaphors that may be more relevant to a client or project. For instance, some projects may require that the IA communicate hierarchy or relationships more clearly than the map can.

I also think you brought up a great point about needing to maintain documentation so that all previous decisions are not in one person’s head. While I’ve never yet been able to create a truly maintainable site map, I always keep an updated copy that reflects all decisions made prior to launch. Down the road, when systems start creaking at the seams again, I often use the original site map to remind myself and the team about the state of the previous site, good decisions made, old issues addressed, and the real successes of the current system.

Melissa Robison — Sat, 01 Mar 2008 23:54:45 GMT

Great article. I’ve been busy with work and just got a chance to read this.

I agree that the IA may need to be a change agent on many fronts.

A few years ago, I worked with a client to re-architect and redesign a large public site. Our team started with a usability review, developed user scenarios, conducted focus groups, developed a more user-friendly IA and content structure, and designed a site that got much closer to meeting the public site user’s needs. We also made recommendations on repurposing old content, creating new content, and deleting outdated or bad content.

The roadblock came when the client needed to gather new or repurposed content from subject matter experts. While originally behind the redesign, the subject matter experts were overwhelmed by the work they saw in front of them. Client-side staff started asking why a new IA was even necessary. It was the new IA that they thought was causing their pain…so, it was the new IA they attacked. We had planned on resistance here. We just didn’t expect it to be so strong. Part of the problem was that the client-side person in charge of content strategy didn’t really implement an internal process for content development as expected.

We didn’t want this resistance to cause failure in what we thought was a solid IA and a great site improvement. In this case, we acted as their internal change agent. Our IA and content expert quickly scheduled a meeting with all content providers, discussed their concerns, and then scheduled a half-day workshop where our team helped them prepare content to fit into the new IA. We also provided quick-start tips and checklists. It became a fun workshop and some staff even completed their content during that session. In the end, the public site was a huge success and the staff supported the new IA.

Melissa Robison — Fri, 26 Oct 2007 16:56:44 GMT

Thanks for the article Karl,
You provide good and specific examples outlining the limitations of using server logs to accurately analyze a site’s usability, success, and/or user flows.

I agree with Peter and others above about the importance of looking at all available tools objectively, understanding their individual limitations, and then moving forward to extract the best value from all tools at hand.

While I’m not personally a fan of using server logs to measure usability, I’ve had to defend my position and discuss the pros and cons of using server log data with clients and peers. Often, I’m also in the position of recommending the best approach for clients to extract accurate user data from existing sources prior to planning a site redesign. Sometimes, the server logs or poorly implemented analytic software are the only data sources we have to review. The examples in your article will enable people in similar situations to analyze the data in an informed manner.

I think it’s also important to keep in mind that less experienced User Experience “experts” are consulting with clients or working on sites every day. In my opinion, this discussion is a valuable one for them.

Melissa Robison — Fri, 21 Mar 2008 03:37:50 GMT

Anthony,
Great article and excellent follow-up comments.
I agree with Jason that the information in this article can help explain the roles and skills of the UX group to internal teams and also to clients.

I liked Alexender’s comment about a UX candidate needing tons of patience and also a quick mind. I am an account manager at an interactive agency. Patience, agility, and speed are necessary when working in an agency environment or under deadlines. A star candidate would bring relevant skills to the table while being able to build consensus, negotiate deadlines, and also adhere to budget. A tall order!

Melissa Robison — Sat, 22 Mar 2008 00:24:26 GMT

Excellent article!
Yes, a persona can end up being a forgotten document if you’re not careful. One method I use to make sure that personas are useful in the entire process is to always include a prioritized list of primary and secondary tasks that each persona/user group will want to perform in the chosen application/site. This way, our team will always refer back to the persona when developing content, design, and functionality.

Melissa Robison — Tue, 23 Sep 2008 16:28:54 GMT

Nice Article.

I conducted a QTUT last month for a client with a small site site redesign. The site had limited functionality and I had only a week to conduct the usability tests and compile a list of recommended design changes.

We actually recruited the participants and conducted the tests via email. For the participants, we chose a set of web savvy and creative people via our collective social networks. We offered a downloadable gift and found a number of well-screened and enthusiastic participants!

We then conducted all the tests via email by sending a link to the beta site and a link to a web form with the test questions. Our method was much like the one you listed in the article above and we got great and useful feedback. Of course, we were only able to identify the low hanging fruit and easy-to-fix items…but, we caught many copy, layout, and functional snafus that our design and developement team missed because we were too close to the project!

I’m looking foward to the second part of your article!