Source: A List Apart I work with lots of different teams and different developers. I usually know innately, as does the team around me, whether the teams we’re working with are good or not. We rarely disagree on the evaluation. But what does good mean? I find that the most valuable web developers interact with …
Source: A List Apart A couple of years ago, I was asked to help put together a code of conduct for the IA Summit. I laughed. We need a code of conduct here? The IA Summit is the nicest, most community-friendly conference ever! Those problems happen at other conferences! And they want me to help? …
Source: A List Apart When it comes to turning your big idea into a proposal that you want to submit to a conference, there are no real rules or patterns to follow beyond “just do your best” and perhaps “keep it to 500 words,” which makes the whole process pretty daunting. I’ve worked with a …
I work with lots of different teams and different developers. I usually know innately, as does the team around me, whether the teams we’re working with are good or not. We rarely disagree on the evaluation.
But what does good mean?
I find that the most valuable web developers interact with each other along a kind of implicit contract, the tenets of which are based upon web standards and proven ways of doing things that we’ve cobbled together collectively over the years. Most of the time, good isn’t generated by an individual in isolation—it’s the plurality of tandem efforts that hum along to a shared, web-driven rhythm.
When things are ticking along smoothly among devs, I find we have a common underlying way of talking and thinking about the web. We fit together in human and technical ways, upholding a shared understanding about how best to make pieces of the web fit together.
In contrast to the tired stereotype of genius coming in the form of a lone, intense hacker, much of the effective work done on the web is done within the bounds of a certain kind of communal conformance. In a good way.
A heap of obvious things goes into making an individual web developer seem good: An innate understanding of time and effort. An indestructible drive to self-educate. A lick-smart, logical mind quick to spot and take advantage of patterns. I think we look for these talents naturally.
And yet when devs work together, those skills fade back just a bit. In a (grossly oversimplified) way, as part of a larger team each developer is a miniature black box. What comes fiercely front-and-center are the interfacing edges of the people and teams. The way they talk to each other and the timbre of what they build, what they disclose and what they don’t think they need to mention.
When something unexpected pops up between healthy teams—which happens, because this is a complicated world—a communication like, “Hey, when I poke this service in this way, it throws a 500 at me” as often as not is enough information for the recipient to go off and fix it, because we have have similar scars to reference and a shared vocabulary built on common ground.
A common vernacular and communication style is an echo of a common thinking style. Underneath the chatter are cognitive technical models of the metaphors at hand, based on each team member’s perception of how the web fits together—REST, modular patterns, progressive enhancement, etc.—and how those components apply to the current project. Happy days when those internal archetypes align.
When you run into misaligned teams it is obvious. There’s a herky-jerky grating to communication. Seemingly dashed-off emails that don’t quite dig into the problem at hand. Teams where you can tell each member’s mental context differs. Code that feels weird and wrong.
A common ground engenders brilliant ideas
Unless it is the actual goal of the project, I don’t care too much if you can come up with a Nobel-worthy new implementation of a basic CRUD feature. In most cases, I’ll happily accept something predictable and expected.
This is not an argument for ignorance or apathy. Ideally, everyone should be pretty good at what they do—those individual technical skills do of course matter. I mean, part of the contract here does involve boots-on-ground time—to understand the lay of the land, to break HTTP into bits and pieces, leak some memory, screw up DNS a few times. We break and heal frequently as we gain deeper web mastery.
But having a web set of conceptual building blocks—standards, patterns, conventions—upon which we can frame and build gives us the freedom to focus on where we really need to be creative: the particular task, product, or site at hand. Common components, shared notions.
After all, the best chefs in the world don’t reinvent carrots. Instead, they identify what other remixed food components might plug into a carrot to make it divine.
Likewise, good developers are mixing up agreed-upon technical ingredients into the soup of the day. And just as a talented cook knows how to explain to the waitstaff the nuances that thyme brings to the potato, good devs know how to talk to those around them, team members both in the kitchen and beyond, about why today’s menu includes OAuth or moment.js.
It’s not just touchy-feely
It used to be that I would think, “Hey, these people seem like they’re on the same wavelength as my team; that’s cool,” but now I realize it’s likely that what seems merely like good vibrations saves prodigious time and money on projects.
In damaged teams, mental reference dissonance carries through to the outcome, manifesting itself in jarring technical mismatches, poorly-thought-through integration seams and, frankly, bugs. It’s as if people are thinking about the web in different internal language systems.
So? Things take longer, often a lot longer. Teams become frustrated with each other. Meetings and discussions are drawn-out and less fruitful. The results suffer. Things break.
I’m not suggesting we all link arms and plow out code from a single hive mind. In fact, I’d argue that the constraints imposed by a common perspective help to drive a certain kind of unique brilliance.
A couple of years ago, I was asked to help put together a code of conduct for the IA Summit. I laughed.
We need a code of conduct here? The IA Summit is the nicest, most community-friendly conference ever! Those problems happen at other conferences! And they want me to help? There are sailors jealous of my cussing vocabulary—surely I was not PC enough to be part of such an effort. But the chairs insisted. So, being a good user-centered designer, I started asking around about the idea of a code of conduct.
I found out design conferences are not the safe meetings of minds I thought they were.
One woman told me that she had been molested by another attendee at a favorite conference, and was too scared to report it. “No one will ever see me as anything but a victim,” she said. “I’ve worked too hard for that.”
At another conference, a woman was woken up in the middle of the night by a speaker demanding that she come over. When she told the organizer in the morning, he said, “We were all pretty drunk last night. He’s a good guy. He just gets a bit feisty when he’s drinking.”
Then there was my own little story. Years ago at the IA Summit, I went to talk to a speaker about something he’d said. I’m a tall, tough lady. But he managed to pin me against a balcony railing and try to kiss me. I started wondering, what if there had been a code of conduct then? What if I had had someone to talk to about it? What if I hadn’t said, “Oh, he’s just drunk”?
Maybe I wouldn’t have spent the past seven years ducking him at every event I go to. And maybe he wouldn’t have spent those same years harassing other women—women who now were missing out on amazing learning and networking opportunities because they thought they’d be harassed.
The idea of a code of conduct didn’t seem so silly anymore.
A wicked problem
Unfortunately, it still seems silly to others. Recently I was talking to another conference organizer about setting up codes of conduct, and he said, “That doesn’t happen at our conferences. People know me, and they know they can talk to me. A code of conduct will make people nervous that we have a problem. And we don’t.”
In order to feel safe enough to come forward, attendees and speakers need to know that the conference organizers are paying attention. We need a guarantee that they’ll listen, be discreet, and do something about it.
A code of conduct is a message—not a message that there is a problem, but a message that there is a solution. As much as a label on a button or a triangle with an exclamation point in it, a code of conduct tells you how a conference works.
Tweaking the UI
We are designers.
That means we make choices about the interface that sits between the people and the thing they want. We mock interfaces that aren’t clear. We write books with titles like Don’t Make Me Think. Yet when we hold conferences, we seem to assume that everyone has the same idea of how they work.
Why do we expect that people will “just know” how to use this complex build of architecture and wetware? There is a lecture; that means professional behavior! There is a bar; that means drinking and flirting! There is a reception; that means…alcohol plus speakers…network-flirting? A conference can be a complex space to understand because it mixes two things that usually have clear boundaries: social and work. If one person is working and another is looking to get social, conflict will happen.
These fluid boundaries can be particularly hard on speakers. Attendees often approach speakers with questions inspired by their talk, which could start a conversation that leads to work…or a date. It’s hard to tell; cautious flirting and cautious networking often look the same. People can feel uncomfortable saying no to someone who might hire them—or keep them from being hired.
Sometimes after giving a talk, I’ve mistaken admiration for flirtation, and the other way around. A wise speaker stays neutral, but it can be hard to be wise after a few glasses of wine. A code of conduct is useful because it spells out parameters for interaction. Some codes have even gone so far as to say if you are a speaker, you cannot engage in romantic activities like flirting. Clarity around what is expected of you leads to fewer accidental missteps.
A good code, like a good interface, sets clear expectations and has a swift feedback loop. It must:
Define clearly what is and isn’t acceptable behavior at your con. “Don’t be a dick” or “Be excellent to each other” is too open to interpretation. The Railsconf policy offers clear definitions: “Harassment includes, but is not limited to: offensive verbal comments related to gender, sexual orientation, disability, physical appearance, body size, race, or religion; sexual images in public spaces; deliberate intimidation; stalking; following; harassing photography or recording; sustained disruption of talks or other events; inappropriate physical contact; and any unwelcome sexual attention.”
Set expectations for what will happen if the code is violated, as the O’Reilly code of conduct does: “Conference participants violating this Code of Conduct may be expelled from the conference without a refund, and/or banned from future O’Reilly events, at the discretion of O’Reilly Media.”
Tell people how and to whom to report the incident.The Lean Startup Conference’s code includes: “Please contact a staff member, volunteer, or our executive producer [name], [email] or [phone number].” Providing a phone number is a massive signal that you are willing to listen.
Set expectations about how it will be handled. The World IA Day code is very clear:
A code of conduct is a little like a FAQ or a TOS. It’s clunky, and I hope someone comes up with something better. But it’s instructions on what to expect and how to behave and, most importantly, what to do when something breaks. Because, as we keep seeing, something will eventually break. It’s better if it’s not people.
A lot of conferences are adopting codes of conduct now. The Lean Startup Conference one mentioned above is heartfelt and crafted based on their values. The art and technology festival XOXO has an excellent one, based on the template from Geek Feminism. Yes, there’s a template. It’s not even hard to write one anymore. It doesn’t even take a long time.
Meet (or exceed) expectations
Any good experience designer knows that setting expectations is worthless if they aren’t immediately met. Beyond writing a code of conduct, conference organizers must also train their team to handle this emotionally charged situation, including making sure the person reporting feels safe. And there needs to be a clear, established process that enables you to act swiftly and decisively to remove violators.
So how should a conference handle it when the code is violated? There are a couple of telling case studies online: one from Elise Matthesen at the feminist science fiction conference WisCon, and another from Kelly Kend at XOXO.
In both cases, these women were immediately supported by the people they spoke with—a critical first step. In Kelly’s case, she brought her situation directly to the organizers, who listened to her and made it clear they weren’t going to blame her for the incident. Once the organizers had made her feel safe, they removed the harasser. It was improvised action, but effective.
In Elise’s case, it’s clear that WisCon was well-prepared to handle the incident. The first part of the story is exemplary:
The conference staff member (called a “safety staffer”) asked if Elise wanted someone there while she reported.
The safety staffer asked if she wanted to report it formally, or just talk it through first.
The safety staffer asked if she wanted to use her name, or remain anonymous.
And the safety staffer and the conference organizers kept checking in with her to make sure she was doing okay.
It is hard work to get the poison out of the apple. Elise writes, “Serial harassers can get any number of little talking-to’s and still have a clear record,” which has been my experience as well. Since I started writing about conference harassment, a number of women have spoken to me about incidents at various design conferences. Two names keep coming up as the abusers, yet they continue to get invitations to speak. Until more people step forward to share their stories, this won’t change. And people cannot step forward until they are sure they won’t be victimized by the reporting process.
If you are a conference organizer, it is your job to make sure your attendees know you will listen to them, take them seriously, and act decisively to keep them safe.
If you are an attendee who sees harassment, stand up for those who may be afraid to step forward, and act as a witness to bad behavior.
And if you are harassed, please consider coming forward. But I can’t blame you if you choose not to. Keep yourself safe first.
John Scalzi, author of several best selling sci-fi novels, made a pledge to his community that he would neither speak at nor attend any conference without an enforced code of conduct.
I will make the same pledge now. I will honor any commitments I’ve made previously; all new ones are subject to the pledge.
I will neither speak at nor attend conferences that do not have and enforce a code of conduct. This may prove hard, as many conferences I’d love to speak at do not have a code yet. But change takes sacrifice. Integrity takes sacrifice.
If you believe, as I do, that it is critical to make a safe place where everyone can learn and grow and network, then leave a comment with just one word: “cosigned.”
When it comes to turning your big idea into a proposal that you want to submit to a conference, there are no real rules or patterns to follow beyond “just do your best” and perhaps “keep it to 500 words,” which makes the whole process pretty daunting.
I’ve worked with a number of people submitting proposals to events over the past few years. I’ve been racking my brain trying to identify a strong pattern that helps people pull together proposals that provide what conference chairs and program planners are looking for, while at the same time making the process a bit more clear to people who really want to find their way to the stage.
I’ve found that it’s best to treat the proposal-writing process as just that—a process, not just something you do in a half-hour during a slow afternoon. One of the worst things you can do is to write your proposal in the submission form. I’ve done it. You probably know someone else who has done it. Most of our proposals probably sucked because of it. Hemingway advises us that “the first draft of anything is shit,” and this is as true for conference proposals as it is for just about anything.
When you write a proposal in the submission form, you don’t give yourself the time that a proposal needs to mature. I’ve found six solid steps that can help you turn that idea into a lucid and concise conference proposal that paints a clear picture of what your presentation will be about.
As I walk through these steps, I’m going to share my most recently created conference proposal. I’ve recently submitted this to some conferences, and I don’t yet know if it will be accepted or if I’ll have any opportunities to give this presentation—but following these steps made writing the proposal itself much easier.
Let’s get to it.
Step 1: Write down the general, high-level ideas that you want to talk about
This is a very informal step, and it should be written just for you. I use this step to take any notes I’ve stored away on post-its or in Evernote, and turn them into something resembling a couple of paragraphs. It’s an exercise in getting everything out of your head.
You don’t need to worry about being factually accurate in what you’re writing. This is the opportunity to go with what you know or remember, or assume you know or remember, and get it all into some other medium. You can fix anything that is inaccurate later; no one is going to read this but you.
For example, I’m writing a proposal for a presentation about creating “skunk works” projects (essentially, where small teams work on secret/necessary endeavors) to get things done when you’re busily leading a team and don’t really have time to get all the things accomplished that should be in place.
Here’s what I started with:
This is an extremely rough draft, and should be for your eyes only—despite the fact that I’m sharing mine with you here, in its poorly written and somewhat inaccurate state.
At this point, you’ve earned a break. You’ll want to be fresh for the next step, where we start to build a supporting backbone for your free-flowing words.
Step 2: Break your content into topic points
Review what you’ve written and begin to break that content into topics. I create bullet points for “Pain,” “Solution,” and two rounds of “Support.” I also add a bullet point I call “Personable,” so that I have a place to add how the idea is relatable to my own experience (though this sometimes ends up being covered by one of the Support points).
This isn’t final content; go ahead and lift sentences from your previous paragraphs if you feel like they’re relevant. Grammar still takes a backseat here, but do make sure that you’re addressing the topic point with some clarity. Also, spend a little time doing some fact-checking; tighten your points up a bit with real and concrete information.
As I was working through this step, I did a little more homework. I cracked open a few books and hunted down articles in order to refresh myself and feel like I was on more solid ground as I pulled the points together.
When you think about your presentation’s topic, what is the common point of pain that you believe you share with other people? What prompted you to feel that this is a strong idea for a presentation and worthy of sharing? Pain is something we all share, and when you can help someone else feel like their pain might be alleviated, they start to nod their heads, mentally say “yes!” to themselves, and begin to relate to you and your message.
After you’ve identified that common point of pain, what’s the general, high-level solution? If you are the person who found the solution, you should say so; if not, you should identify who did, and explain what you learned from it. Give enough information to assure people there is a solution. Don’t get hung up on feeling like you’ll give away the ending; people will show up to your presentation to hear more about the journey you’ve taken from that common point of pain, not just to hear you recite the solution itself.
Once you’ve worked through the pain and solution, it’s time to provide a little more information to the reviewers and readers of your proposal. Merely telling people that there is pain and a solution is great to lead with; however, it’s not enough. You’ll still need to convince people that this idea applies to a broad range of other contexts, and that this is a presentation that they need to see so that they can benefit from your wisdom. What are a couple of key points that you can use to support the validity of your proposal and the claims that you may have made?
Something personal and/or humorous (optional)
If you’re able to pull something personal into your proposal, you can help reviewers and audiences members further relate to you and what you’ve been through. It can shift a proposal from appearing to be “book report-ish” to one that speaks from your experience and perspective. I like to leave this as optional content because you may already be adding something similar in the Pain, Solution, or Supporting points sections.
It’s important not to overlook the value—and the risk—of humor. Humor is tough to do in a conference proposal. You may have a line that you find hilarious; however, great comedy relies heavily on nuances of delivery that are difficult to transmit in a written proposal (and sometimes even harder for the readers to pick up on). Take caution, and when in doubt, skip anything that could be misperceived when creating your proposal.
Together, these provide the foundation for the next step, which is where we start to get more serious.
Step 3: Turn your topics into a draft proposal
This is where we take the organization and grouping of your thoughts and turn them into a few short paragraphs. It’s time to turn on the spell checker and call the grammar police; this is a serious activity and the midway point to having a proposal that’s ready for submission.
You’ll be writing the best, most coherent sentences that you know how to craft based on your topic points. You should use your topic points as the outline for your proposal, hitting the ideas in the same order. As a refresher, here are my topic points, in the order they were created.
Once you’ve reviewed your topic points, put your writing skills to work. I did more gut-checking and fact-checking to make sure I wasn’t completely full of crap and to generally tighten up my thinking.
Notice that I didn’t just take the topic points and copy and paste them into paragraphs. Instead, I put on my editing hat and tried to establish the flow of what I was writing, keeping the paragraphs limited to 2–3 sentences for the sake of concision.
Step 4: Phone a friend
You know that friend you can always count on to tell you when you’ve got a booger on your noise or spinach in your teeth, or who will tell you when you were just a completely out-of-line jerk and you need to get your head on straight?
That’s the friend you want to send your proposal to. If you’re fortunate enough to have more than one of these friends, send it to all of them. Explain to them—clearly—what they’re about to read and what the purpose is. Give them enough background so that they can provide you with actionable feedback. Tell them about the conference, the expected audience, your topic, why you’ll be good presenting on this topic, and what your proposal is about. Finally, give them a deadline of a day or two so they can review it with the focus that it deserves.
I sent my proposal off to my friend Gabby Hon, because she’s that friend who will tell me all those things I listed above and because she’s a words-and-grammar nerd who kicks my work as hard as it needs.
She sent me feedback, and, for once, my confidence was a bit higher than it should have been. I really like my topic and really felt strongly that I’d pulled together a solid proposal. Gabby’s feedback was essentially:
You’re using “a bit” and “a little bit” too much. I’ve counted 3 so far within a paragraph
Okay, so, there’s too much “this is what skunk works is”—which I can find on Wikipedia—and not enough “why this matters to design/tech/UX”
You say you can adapt the rules, but can you give a little hint?
I mean obviously it was all about design and working around restrictions and limitations—thus skunk works
If design is best when faced with limitations, then skunk works programs are our best historical example of how to do great work under something something
Not only did Gabby provide some great things for me to think about and improve on, she was also gracious enough to let me know that I didn’t entirely stink up the page when I’d written my proposal:
It’s very good
Just the second paragraph needs some polishing
Step 5: Revise your proposal
Once you’ve had time to process the feedback, sit back down with your proposal and make adjustments. Don’t be shy about killing your darlings; the feedback you’ve received is meant to help you focus on the important parts and make them better. If something doesn’t fit, move it to a parking lot or remove it entirely.
Here is my final revision that I’ll be submitting to conferences:
There’s a bit of a method to my madness, believe it or not. Here’s a micro-version of the change log of my proposal:
I made a key change in the title; I’m pretty uncomfortable with using the word “science” (originally “The Science of Skunk Works”). I’m pretty sure “science” is making a promise that I’m not certain I can keep in the presentation, and I’d prefer not to be called to the mat for that.
I tested my title with a few friends and this title fared the best. I was leaning toward “Shoes for the Cobbler’s Kids” personally, and the feedback encouraged me to not be so precious.
I also tightened up the copy based on Gabby’s feedback, placing extra focus on the second paragraph.
Step 6: Submit the proposal to a conference
You likely had a conference in mind when you started trying to pull together your proposal. Each year, I start contemplating my primary presentation for the next year as soon as I can. Generally, starting around March through April or May is when I really start to try and think about what I’ve learned and what is worth sharing with others, and then I start collecting information—notes, articles, books, and so on—so that I can support my thinking as best as I can.
When I go through this process, then I know that I’m ready with a pretty solid proposal. I copy and paste the final, vetted version into the form and hit submit, confident that I’m not just winging it.
And sure enough, that’s when I find that last typo.
In 2005, my husband and business partner Drew McLellan had an idea for a website. He emailed friends and colleagues, we filled in the gaps, and 24 ways was launched: 24 articles in the run-up to Christmas, advent-calendar style. As I write this article, we are on day six of season 10 of that project. By 24 December, there will be 240 articles by 140 authors—many of them well-known names in web design and development. As a fun holiday season retrospective, I thought I would take a look at what 10 seasons of 24 ways can tell us about how our industry has changed—and what hasn’t changed.
By 2006, Andy Budd was teasing us with the rounded corner possibilities brought to us in CSS3 and in 2007, Drew McLellan helped us to get transparent PNG images to work in Internet Explorer 6. The article titles from those early years show how much of our time as designers and developers was spent dealing with browser bugs and lack of CSS to deal with the visual designs we wanted to create. The things we wanted to do were relatively simple—we wanted rounded corners, nice quote marks, and transparency. The hoops we had to jump through were plentiful.
The introduction to the 2013 archive of 24 ways notes that 2013 was the year that the Web Standards Project “buzzed its last.” By 2013, browsers had converged on web standards. They were doing standard things in standard ways. We were even seeing innovation by browser vendors via the established standards process. My article for the 2013 season described the new CSS Grid Layout specification, initially developed by Microsoft.
Since 2005, the CSS that we can consider usable in production has grown. We have far more CSS available to us through browser support for the new modules that make up CSS3. The things that CSS can do are also far more complex, expressive, and far reaching. We’ve moved on from spending our time trying to come up with tricks to achieve visual effects, and are spending a lot of time working out what to do with all of this CSS. How do we manage websites and web applications that are becoming more like complex pieces of software than the simple styled HTML documents of days gone by? Topics in recent years include new approaches to using CSS selectors, front-end style guides, Git, and Grunt. The web has changed, and the ways in which we spend our time have changed too.
We all got mobile
In the 2006 edition of 24 ways, Cameron Moll explained that,
The iPhone wasn’t launched until 2007, a move by Apple that forced us all to get off our lazy butts and think about mobile! In December 2007, Brian Fling explained the state of the mobile landscape half a year after the launch of the iPhone. It wasn’t until responsive design was brought to life by Ethan Marcotte on A List Apart in May 2010, however, that articles about mobile really became numerous on 24 ways. The 2011 season had four articles with the words “responsive design” in the title!
By 2012, we were thinking through the implications of designing for mobile, and for mobile data. Paul Lloyd took a look back at the two approaches for responsive images discussed in the 2011 season and the emerging proposals for picture and srcset in Responsive Images: What We Thought We Needed. Tim Kadlec reminded us that,
As we rushed to implement responsive sites and take advantage of new platforms, we had to take care that we weren’t excluding people by way of bandwidth limitations. Whether it is IE6 or mobile data, some things never change. We get excited about new technologies, then come back to earth with a bump as the reality of using them without excluding a chunk of our audience kicks in!
The work of change
In these 10 seasons, we can see how much the web has changed and we have changed, too. Every year, 24 ways picks up a new audience and new authors, many of whom would have still been in school in 2005.
Always, 24 ways has tried to highlight the new, the experimental, and the technically interesting. However, it has also addressed more challenging aspects. Whether an old hand or a newcomer to the industry, we can all feel overwhelmed at times, as if we are constantly running to keep up with the latest new thing. In 2013, Christopher Murphy wrote Managing a Mind, a piece that starkly illustrated the challenges that constantly keeping up can bring. This year, we are given a reminder that we need to take care of our bodies while performing the repetitive tasks that design and programming require.
The business archive contains some of the most evergreen content on the site, demonstrating that good business knowledge can serve you well throughout a career.
The industry that shares
Another thing that hasn’t changed over these 10 seasons is the enthusiasm of each 24 ways contributor for their subject, and their generosity in writing and sharing their thoughts. This reflects our industry, an industry where people share their thoughts, research, and hard-earned experience for the benefit of their peers.
On that note, I’ll close my final A List Apart column of 2014. Best wishes to all of you who are celebrating at this time of year. I look forward to sharing my thoughts on the business side of our industry throughout 2015.
“Producing great, highly differentiated user experiences should be the goal of every UX leader. But in many companies, UX leaders face challenges that force them to approach leading User Experience in a less than optimal way.”
This column is the second in our series that highlights our insights on what it would take for companies to go from producing dreary, overly complex user experiences to producing truly great user experiences that differentiate their products from those of competitors in their marketplace. In our first column, we stated that producing great, highly differentiated user experiences should be the goal of every UX leader. But in many companies, UX leaders face challenges that force them to approach leading User Experience in a less than optimal way. If, as a UX leader, you find yourself stuck in a situation where you and your team cannot do great work—that is, you are unable to produce user experiences that solve people’s problems, inspire, and delight—you’re working for the wrong organization and should find a better job. In that column, we also discussed how to position User Experience for optimal impact. UX Leadership, Part 1: The Nature of Great Leaders
“When creating early mobile designs, we should still start with the same simple sketching techniques that we’ve traditionally used for desktop designs.”
These days, it’s easy to design mobile user experiences using powerful tools such as Axure RP, Blueprint, or Protot.io. But when creating early mobile designs, we should still start with the same simple sketching techniques that we’ve traditionally used for desktop designs. Now, there are apps that let us get our sketches on real mobile devices for demos and usability testing. In this article, I’ll share some of my favorite tools for sketching mobile user experiences.
When I first started designing user experiences for mobile devices, there were almost no tools whose specific purpose was sketching hand-held user interfaces. Designers were creating six-ups and Photoshop and Illustrator templates for their own use, but since these belonged to individual designers or design agencies, few became resources for the larger UX community. Fortunately, the landscape has changed, and many tools and resources are now available for designers to sketch mobile user interfaces—working within the constraints of device screen sizes—then turn their sketches into interactive prototypes. Sketching Your Way to a Mobile UX Design
“In exploring potential means of integrating user experience into an organization’s product strategy and overall business strategy, our expert panel discusses such approaches as presumptive design and the Jobs to Be Done model.”
In this edition of Ask UXmatters, our panel of UX experts discusses two topics:
how to integrate user experience into an organization’s product and business strategy
how to best understand the culture of an organization for which you are providing design solutions
“The user experiences of enterprise applications do have direct impact on an organization’s performance. When the applications that an enterprise employs provide better user experiences and usability, its people are more efficient and productive.”
Organizations that have IT (Information Technology) departments should be more effective than organization that lack them. If your organization doesn’t use and maintain its software and servers efficiently and effectively, that’s money down the drain.
But, while it’s easy to see the direct impact that the user experience of a consumer application has on user conversions, that’s not true of user experiences for the enterprise segment of the software marketplace. Computer software that automates the business of non-software organizations is usually slow evolving. However, the user experiences of enterprise applications do have direct impact on an organization’s performance. When the applications that an enterprise employs provide better user experiences and usability, its people are more efficient and productive. The greater the cost of human resources within organization, the bigger that impact is. Task-Driven User Interfaces