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:
A Heuristic Evaluation is a usability inspection method performed systematically; it is traditionally part of an iterative UI development process and an alternative to user testing. For this project, an evaluation was performed with all employees within the company. We used the heuristics more loosely to guide discussion around the major functional areas of the product.
The goals of a heuristic evaluation are:
To find usability problems, both major and minor
To judge the software’s compliance with recognized usability principles
The discussion elicited many ideas and visions for how the product can accommodate its vast client needs. The largest benefit was the consensus building and idea trading taking place between colleagues from different departments within the company.
Why Perform a Heuristic Evaluation of Your Product?
A Heuristic Evaluation project is the first step in evaluating an existing product’s strengths and weaknesses, and will support brainstorming within a company on improvements for the next version. The primary outcome of the project is a compiled design evaluation that includes new feature proposals and high level design principles. The secondary outcomes of this type of project is to unite the different business units of the company, promote creativity and forward thinking, and build a shared sense of team and common goals. A tertiary benefit, which should be part of every company’s knowledge management efforts, includes hard-coding employee domain expertise so that in the event of anyone’s departure, this knowledge remains an asset to the company, and does not walk away with the employee. We may also include education as a benefit, in that more team members grasp basic usability principles that they can carry with them as they embark on features and bug fixes that don’t have time to be reviewed by a designer or analyst.
Background
In April 2008, I was the first trained “any role”* that sat between the client and the software development team. The product has sailed by for the previous 5 years because it was the only web-based SAAS product on the market in its industry. When you have that type of advantage, little effort is required to retain customers. That means that features were poorly implemented and based on only a few loud clients’ requests, the sales team was allowed to oversell the product, and the customer support team was left to handle dissatisfied users. All of this, after five years, left the majority of development resources stuck fighting fires, rather than building a world-class, scalable application. It was also clear that there was a breadth of domain expertise from all parts of the company, but little time to share that knowledge, nor build up from it.
After the first 6 months at work, I lobbied the CTO and the rest of the management team to allow me to collect our company’s knowledge by running a Heuristic Evaluation on our out-of-the-box product. Not only would I be able to hard-code this knowledge as a company asset, I would be able to learn more from my co-workers in order to build better features and modules, as well as work towards Product 2.0.
Help Users Recognize, Diagnose, and Recover from Errors
Help and Documentation
Methodology
Over a two week period, I held 8 team meetings. The company was divided into 4 groups for the first week, and a different 4 groups for the second week. Each group (for each week) was made up of participants that had varied roles and expertise within the organization. For example, one group had a junior and senior programmer, a customer support associate, a trainer, and a sales associate. The idea was to build groups with employees that may not normally trade ideas about the product.
During each 1 hour meeting, a different functional area was the focus. One group looked at scheduling, while another looked at invoicing, and so on. At the beginning of each meeting, we reviewed Jakob Nielsen’s 10 Usability Heuristics (listed below). We then went through 4-5 major user tasks within the assigned functional area; for example, Create a New Patient. Everyone would have a few minutes to perform the task and take notes, then I would choose one person, usually the one least likely to know how to perform the task, to guide us through the steps they took to complete the task.
As one teammate discussed their frustrations, another would offer tips, while another would chime in with why the feature was implemented in such a way. Teammates from customer support would let us know if this was particularly frustrating for the users that they spoke to on a daily basis, and new programmers would detail how they may have implemented such a feature. After frustrations were aired within the context of the heuristics, I would ask everyone to tell me how the feature would operate in a “perfect world” with “no strings attached” to lead into brainstorming.
Final Report
After the 2 weeks of meeting, I prepared a final report for the management team in two versions – one detailed report and one executive report. Here are some of the components of the detailed report:
Most often violated heuristics
General Pain Points (ex: button placement, help information, data pages and forms)
By Functional Area:
Table of Pain Points with Examples and Design Opportunities
Specific features with suggested design changes
Customer Support Statistics (ex: 30-40% of our support issues deal with reports)
Business Goals (ex: Reduce the effort to train current users)
Design Goals
Design Ideas (high level)
Structural Guidelines (ex: maintain a multi-user system)
Special Considerations
Risks
Opportunities
Next Steps
* “Any Role” = Product Manager, UI Designer, User Experience Researcher, Requirements Analyst, etc. Any role that participates in translating customer needs to software requirements and functional specifications.
Recent Comments