UsabilityBlog

Here’s a crappy little form field pattern I encountered a few days ago. I haven’t seen it mentioned anywhere yet, so I’m claiming naming rights and calling it “pre-scolding.”

I’m sure you’ve encountered something like it: you’re filling in a website or app form, you enter a particular field set – in my example, it’s a DOB field set – and the second you enter what is definitely valid data, you’re scolded with flaming red error indicators.

Dude. I’m not even finished.

Notifying users of an error as quickly as possible – that is, without waiting for them to submit the whole dang form – is a good practice. But this is an overzealous application of the principle. A better and more common pattern would be to validate input and flag errors when the user leaves the last field of a set. The way this validation scheme is working, I feel like I’m being scolded before I’ve actually made a mistake. In other words, I’m being pre-scolded.

One situation where the pre-scolding pattern might be useful is when the field asks for a password with complexity requirements. In that case, flagging the field as errored upon entry and until the user satisfies the complexity rules is actually a good practice. This can also be done with dynamically refreshing content and strength meters. Here’s one example:

As you can see, the interaction make use of both textual guidance and color to guide the user toward creating a stronger password. Thanks to Misha Rudrastyh for the example.

But before you run off implementing password strength indicators everywhere, you might want to give this article a read.

Here’s what I’m doing in UX this week…

What I’m Working On

While I’m still working on the information architecture and navigation redesign project I’ve been on for about 6 months, two old clients came back for user research and workflow design.

Old client 1 is (broadly speaking) in the financial services industry. My design partner Brent Cameron and I redesigned one of their flagship SaaS products about 2 years ago. It provides financial services workers the ability to download reports that are financial and legal in nature. We’re back to solve an interesting design problem: how can the organization increase adoption of reports that are available to their customers, but require an incremental purchase?

It’s an interesting design challenge because their user base may or may not have purchase authority, depending on who they work for. So we need to design for two separate use cases:

  • The user can directly purchase add-on or supplemental reports.
  • The user must route a request for purchase to their organization’s point of contact for the application.

There’s more to the design challenge. We could design in calls-to-action in many areas of the application, but if we add too many CTA’s or we put them in places where users don’t feel they belong, we risk annoying them. We obviously don’t want to do that, so we need to be judicious in our placement of CTA’s. We’re also designing the central repository for available reports – essentially a digital store embedded within the app – but we’re fairly confident we can rely on existing patterns for this area. We’ll need a gallery pattern that organizes the reports in a sensible manner. Ideally we should provide short descriptions that relate why each report is useful and probably what users would find it most useful.

We’re also going to rely on a product page pattern for individual views of each report. Existing patterns are our friends here: more content detail, a preview, possible a download link for a sample report, the works. I’d love to have a recommendation engine dynamically a generate a view of related reports for cross-selling purposes, but for MVP any related report presentation will almost definitely be static and best-guess driven.

Old client 2…things aren’t final with them yet so I don’t want to jinx that gig. But let’s just say I’m really looking forward to it. I’d be conducting user research with developers to better understand their needs around building apps for and connecting to services provided by a high-traffic platform. I’ve spent most of my career side-by-side with developers, and while I would never ever put any code I’ve written (and it hasn’t been much) into production, I like working with developers. Designing tools for them is immensely gratifying.

Teaching

We’re in week 6 of the two 7-week courses I’m teaching for KSU. So far I’m really pleased with how the roughly 55 students are doing in the introductory class User Experience Design Principles & Concepts and the core course Researching User Experience I. A few observations on teaching UX’ers and soon-to-be UX’ers:

  • Communicating UX research and design should be treated by everyone – including me – as an opportunity for continual self-assessment and improvement. I don’t just mean creating pretty, well-formatted deliverables. As UX’ers, we should always be focused on relating research findings and design decisions in ways that meet the stakeholders more than halfway across the communication chasm. I don’t think that means we need to create our deliverables or artifacts anew for each different audience and situation. But I do believe that we should always prepare our design comm with an understanding of who the audience is. For example, will you be presenting to managers? Executives? Product managers? Blended teams? Adjust your messages accordingly. If you’re presenting to multiple audiences simultaneously – for example, VP’s of Product and Development alongside individual product and dev contributors – then you need to thread the needle, so to speak. My advice in this situation: aim for the VP’s, but have detailed supplemental (or followup) material ready for the contributors. The key is that you’re trying to build alignment up and down the org chart.
  • Some people take naturally to solving design problems, but all UX’ers benefit from a mix of analytic structure and free-form, inspiration-driven creativity. It’s been fun watching students mix these two key UX ingredients in varying proportions as they work on curriculum-based design challenges as well as challenges at their places of work.

