Stop banging your head against the wall, asking the wrong questions of your users and processing the feedback incorrectly; learn how to get ahead of the curve by designing better experiences and interfaces for your applications! I am very excited to announce that this month I will be teaching a beginner’s class on User Experience and User Interface Design as part of the NY-based startup SkillShare’s launch in Philadelphia!
Why? Because the future of application development is in the experience and you only get one chance to make a first impression! It’s not just a matter of redesigning your Web 1.0 (alternating colored rows in a table, yuck!) app by implementing the flashiest new jQuery plugin (Woohoo, the form slides in from the left!!), it’s about picking the right design for the right use, and converting visitors to real users.
If that’s not enough, all proceeds go to the local Philly organization TechGirlz, dedicated to training the next generation of female technologists.
I would like to hear from you if you cannot make the class (so I can schedule Take 2) OR if you want to take the class AND have questions about what you will learn OR have specific goals for the class that you would like to share with me. SkillShare is all about teaching and learning, as well as building a community, so please contact me in the comments or via email (lindsaytabas [at] gmail [dot] com).
No one would ever want to design an interface like the HCFA, but I had to because it was what the user wanted. I couldn't be stubborn, I had to admit I was not a user, I had to come to a 360 degree understanding, and realize that I could not change what the users do.
Last week, I posted my tips for being an effective designer in a lean environment. This week, while perusing the UX topic on Quora, I noticed someone posted a question “What are the top 3 commandments of Web UX?“. It reminded me that I had started a Top 10 list last year and never got around to publishing it. So here you go, my Top 10 Design Principles.
Build something that supports what people do, not changes how they do it. I do not believe I have to expound on this one.
Training is not an excuse for poor design. I wrote a blog post on this topic last year. If you ever hear a teammate say “Oh, but we can train the users how to do this” then your product’s design is going in the wrong direction.
The users are always right, but they never know what they need. Listen to your users, they have vast wealths of information about their problems and what they would like to see fixed. But software designers, they are not. If a user tells you the solution, ask them first to describe the problem. Once, a non-profit explained to me that they needed users to sign-up with their website so they could RSVP to events and download a member registration form. I could have spent hours developing a multi-user system, but instead I asked them more about their event planning and how one become a member of their organization. It turns out Eventbrite could handle their events, and they were fine with the form being publicly available.
I am not the user. My teammates are not the users. The customer is not always the user. This is fairly simple. The users are the users, and they have to be able to use what you design and build for them.
Empathize with the users’ problems and end goals. If after discovery, you don’t feel like you are burdened by their problems too, you’re not going to design a world class product and the solution they need.
Don’t settle until you have a 360 degree view of the problem. If you do not have a full grasp of the entire service system, something like accounting or managerial over site will come bite you in the behind when you’re about to launch. ”Oh, the solution cannot work like that, you did not take into account XYZ.” Oh, well no one told me about XYZ. That’s not their fault, you should have asked.
Your Design should be C.R.A.P.-y : In my first semester in HCI, the first homework assignment was to redesign posters by the C.R.A.P. principles: Contrast, Repetition, Alignment and Proximity. Here’s a nice post about C.R.A.P.
Friends don’t let friends design alone (i.e. share your designs with others). It took me at least my first semester at the School of Information to go from an objective, standards-based engineer (things were fairly black and white), to a designer that fully grasped the subjectivity that is the human language and opinion. Pull in your team members, it’s part of operating in a lean environment anyways.
Stubborness is the worst trait of a designer. If a user or co-worker critics your design, take the feedback and go back to the drawing board. It took me 4 iterations to get a 10-key form right, but the users love it.
If something is difficult to do, people will not do it (ref) Also, fairly simple. It also goes very well with a sentiment I have been building that goes like, “If people don’t already do it, just because you make it easier, doesn’t mean they are going to start.” This goes well with #1.For example, providing easy social media tools to niche populations. If they’re not already talking and sharing naturally, they probably won’t talk and share just because you build them a custom app.
Don Norman said once in a lecture at the I-School that if the HCI people aren’t part of the product planning, then their value is actually lost (*paraphrased). Possibly, in the past year or two, the importance of user experience (UX) design is rising to its appropriate place in entrepreneurship circles and startup teams.
As a community, we are realizing a trained designer with a diverse skill set goes beyond the placement of buttons and the creation of CSS sprites. We UX designers now come prepackaged with the features to help inform the product roadmap (if not manage the product), work closely with software developers, and contribute to sales calls and client visits. We are a diverse breed because at the crux of our skills is not only the know how to make things look pretty and function properly, but the ability to empathize with our users’ problems and to understand people.
Today, I found myself writing an essay-of-a-response to an interesting blog article from Cooper, a design and strategy firm in San Francisco. Tim McCoy wrote in “Lean UX, Product Stewardship, and Integrated Teams” how UX designers are finding their place in start-ups, flexing their diverse skill set, and effectively contributing to lean development team. I had a few pieces to contribute that went beyond the maximum permissible (in my opinion) characters of a good comment, so here I share with you.
McCoy posits that traditional UX methodologies were developed in waterfall environments, which we can all agree upon because almost everything regarding software development began in the waterfall environment.
In the past decade of my education and career, user-centered design rose to the challenge of modern software development techniques by being inherently iterative. Research, design, develop (Lo-Fi Testing), research, design, develop (Hi-Fi Testing), research, design, develop (Alpha/Beta). My design project from the iSchool (circa 2006), LightsOn, made it to 3 iterations before the final project was due; we only had to test with 3-4 potential users each time. As I left graduate school, it seemed we were ready for agile environments, but developers and engineers were not ready for us.
It’s a combination of multiple facets that has prepared us for this meeting point where:
The users have a stronger voice, demanding better experience
There are enough designers to meet the call of duty
The developers and engineers understand where their skills end and a designer’s begins
So what can we designers do to improve our downward dog, be agile and flexible, and meet the demands of a fast moving software development team? In response to McCoy, I detail a few techniques that I use to apply myself effectively to my teams:
Involve developers and engineers in your process: Your teammates are more likely to value your user personas and user feedback if you actually explain to them who the users are. Some of my teammates have told me they really don’t care, “just get me the requirements”, while others have joined me in developing activity diagrams, data requirements and new design ideas.
Become a partner in design: In line with #1, if an interaction or data requirement is outside of your expertise, it’s a great way to involve the developers and engineers in your work. Ask, “Is this interaction even possible? Can we implement it this way?” Explain why it has to be done that way, and negotiate a solution. Be partners in design. The worst thing for you to do is to design a new feature, hand it to a developer, and, then find out the implementation is technically impossible. You just wasted a week, and probably another.
Test with anyone, at first: In one project, I put together a simple lo-fi prototype to test the intuitiveness of a new feature’s interaction. I met with one of our sales representatives for 1-hour; the meeting revealed a list of design changes, as well as new ideas given her experience with the product. You don’t necessarily need a representative from your user community to get valuable usability feedback.
Ignore LOUD users: The worst thing a company can do is adhere to the complaints and demands of a few loud users. A business-side employee pushed through a new feature that permanently locked text notes because one client did not trust his employees to make edits. It was a PR disaster. We rolled back that change in less than 24 hours, took 1 month to rethink and research, then relaunch.
Cultivate a strong relationship with Customer Support and Community Leaders: It’s really simple. The people on the phones everyday with the users know why the users want the changes they have requested. They are always my first step when researching a new feature request.
Learn the Basics of Objected-Oriented Programming and Database Structures: My 4-5 semesters between undergraduate and graduate school did not make me a trained software developer, but understanding 0…* relationships and class diagrams, as well as being able to speak in “if”, “else”, “while” and “for” gave me the tools to walk the bridge to my teammates’ side of the chasm.
Take a Tip from Business Development: When you start a new business, you value your first few customers more than any others. You never raise their fees and you service their requests in a timely matter. They repay you in recommendations and referrals. Do the same with a handful of users that you keep in touch with. Politely call them with questions about new features and bugs; it’s cheaper than running community-wide surveys and less intensive than deploying poorly designed features and processing all of the complaints.
Teach Nielsen’s Usability Heuristics: I’m a firm believer in Jakob Nielsen’s Usability Heuristics and the Heuristic Evaluation. After running a project with 90% of my coworkers with my last employer, we all shared a common language to discuss new product features.
Develop a Style Guide: Marketing and Advertising departments have style guides for the way the company logo can be used, so you should maintain one for the way the software should function. It maintains consistency, and becomes the de facto guide for any developer left to their own design-devices. They detail the shape, size and color of buttons, whether a link should open in a new window versus the existing window, and how the navigation system should function across all levels of the site hierarchy.
Finally, be well rounded. What makes me good as a designer is that I have tried a little of everything: I’ve pressed send on marketing e-mail campaigns, designed logos, built websites, and met with customers to up-sell them on products. Designing is my core skill, but in an agile environment, I can fill in on any team that is lacking a particular talent.
McCoy posted a slide deck that addresses even more ideas for integrating with a lean environment:
In my opinion, designing for the health care industry, particularly for the relationship between doctors and insurance companies, is one of the greatest design challenges of the 21st century. Here, I describe one project that sought to increase the clearance rate of electronic insurance claims for one organization in the audiology industry.
The client organization employed 8 Insurance Billing Specialists to bill thousands of insurance claims per month for over 200 clinics around the country. Their existing system of use included two different applications, 1 for the clinics and 1 for the billing office; this design caused many information gaps, overlaps and inefficiencies in their business processes.
The goals of the project were to:
Reduce the amount of time it takes to create, process and submit claims, electronically and by paper, to over 2000 Insurance Companies.
Design a Claims Console for the corporate office to review and process over 1000 claims per week.
Plug in the Claims Console to the Clinic Software so that the clinics can submit accurate claim information electronically to the billing department.
Update the existing software so that the clinic users can more accurately assess the status and track the claim through the course of the claims lifetime.
…all while meeting detailed accounting regulations.
As the lead (and only) business analyst, product manager and user interface designer, my responsibilities were to:
Identify the gaps and overlaps of information exchange between centralized billing and its
200+ clinics.
Document discovery and requirements, create UML deliverables, including user stories,
activity diagrams and use cases.
Design the user interface for both clinic, billing and administrative users.
Manage the multiple user objectives, and (often) conflicting business goals.
Work closely with the engineering team through development and testing, managing bugs, change orders and new requirements.
To read more about some of the design challenges I faced designing for these users, read Designing for 10-key Users.
Two or three years ago, it seemed that while universities were churning out students who had taken classes in Needs and Usability Assessment, User Interface Design and Development, and Social and Organizational Issues of Information, industry was still denying the benefits of such expertise on their products. These roles were confined to corporateresearchlabs, and only the bleeding edge companies (at the time) like Google and Yahoo. In the past few years, more companies seem open to the idea of having designers on their development teams, but still not being able to quantify their benefit in terms of Return on Investment (ROI) figures, they are trying to sandwich User Interface Design and User Experience Research between other roles.
UI/UX != Graphic Design
Graphic Designers are artists and extremely creative. They have amazing visual talent, and most likely honed their art through other mediums, then realized years later that the foray into technology meant more money. User Interface and User Experience designers should have a technical background complimented with expertise or familiarity in psychology, sociology and cognitive science. It’s not necessary they have a degree in computer science and a degree in psychology, but one or the other, with familiarity in each is necessary. In simplest terms, Graphic Designers make things look cool, UI/UX designers make things functional and usable for the user.
Looks Cool, But Doesn't Work
I use this analogy to highlight my point: My mom is an interior decorator. She makes homes look beautiful for our family and all of her customers. She has a good eye for patterns, fabrics, and colors, and is familiar with feng shui for organization. While my mom understands the purpose of the room, and can arrange it to succeed the goals of the room (for cooking, for leisure, for games), she’s not designing the fabric patterns, the tchotchkes, and the furniture herself. There are experts for each of these things. My mom is a UI/UX designer for homes, the pattern experts are graphic designers for the things she puts in the homes.
To employers and product managers out there – hire a UI/UX person to work with the users to understand the problem and design the product to solve that problem. This person (if they are good at what they do) will build you excellent activity diagrams, interactions diagrams, wireframes, and, if they are awesome, the beginnings of data and functional specifications. They will understand the difference between radio buttons, checkboxes, and drop-downs, and be able to give you a 360 degree view of the application in its design phase. In the wireframes, they reserve space for content, forms, and graphics. They won’t design the graphics themselves because there are trained professionals (i.e. Graphic Designers) for this, and you can hire them on freelance and save yourselves (and your company) lots of money. Besides, you will want to free-up your UI/UX person to move to the next project, or to work with the software developers through implementation.
UI/UX != UI Engineer
When Software Developers are Left to Design Error Messages
In absence of a real UI/UX designer, the role of UI Engineer is perpetually confusing for me. I have to say first that UI Engineers are no different than other software engineers. Just because they know how to write JavaScript, PHP, HTML and CSS does not mean that they are better suited than other software engineers for working with the users to design a better solution. That being said, for years experts in the industry have been saying that software developers should not be handling user feedback. When software developers are left to their own devices without user interface designers to give them guidance, we get open source projects. Firefox aside (because they had UI/UX people come help), how many open source consumer applications are used by more than a few percentage points of the population? I myself forayed into Ubuntu and Mepis, backed out 4 months later, and ended up buying a Mac. OpenOffice maybe has 11 mm active users in the US, which would be roughly 4% of the population.The operating system and applications were not intuitive or easy to use, and when they crashed, they crashed so hard that I had to use the terminal to get anywhere (but usually ended up no where).
Rarely is an excellent software developer (front or back end) particularly good at connecting with, interpreting, and responding to other people, let alone are able to translate what those people’s goals are to usable interfaces. These are all traits demanded by a good UI/UX designer. Furthermore, those of us that take a UI Engineer position expect to have more input into the UI design while still contributing some code to the application. Often what happens is that the UI Engineer is stuck with a crappy design from a Project or Product Manager not trained in UI/UX or Usability, and is expected to do much more development than they ever planned. The company and application/product suffers from not first understanding what skills they needed, and, second, finding the right talent for the job.
After several years of writing on this blog, I realized last week that I rarely write about the exact field I work in full-time, every day: User Interface and Interaction Design. This will be my first post about a design challenge I had this spring and summer: Designing a Web Interface for 10-Key Users.
Background
For a lot of designers, the real challenges are not in designing a cool teaser page or a food fetish website. The bread-and-butter for us comes in redesigning outdated user interfaces (UI) for corporate users. For the past two years in my career, I’ve worked on customizing web portals, document management systems, patient and practice management systems, and now, insurance claims processing consoles.
My current project entails customizing our out of the box patient and practice management system for 1000+ daily users, and then designing and building an entirely new insurance claims processing console for roughly 25 users at the client’s headquarters. For one specific interface, the requirements dictate that:
The user must enter 12 pieces of data per line (up to 6 lines), but be able to view over 25 pieces of data for each line.
The user must be able to use the 10-Key pad to enter these values
We know that the user processes about 100 documents per day, and, like any re-engineering project, we shouldn’t increase this time; optimally we should reduce this time.
Finally, their current interface is a desktop application, where they enter all this data into a grid with massive horizontal scrolling, no fixed left header, and a color palette of grey, black and white.
Methodology
Step 1: Do Some Research
The first topics to research are data-entry forms and 10-Key user behaviors. 10-Key refers to the user’s ability to rapidly enter numerical data using the keypad on the right of the keyboard. When you do a search online, 10-Key brings up a lot of 10-Key tests, but not a lot of information on how these users behave. If a simple search doesn’t bring up what you need, head to Google Scholar and try to locate academic research. I found:
In this paper, the author’s Visual Framework (directly pulled from the paper) is the biggest take away:
Partitioning a data set in groups and subgroups
Sorting the groups and the individual objects
Assigning graphic primitives to groups, subgroups or individual objects
Decorating the graphic primitives (assigning color and other graphical attributes)
I had two ways of creating groups and subgroups:
First Way: Data the User Entered, Static Data the System Presents, Data the System Calculates off of the Static Data
Second Way: Data by Groups, where each group has a piece of data entered by the user compared to static data, which the system uses to calculate a third data.
Step 2: Design Iteration 1
Based on this information, I did a preliminary design based on the “First Way” grouping strategy. This let the user view static data and then select an option to enter the additional data by line. The interaction became “Click, View Modal Pop Up, Enter Data, Close Modal Pop Up, See Calculated Data”. While the Modal Pop-up was positioned so that the user could see the static data while entering the new data, the piece of feedback I got from the client was “That’s too many steps when you’re processing 1-6 lines per document, over 100 documents per day.”
Step 3: Iterate
The worst characteristic of a designer is stubbornness; you have to be able to process feedback and iterate. The goal now was to reduce the amount of steps, while still being able to view all of this data in one screen for each line-item. If I didn’t already state this, when you are confined to 950px in width, 20+ pieces of data per line-item forces horizontal scrolling. To me, horizontal scrolling is the bane of my existence as a designer. I had to do it once before, and it made me feel really uncomfortable. I was open to redesigning the screen, but at this point, I was still hostile to horizontal scrolling. I think it’s a huge no-no, and apparently these people agree with me, and these people too, who say “But requiring a large percentage of your site visitors to scroll in two directions to see your content is rude.”
I decided to continue my research into 10-Key user behavior and found a few more helpful tips (from Databasics):
Don’t force users to scroll (Thank you!)
Go easy on the fonts (Duh?) and colors.
Abandon defaults
Check Your Tab Order
Be Consistent
The last two are the most important for 10-Key users because they use the keypad to tab through the form, and often, they do not look up at the screen until they are finished - so consistency is very important; they memorize the field order very quickly.
I then found a cached-version of “Web UI Design for Data Entry-Oriented Users“, where the writer created a very relate-able persona (..of sorts) for this type of user. These users gained “operational efficiencies” in the mainframe, DOS era which the mouse-navigable screens of today cannot afford. The author points out the following:
Maximizing the amount of data that can be entered between trips to the server.
Lean, fast web-side code that serves up light, text-based pages.
Use of client-side code (e.g. JavaScript) to push as much business logic out to the client and limit round trips to the server as much as possible.
Get the tab order right for keyboard-based navigation from field to field.
Take advantage of keyboard shortcut (“accelerator key”) functionality made available by browsers.
Make efficient use of screen real estate.
My Final Design
I iterated about 4 times on this design before we settled on a design that worked for the client and the user, and one that I could feel proud of (and willing to share here). My original groupings didn’t work until I realized that the data could be partitioned further into the following:
Group 1: Static Data that never changed, and was never compared to data that is entered.
Group 2: Static Data that never changed, and was compared to data that is entered.
Group 3: Data that is entered by line-item
Group 4: Data that is calculated as the difference between Group 2 & Group 3.
Group 5: Data that is entered, and applies to all line-items
My final Design
This allowed me to partition the page into widgets that were all viewable at the same time, and reduce the number of data that had to be showed on the same line, inline. While I could make this gain, I still had to cave in to the horizontal scroll. If you’re going to use horizontal scrolling, make sure you use a fixed header and fixed left column, so that the user always knows where they are in the grid (if they do look up from the document and 10-key pad). You may not like it as a designer, and you’re developers don’t like it in implementation, but your user will be satisfied.
Looking at the design, the user enters data into the form, and when they select “Finish”, basic information about that form is posted into the upper right widget. The user can later navigate back to what they entered by selecting the link(s) posted there. The upper left widget is purely informational, and contains links to related pages in the system.
Final Take-Aways
I found another article, which didn’t add much in substance, but one commenter did say something along the lines of “The reason you cannot find screen shots and examples of good web-based data entry design is because there’s not much out there for anyone to brag about”. This is the primary reason why I am posting my stripped-down wireframe here.
There are so many advantages to building a web-based application for a new client when it comes to design. You can use more colors and provide better visual cues; if you’re innovative, you can use some jQuery to provide audio cues on form validation too. But, there are serious draw backs in web-based interfaces for data-entry, including designing for multiple browsers, sticking to a particular screen resolution and width (max: 950px now is what I believe the average is), and affording rapid data-entry.
I hope that you have found something here to help you on your journey to conquering this particularly difficult design challenge.
Recent Comments