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).
This week I presented at Cheltenham Elementary School’s Women in Science Fair as the first ever “computer” participant in the fair’s history. I decided to teach the children the basic design principles – C.R.A.P. – though I had to rearrange the letters – P.A.R.C – to take into consideration my K-5th grade audience. So we learned about Proximity, Alignment, Repetition and Contrast by assembling a poster about Toy City.
To prepare for the fair, I used stencils, spray paint and markers to create an interactive poster board. In the center, I put the pieces of information for the Toy City website on velcro so the children could move the information around and see the results spatially on the board.
The day began with the Kindergarteners who, we all agreed, were too young to grasp the “science” part of the fair. They did understand the mission given to them by their teachers: Get at least 6 sign-offs from the different tables indicating you visited. It probably wasn’t until the 3rd graders that the students really started to grasp the concepts of layout and design. I think this is a big take-away for anyone else out there keen on teaching design to younger children.
The typical conversation with each student went this way. After approaching, I would say:
Lindsay: Hi there, do you like to play with computers?
Student: YES!
Lindsay: What do you like to do on computers?
Student: Play gaa-a-ames!
Lindsay: Oh what kind of games?
Student: [INSERT SOME GAME I DON'T KNOW]
Lindsay: Well do you want to play a game today?
Student: Yes!
Lindsay: We’re going to design a website! Have you ever done that?
Student: <shakes head>
Lindsay: Well let’s design a website for ToyCity, the BEST Playground & Toy store in Philadelphia. Before we begin, lets organize the information into groups (prompt them to organize all the pieces on the table. pieces that were similar were also in the same color).
The groups of information were: Name of the Store, Taglines, Products & Availability. I walked them through each one, pointing out principles of alignment and repetition. I found Contrast was almost negligible in this exercise.
I think the highlight of the morning was the one 4th grader who, when asked what he likes to do most on the computer, answered enthusiastically, “Search facts on Wikipedia!” And when I asked him if he wanted to design a website, he cooed extra excitedly “I’ve always wanted to do that!” Unfortunately, his teacher chirped for all her students less than 20 seconds into the exercise.
From February 2010 – February 2011, I traveled to 14 Countries and 6 Continents, plus resided in the USA. Does that qualify me for an award? Maybe I should check out the URDB for that: Most countries visited in a single year!
I’m doing some housecleaning on my lap-top, upgraded the OS to 10.6, got a bigger hard-drive (500GB) and boosted the memory (4GB). This means I can start collecting all the 16GB SD cards from my trips and create a fresh new iPhoto Library organization, coagulating everything together into one large masterpiece. I just wanted to use the word “coagulating”, did you catch that?
I found these icons already on one of my hard-drives so I’m ticking one for each country, like a virtual backpack with a patch for each. In no particular order:
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:
Recent Comments