What I’m Learning

I’m collaborating with our former students Brian Parsons and Jennifer Sweeney to create an accessibility course. So I’m catching up on the latest developments in access technologies and universal design practices.

Finally, I’m about 70% through Stephenson’s latest. Having heard next to nothing about this book, I was pleasantly surprised to discover that Stephenson ties it back to Reamde and The Baroque Cycle. Given that reading Stephenson is going to be a crash course in anything from architecture to teleology, I’m sure I’m learning…stuff. Can’t tell you what it is quite yet.

Here’s what I’m doing in UX this week…

What I’m Working On

I’m still working on the information architecture and navigation redesign project with the Cleveland-based software company. But a few interesting opportunities came my way last week:

  • An old client from the financial & real estate software world called me. His team want my design partners and I to restart support for new feature research, workflow design, usability testing, and design system updating. This is nice because it means we can essentially pick up where we left off last year for most of the products we supported.
  • A local (as in Cleveland) experience design consultancy asked me to join them on a bid to design and usability test a mobile-based patient check-in system for a regional healthcare organization. Every time I think I don’t have a network to speak of, I need to remind myself about opportunities like this.

Teaching

As I mentioned in earlier posts, I’m teaching two well-designed classes for KSU during the first half of summer: User Experience Design Principles & Concepts and Researching User Experience I. So far, so good. There’s only been a few minor hitches that were easily remedied through some on-the-fly instruction updates.

What I’m Learning

Honestly I’m so task-loaded this week it doesn’t feel like I’ll be intentionally seeking out new information. But I did learn that Neal Stephenson’s new book goes on sale tomorrow, Technically that counts as learning something, right?

Here’s what I’m doing in UX this week…

What I’m Working On

I’m continuing the information architecture and navigation redesign work with the Cleveland-based software company. In a meeting with business analyst and development contributors we reviewed our initial concepts for converging five applications into a more object- and task-based IA and navigation approach. Feedback was good, so the principal designer and I are going to prototype multiple variations for usability testing. Their user base is tough to access depending on the time of year, so we’re hoping we can line up users before the end of July.

Teaching

During the first half of summer I’m teaching two classes for the Kent State UX Master of Science program: User Experience Design Principles & Concepts and Researching User Experience I. They’re among my favorite classes to teach. The Principles & Concepts class is the first course in the overall sequence. I actually designed the most current version about two years ago. It seems to be doing well from both in terms of outcomes and student evaluations. That is, nearly 100% of students who begin the program by taking this class continue on in the program, and the course is evaluated quite positively across multiple instructors.

The research class is still solid, but I’m fixin’ to redesign it this fall before it runs again in a year. The current version was designed by Samantha Starmer, VP of Design at Capital One. The content is top-notch, but my feeling is that we should remove the survey research learning goals and focus exclusively on qualitative, small-sample observation and interview techniques. I’m not saying surveys are completely useless…unless of course I’m stuck trying to analyze the data from someone else’s poorly-designed survey. My take, having spent most of my graduate school career learning how to conduct research surveys properly, is that it takes way more time to learn survey research than we can give it in a 7-week course. So I’d rather we not send UX’ers into the world with an insufficient grasp of proper survey design, deployment, analysis, and synthesis.

Oh and I’m also supervising and contributing to the creation of our first course on accessibility and universal design. I’m excited about this. I’ve been an advocate for accessible design since…hold on, checking Google Scholar…wow. Since 2003. I’ve ran numerous trainings and workshops on accessibility, but haven’t gotten the chance to build an industrial-strength (or more accurately, academic-strength) course until now. We’re aiming to launch this course in time for the spring semester.

What I’m Learning

Since I relaunched ShermanUX I have a renewed interest in SEO and analytics. I’ve let my knowledge in this area become a bit stale and I need a refresher. So I’ll be looking for readings on site analytics and content marketing.

This summer I’m teaching two courses for the Kent State UX masters program – the introductory class User Experience Principles & Concepts, and the first of two user research classes. The intro class is a level-setting course, as we admit people with a broad range of UX and non-UX related job experience.

The Researching User Experience (RUX) 1 class gives students the opportunity to learn how user research techniques are used to help organizations accomplish their strategic business goals. Sometimes this means identifying how people organize their overall workflow and how the organization’s current solution is incorporated into peoples’ workflow. Other times user research is employed to discover opportunities, i.e., “jobs-to-be-done” that people or a business would pay to have a solution for. Whatever the specific research goal, you learn a hell of a lot by watching people work or play.

The key for me is that user research is one of the more important tools that a product manager / product owner can deploy to better understand both customers and customer value. So when UX’ers are functioning as user researchers, it’s incumbent on us to identify the underlying drivers of users’ behavior. And we best serve the organizations we conduct research for when we also understand the product owner’s goals and the organization’s objectives.

Getting students to recognize that user research is not primarily about identifying a product’s usability issues has been my biggest challenge when teaching RUX 1. It requires me to help students focus their attention on big-picture workflow and overall process pain points. It’s much easier to identify task-level usability problems in a single application, because they’re more obvious than process- and workflow-related pain points and inefficiencies. It’s harder to go deep and identify root causes.

It’s a challenge, yes. But it’s fun and gratifying when I get to watch students learn how to take a broader approach to user research and develop their opportunity-spotting skills.

I’m recommitting to journaling my experience as a working UX practitioner. I’m not sure exactly why I stopped. Between 2006 and the mid-teens I had a good run with UsabilityBlog. Somewhere along the way I probably got too task-loaded, and I just tailed off.

Here’s the thing, and I doubt it’s just me that has this feeling: it’s hard to start blogging again when you expect that every piece you produce should be worthy of a keynote speaking slot. So join me as I lower both your expectations and mine. And read on for a peek into my ongoing series I’m going to call “UX Working & Learning.”

What I’m Working On This Week

I’ve been working with a Cleveland-based software company for a few months now. This past winter I designed views and workflows for a new set of features they’re rolling out in the beginning of Q3. For the past few weeks I’m helping them redesign information architecture and navigation so their suite of products employs a consistent navigation scheme, structure, and interaction style. Like many enterprise software products, they haven’t had much in the way of a design system or any product line-wide design standards. So their five or so main products, which are increasingly converging to meet target users’ needs, are wildly inconsistent in some areas. The principal designer (actually, only designer) and I were tasked with bringing the products’ navigation and IA together, while not stranding (read: pissing off) the installed user base.

It’s a challenge, but I’ve done this type of thing before. I learned some important lessons when I led the redesign effort at Peachtree Accounting over 10 years ago. My key takeaways then were:

  • You can add a second navigation scheme and system to an existing, inefficient one. But you need to make sure they don’t interfere with each other. You have to ensure you’re not pulling the rug out from the feet of long-time users who are resistant to change, while also providing a more sensible and usable scheme and system to newer and future users who haven’t overlearned the old ways of doing things.
  • Don’t put all your redesign eggs in one basket. Design several competing alternate versions, and test them. Let iterative usability testing be the “design Darwinism” mechanism of identifying the best IA and navigation.
  • Position the design and testing as iteration zero so you can defend against “BDUF” (big design up front) accusations. Agile works great when most of the design direction is known. But UX’ers need more than your standard two weeks for a ground-up redesign or product line convergence.

What I’m Learning This Week

Sometimes I learn a soft skill technique, other times I’m heads-down in a new tool or application. This week I’m learning how to use the prototyping tool UXPin. The lead designer uses it and would like to be able to collaborate on the IA and navigation concepts. So I’m off to watch a few more video tutorials.

Here’s something for UX’ers and people who hire and manage UX’ers: I’ve updated the UX Kit for 2019.

I originally created this document as a guide for product management and development teams that wanted to incorporate user experience research and design practices into their processes, but weren’t sure how to do it.

Over the past 10 or so years it’s grown to cover new areas, including:

  • UX strategy and content specialist roles
  • How UX contributors function in agile software development environments

The most recent update includes minor corrections, updated salary information, and the addition of other publicly-available UX resources.

The UX Kit is available under a Creative Commons Attribution-Share Alike 4.0 International License. Support open culture! You can learn more about this license here: http://creativecommons.org/licenses/by-sa/4.0/

Get the UX Kit

Here’s another resource that I wanted to share with the UX community: I’ve created a template and example for a daily research recap.

I created this template as a way to quickly communicate research results to team members and stakeholders on a daily basis.

One of the more important lessons I’ve learned during my UX career is that it’s vital for UX practitioners to keep team members and stakeholders informed and aligned. Another lesson I’ve learned is speed of communication is critical in this brave new world of agile/lean product ideation, design, and development.

As the people who glean insights from users and customers, we should strive to communicate our results quickly. At the same time, we need to be clear that daily recaps should not take the place of considered analysis.

This template is intended to communicate “here’s what we’re seeing after n user sessions” as opposed to “here’s the results, now go write stories and code to this information.” When you use it, you should ensure that this understanding is shared.

It’s set up as an email, but you could just as easily drop it into Slack, Jira Agile, etc.

The template is here: https://docs.google.com/document/d/1VqgNCnlwG89WVjI7wjK3SD_6AMhKGMjUhpBW6zkdYjs/edit

Like the UX project planner, I’ve licensed it under the Creative Commons Attribution-ShareAlike 4.0 International License. As a Creative Commons work, it’s yours to use, modify, adapt, etc. Please share it, improve it, and enjoy!

UX’ers, I made a thing for you: check out version 1.0 of an open source UX project planner / tracker template I’ve been working on for a few months.

I created it as a tool to document a user experience project in an efficient and collaborative manner, as well as give clients/stakeholders visibility and accessibility into various aspects of the project.

We all know the importance of setting appropriate stakeholder expectations, attaining alignment among contributors and stakeholders, and ensuring that your project schedule, process and data are accessible by all involved.

The planner / tracker is my solution to these challenges. It’s not perfect, but it functions well as a “one place for everything” resource. You can use it to frame up the project, identify contributors and approvers, lay out the schedule, design and document your recruiting and session protocols, record your project meeting notes, and even enter your raw notes from observations or interview sessions.

Best of all IMO, your client or stakeholder can comment inline on whatever section you need reviewed. Because I’ve utilized document headings and subheadings, you can do neat things like tell the client (via email, Slack, semaphore, etc.) something like:

Hi all, I’ve drafted the recruit request and put together an initial schedule of session times and dates.

Could you please review these and provide comments and/or approvals?

The recruit request is here:

http://docs.google.com/document/foo#heading=recruitheadingID

And the participant schedule is here:

http://docs.google.com/document/foo#heading=scheduleheadingID

Some other thoughts:

  • Leave the outline sidebar on. It’s incredibly useful for jumping between sections.
  • I’d like to add a section for initial data synthesis, and possibly analysis. I just figured getting this out in the world was more important than making it perfect.
  • As you read it, you’ll see references to other tools that I employ for project work, such as SlackGoogle DriveMoqups, etc. Obviously, use what works for you. But I highly recommend including direct links to any external resources in the project planner itself.

I’ve set permissions for this as “viewable, copyable and downloadable by all.” So you should be able to just save a copy to your own G Drive, or download it to use in Word. Fair warning, I make no claims regarding formatting fidelity outside of Google Docs.

I’ve licensed it under the Creative Commons Attribution-ShareAlike 4.0 International License. As a Creative Commons work, it’s yours to use, modify, adapt, etc. Please share it, improve it, and enjoy!

Here’s a short URL for the planner / tracker: http://bit.ly/uxprojecttemplate