Showing posts with label stakeholders. Show all posts
Showing posts with label stakeholders. Show all posts

Friday, October 10, 2014

Creating a Cultural Fit: Using ethnography with users and stakeholders

ARTICLE NO. 1323 OCTOBER 9, 2014


“The power of authoritative knowledge is not that it is correct but that it counts.”–Brigitte Jordan
They stride into the arena wearing the maize and blue. They are tall, strong, fast, and confident they will conquer the world. It wasn’t easy getting here, but after countless hours of practice, weight training, and gut-busting cardio workouts, they have arrived. The price is high. It costs thousands of dollars a year to play at this level, but without access to the best coaches, facilities, and technologies, you might as well just go home.
It’s six-thirty in the morning in January, and as I watch our fourteen year old daughter’s volleyball team make their way to the court, my feelings are mixed. I’m not happy about waking up at five o’clock on a Saturday to drive for an hour through the snow. A few years ago, I’d have laughed at this elite sports scene. Now I’m a part of it. Claire is staying fit, making friends, building self-confidence, learning teamwork.
Still, it’s over the top. Our club makes me uneasy. What bothers me most is the uniforms. They are beautiful. Since our club is run by the University of Michigan, our girls are decked out in blue and gold. While a lot of teams satisfice with cotton t-shirts, we have personalized, lightweight, wicking Nike jerseys with matching shorts, warm ups, and backpacks. As our girls prepare to play, I can’t help feeling we’re on the wrong side of the tracks. And sure enough, we are crushed by the t-shirt team, just like in the movies. Later, after a day of losses, I tell Claire not to worry, it’s the first tournament of a six-month season, the team will get better.
Of course, it was all downhill from there. Our coach was a hard-ass all season. One girl was berated for not hitting hard enough. Later it turned out her finger was broken. Claire was told she couldn’t take a break even though she felt sick. Soon after she was vomiting into a bucket. The girls were taught how to trick the referee. They were instructed to lie. The coach invited them to voice complaints. Claire did so and found herself benched. The parents weren’t any better. Our alpha mom reduced other moms to tears, taunted the opposing teams, and paid for weekly private lessons with the coach. This looked like pay-to-play corruption to us, but several of the parents said that’s simply how you play the game.
The next year we switched clubs. The new one was a little less expensive and a whole lot better. When the coach told the girls it was okay to miss practice for homework, since education is more important than volleyball, he actually meant it. When we lose a game, you won’t hear a word from our alpha mom. We don’t have one. The girls practice in an old warehouse, no windows, flickering lights. It’s nothing fancy. Neither are the uniforms. And that’s the way we like it. We found our fit.

Cultural Fit

In the 1990s, as co-owner and CEO of a consulting practice, I hired and managed several dozen employees. Mostly we got it right, but once in a while we hired someone who didn’t fit. The consequence of a cultural mismatch is often compared to an immune system response. It’s not a bad analogy. The first symptom is inflammation. This pain is followed by isolation of the foreign body. But in organizations, there’s no need to destroy the antigen. Few people endure outsider status for long. They quit. At the time I thought there was something wrong with those people. My enculturation was complete. Now I know it simply wasn’t a good fit.
As a consultant for two decades, I’ve been a tourist in all sorts of cultures. I’ve worked with startups, Fortune 500 companies, nonprofits, Ivy League colleges, and Federal Government agencies in multiple countries. My clients have included folks from marketing, support, human resources, engineering, and design. Being exposed to diverse ways of knowing and doing is one of the best parts of my work. But my interest runs deeper than cultural tourism. Over the years, I’ve realized that understanding culture is central to what I do.
First, as an information architect, I must understand the culture of users. When I run a “usability test,” evaluating the system is only half my aim. I also hope to uncover the beliefs, values, andbehaviors of the people who use the system. Before imposing my own theories, I want to see how they define their world. What can we learn from their use of language and the way they sort concepts into categories? Which sources of information and authority do they trust? What is the meaning behind their behavior? For years, I’ve used lightweight forms of design ethnography as part of my user research practice. It’s helped me to better understand and design for oncologists, middle school children, university faculty, bargain hunters, and network engineers. And, as the systems we design only grow more rooted in culture, I’m convinced we must dig deeper into ethnography.
Second, as an outside consultant, I must understand the culture of the organizations for which I work. Today’s systems aren’t only integral to the lives of users, but they are progressively part of the way we do business. To improve user experience, it may be necessary to change the org chart, metrics, incentives, processes, rules, and relationships. Connections and consequences run all the way from code to culture. Software that doesn’t work “the way we work” will fail like an employee who doesn’t fit. So we must also study and design for stakeholders. In my research, I always interview a mix of executives and employees about roles, responsibilities, vision, and goals. And I’ve learned that if I don’t ask the right questions in the right way, or if I don’t listen carefully and read between the lines, I may mistake the surface for substance and invent a design that won’t fit.
Bi-cultural fit
Figure 4-1. We must design for a bi-cultural fit.
In short, the right design is one that fits the company and its customers. A mismatch on either side results in fatal error. We must use ethnography with our users and stakeholders to search for a bi-cultural fit. This is tricky since culture is mostly invisible. That’s why we should start with a map.
The right design fits the company and its customers—a mismatch on either side results in fatal errortweet this

Mapping Culture

Edgar Schein, professor emeritus at MIT and the father of the study of corporate culture, offers a useful definition.
Culture is a pattern of shared tacit assumptions that was learned by a group as it solved its problems of external adaptation and internal integration, that has worked well enough to be considered valid and to be taught to new members as the correct way to perceive, think, and feel in relation to those problems.
Culture is a powerful, often unconscious set of forces that shape both our individual and collective behavior. In an organization, culture is reflected in “the way we do things here.” It influences goals, governance, strategy, planning, hiring, metrics, management, status, and rewards.
And culture is an artifact of history. Organizational culture is rooted in the values of the entrepreneur. In the early days, as leaders struggle to build the business, the beliefs and behaviors that lead to success are internalized. Eventually they become taken for granted, invisible, and non-negotiable.
At this point, it’s difficult to decipher the culture without a compass or map. Fortunately, Edgar Schein’s model offers the orientation we need. We can use his Three Levels of Culture to ask questions about any institution.
Three levels of culture
Figure 4-2. Three levels of culture.
First, what will a visitor see, hear, and feel? Artifacts include architecture, interior design and layout, technology, process, work style, social interactions, and meetings. Who’s the boss? How can you tell? Is there music? Are people talking? What do they wear? Where do they sit? When do they eat? What makes ‘em smile? Artifacts are easy to see but hard to decode. The art on the wall is visible but what does it mean? Why’s it there? Artifacts aren’t answers, but they raise good questions.
Second, what are the mission, vision, and values? How about goals, strategy, brand? Websites, annual reports, and those colorful posters so artfully framed in the lobby offer a place to start, but interviews with insiders are the only way to the truth. Espoused values are hard to miss yet often inconsistent with behavior, which is why we need “informants” to help us see what’s really going on. If teamwork is a core value, why are individuals so competitive? If the organization is user-centered, why doesn’t anyone talk to users? It’s vital to listen carefully as insiders may not know or be willing to tell the truth. Dissonance and its justifications serve as keys to the invisible culture. Entry is earned by paying attention.
Third, what are the tacit beliefs that are taken for granted and non-negotiable? Level three is all about history. What were the ways of the founders that led to success? Are they still valid or holding us back? When we fail to seize the future, it’s often because we’re blinded to the present by the radiance of our past success. Assumptions are the bedrock of culture. They are hidden and resistant to change. As organizations grow, technologies advance, and markets evolve, friction between old assumptions and new realities is inevitable, but people don’t question what they can’t see. This is where an advisor can help. Only insiders can effect cultural change, but it often takes an outsider to sketch the map.
Intertwingled



Read more about how everything from code to culture is connected in Peter Morville's new book Intertwingled: Information Changes Everything.In it, he connects the dots between authority, Buddhism, classification, synesthesia, quantum entaglement, and volleyball.

Monday, June 23, 2014

UIEtips: The Dirty Dozen Roadmap Roadblocks

via UIE Brain Sparks http://ift.tt/1lV3XSA

This article was originally published in Sept 2013 on Bruce’s blog, Product Powers. The original post also offers more in-depth information on the roadblocks.
A good product roadmap is one of the most important and influential documents an organization can develop, publish and continuously update. It’s the one document that steers the entire organization in delivering on the company strategy.
It’s key to success, and yet many organizations struggle to produce effective roadmaps. In fact, many organizations don’t create one, even to publish internally. Or they do, but it is simply a collection of unrelated features and dates.

What Is a Product Roadmap?

A roadmap is your vision for how a product (or product line) will help achieve your organization’s strategic goals. In that sense, it is literally a map of the steps involved in getting your business where you want it to go. To make it even more concrete, I also like to think of a product roadmap as a timeline view of your priorities.
A good roadmap inspires. It inspires buy-in from executives, inspires confidence from customers and salespeople, and inspires development teams to produce the groundbreaking products that drive significant growth.
A good roadmap keeps your organization on course toward its destination. Stating what you will do and when makes it easy to judge when you fall behind schedule or get detoured by good ideas that just don’t fit your strategic vision.

The Dirty Dozen

In my experience, though, there are some specific areas where companies commonly break down in developing roadmaps, hitting roadblocks that often keep them from getting where they want to go. I call these roadmap roadblocks the “Dirty Dozen.”

1. No Strategic Goals

If a roadmap is the path toward your goals, you obviously need to set those goals before you start. Yet many companies fail to sit down and explicitly describe the destination they are driving toward.
Is your product roadmap aligned with your strategic goals? Have a conversation with your CEO or another exec in the know. It may clarify a lot of your prioritization dilemmas.

2. Focusing on Features

A lot of roadmaps are just a list of features in upcoming releases. This is meaningless to most people outside of the development team. A roadmap should make it obvious how things will improve for your customers, organization or shareholders. Like any good sales pitch, it should focus on delivering value.
Look at your roadmap from the point of view of a board member or a customer. Would they see their interests reflected?

3. Inside-out Thinking

Focusing on features can be a symptom of failing to understand your market. Yes, priorities should be driven by internal goals, but those goals must also respond to market reality.
Ask yourself whether your roadmap priorities are driven by the needs of the people and organizations you intend to serve. Strive to bring that message from the outside in.

4. One Size Fits All

You probably serve more than one market segment. When you are talking to customers or partners in one segment, the roadmap you show should focus on how you will address their needs.
Make sure your roadmap is not one-size-fits-all. If a customer sees their interests in only 1 of the next 6 releases, they’ll get the message that you are not focused on them.

5. Trying Too Hard to Please

That said, many roadmaps are simply lists of customer requests prioritized by number (or size) of customers requesting or voting for the feature. This may help with retention for a while, but will not drive your company into new markets or to invent anything new.
Rather than just taking requests, listening for unsolved problems in your market (and doing something about them) is the best way to avoid a roadmap that’s really just a popularity contest.

6. Playing Catch-up

It’s often a mistake to focus on matching your competition feature-for-feature. All this does is commoditize your market. Instead, focus on creating unique value by developing solutions your competition can’t easily duplicate.
How many items on your roadmap are “me too” features designed to close perceived competitive gaps? How many of those have actually lost you business?

7. Not Getting Buy-in

The best-conceived roadmap won’t get you where you need to go if you can’t get anyone else to come along for the ride. You’ve got to get your development, sales, marketing, finance and other stakeholders involved early so it becomes their plan, not just yours.
If people use words like “intellectual,” “cerebral,” “theoretical,” or “ivory tower” to describe you or your work, this is code for lack of buy-in.

8. Prioritizing on Instinct

Good product people develop good instincts for their market. As a company grows, though, it’s hard to get the buy-in you need from all players based just on your instincts.
Can you tie everything on your roadmap back to your strategic goals? Can you show the ROI calculations that put priority 1 ahead of priority 2? A little data settles a lot of arguments.

9. Being Too Agile

Agile was developed as a response to lack of consistent direction from business execs. That doesn’t mean it’s incompatible with good direction. Yet many companies fear to map out a course thinking it’s not allowed in Agile.
Don’t let being agile become an excuse for indecision. You may choose to adjust course down the road, but you’ll move a lot faster if you first take your best guess at a destination.

10. Being Too Secretive

Some organizations have a roadmap but shy away from sharing it with anyone. It might be fear of revenue recognition issues, lack of confidence in the company’s direction, or just not wanting to look foolish if things change.
A good roadmap is not a contract. It can and should be designed as a statement of direction and intent, but customers and investors expect you to accept and act on feedback from the market. They expect your roadmap to change, so stop worrying.

11. No Buffer

One reason an organization might be reluctant to share is if their roadmap is too detailed. A roadmap consisting of 40 bulleted features in each of 10 precisely-dated releases is impossible to read, and can really constrain your options for adjusting course down the road.
Your roadmap should consist of problem-solving themes and broad time-frames. This gives you the leeway to cut or defer a specific feature without risking on-time arrival at your destination.

12. Over- or Underestimating

ROI is a critical consideration in prioritization, yet many product teams make the mistake of setting business priorities without considering development costs. Conversely, some teams spend months estimating every possible product initiative without first considering which are likely to be worth the time.
Approach your technical partner for a quick, high-level estimate of the work involved in your 10 most wanted. What if #4 turns out to be trivially easy compared to the 3 ahead of it? Wouldn’t you like to know that up front?

Want to hear more from Bruce?

He's presenting our next virtual seminar on June 26, Lean Roadmapping: Where Product Management & UX Meet.

Bruce McCarthyAbout the Author

Bruce McCarthy is a founder of three startups. He’s invested in helping product managers and UX designers work smarter. You can get a taste of his fun, teaching style at his blog, Product Powers. You can follow Bruce on Twitter @d8a_driven.

Wednesday, December 11, 2013

How to Create a Documented Content Marketing Strategy: 36 Questions

via Content Marketing Institute http://contentmarketinginstitute.com/2013/11/documented-content-marketing-strategy-benefits-brand/

By MICHELE LINN published NOVEMBER 15, 2013
In this year’s content marketing research, one new question we asked was whether organizations were creating more or less content, compared to a year ago — and the majority of marketers are doing just that. Does that sound intimidating? Do you feel this is a positive trend, or one that just creates greater challenges?
This debate leads off our second roundtable discussion on the results of our B2C content marketing study. But, hold tight — what we learned holds lessons for anyone who is using content marketing, including those who work in B2B and nonprofit industries. 
Watch as our participants Andrew Davis (author of Brandscaping), Julie Fleischer (Kraft Foods), David Germano (Empower MediaMarketing), Buddy Scalera (Ogilvy CommonHealth Worldwide), Michael Weiss (Content Marketing Institute/figure18), and Karen Budell (Imagination Publishing) discuss the trend of increased content creation in the video below:
Andrew Davis summarized the call to action from the discussion nicely:
“My hope is that we start focusing on less content, bigger success, and higher quality content over just high quantity.”
But how exactly should you do this? You need a documented content marketing strategy in order to be successful. As we’ve seen in the responses to our annual survey, those with a documented content marketing strategy:
  • Are far more likely to consider themselves effective at content marketing
  • Feel significantly less challenged with every aspect of content marketing
  • Generally are more likely to consider themselves more effective in their use of all content marketing tactics and social media channels
  • Were able to justify spending a higher percentage of their marketing budget on content marketing
Of course, this leads to questions that we, at Content Marketing Institute, receive frequently:What exactly is a documented content marketing strategy, and what does it consist of?
In short, to develop a documented content marketing strategy, you’ll need to work through the following key activities:
  • Get buy-in for an innovative process such as content marketing
  • Make the case to your key stakeholders
  • Develop buyer personas
  • Map your content
  • Create your brand story
  • Develop your channel plan
Because each organization has unique opportunities, resources and challenges, no “template” exists for building a content marketing strategy. However, there is a set of questions that you can use to help guide you through the process.
Similarly, there is no singular “right way” to document your content marketing strategy. For instance, we have seen that both small businesses and those with simpler content marketing plans have found it adequate to work through the key questions, without much need for explicit documentation. For larger organizations, or more complex initiatives in which there are more stakeholders, documenting everything may make more sense.
To help you determine what documentation processes will be most effective for your organization’s content marketing strategy, our newest 16-page guide, The Essentials of a Content Marketing Strategy: 36 Questions to Answer, explains the basics.

Wednesday, November 20, 2013

UIEtips: LiRPPS – Lightweight, Research-Based Principles, Personas, and Scenarios – Part 2

“Create useful personas in a day? That’s crazy talk!”
They were right. It is crazy talk. Why would we spend an entire day on creating personas when we can do it in three hours, max?
If you read Part 1 of this article, then you saw the preparation needed to create the critical design reference tools of principles, personas, and scenarios. We can do this in a single day because we’re feeding right off the field research we just completed. By involving the entire team in the research and the creation of these design reference tools, everyone ends up on the same page with minimal effort.

Final Preparation: Gathering Supplies in the Room

It’s a well-known fact that design doesn’t happen unless colored sticky notes are involved. This process is no exception. We grab a bunch, in all different sizes. (Those big 4x6 pads are particularly useful, along with the little colored flags.)
We’ll also want one flip chart pad for every three people on the team and a set of markers to use with these.
Those little colored circle stickers are also handy (We can use flag-size or small-size colored sticky notes when we don’t have the stickers available).
A big room where we can stick things to the wall works best. We’ll want to post both the sticky notes, printouts from the research, and the flip chart pages during the day.
Finally, remember those write-ups our team did of all the people they saw on the visits? We want a copy or two of each of those. It’s helpful if each page has a decent size picture of the participant they met, along with their name and the site where the team met them.

Who Participates? Getting the Teams Ready

We use a simple rule to decide who gets a say in creating our personas, scenarios, and principles: only people who went on a minimum of two field visits. This way everyone is basing their decisions on research. If we let folks who haven’t been on visits participate, then they’ll draw from their own experiences or people we hadn’t talked to in this round of research. That reduces the chance we’ll get personas that match our audience, which, in turn, makes the reference tools less valuable.
Making this rule from the start of the project means everyone understands the price of entry. Want to help make the personas, scenarios, and design principles? Then you need to visit at least two sites and take notes.
If you haven’t figured it out, this is the secret part of our agenda. There’s lots of evidence to show the more exposure team members have to real users doing real work, the better the design. The reference tools we’re creating help us stretch the effects of that exposure, so without it, those tools are useless. (Read more about increasing exposure hours.)
On our team, we want to involve designers, developers, stakeholders, and other influencers of what our final design will be. It’s not unusual to have as many as 12 or 15 folks participating in creating our reference tools.
With this many people, we break into smaller project teams of three to five people. Each team gets one of the priorities from Part 1’s Prioritized Action List. They’ll use that priority as their project for the creation of their own personas, scenarios, and principles.
We can create the teams randomly, let them self organize, or be deliberate (such as ensuring there’s one designer on each team). When you’re dealing with smart folks, I’ve found it doesn’t matter too much who is on which team. It always works out.
A recent client focused on updating their HR software that helps managers do their performance reviews. After visiting 14 companies and interviewing 22 managers and HR representatives, we came together to make our personas, scenarios, and design principles. We prioritized the most important actions to update the software, and assigned one to each project team. Now we were ready.

Activity 1: Identify the Personas — 3 Hours

Even though we call the process LiRPPS, for Lightweight Research-Based Principles, Personas, and Scenarios, we tend to create the personas first and the principles last. Everything works well when you define the personas first (including scheduling a mid-day lunch break — we keep our priorities straight). Unfortunately, LiRPPS isn’t as easy to pronounce.
The first step to creating our personas is to pick out the research participants we want to consider. Each team selects their own participants, looking through the lens of their newly assigned project.
Our team’s priority was helping managers with regularly collecting performance information all year long. We observed many managers struggle to track what their employees have done throughout the year. Their annual performance reviews become heavily biased to the few weeks before they sit down to write it. It’s not fair to employees who work hard all year long.
As we reviewed the participants visited during the field research, we looked for managers who struggled with this problem of tracking a year’s worth of employee information. We knew we wanted to build a tool to help with this, but we needed to understand which users would benefit most.
We used the colored dots to vote on which participants would be most critical to our project. We ranked them in order of votes, most to least.
Choosing and ranking the most relevant participants took us about half an hour. The other two project teams did the same for their priorities.

Pulling Out Persona Attributes

Next, we wanted to create a list of attributes that we’ll consider for our personas. The attributes are what make the participants different from each other.
Some of our managers worked for large, multinational companies. Some worked inside of an organization with fewer than 200 employees.
So, organizational size is an attribute we put on the flip chart. Same with whether the HR department had rigorous procedures or not. And whether the institution recommended quarterly or half-year reviews.
We also looked at differences because of team organization. Some managers had large teams, others had small ones. Some had teams where everyone did similar work (like a call center) and others had teams where everyone did something different (like a multi-disciplinary design and production team).
My team was also interested in how the manager seemed to work. Some were excellent at having regular one-on-ones with all of their direct reports, while others never had them. Some were very poor at taking notes, while others were rigorous about it. All these differences went on the flip chart.
Again, we’d seen all these things in the recently conducted research. If we didn’t see it, it didn’t go into our attribute list.
The simplest way to collect these differences was to take the top two participants out of our pile and put them side-by-side. We then asked what was different between them. We’d put the differences on the flip chart, then replaced one of the participants with the next one in the pile. We repeated until we weren’t finding anything new. The process to identifying attributes took about an hour.

Scaling the Attributes

Next, we took the list of attributes we just created and voted, using those colored dots, on the ones we thought most affect our new tool for collecting performance review data year round.
Using 4x6 sticky notes, we wrote each of the top attributes in the middle in large print. Then, we figured out the scale for the attribute and wrote the endpoints on each side.
One of our attributes was Manager’s Note-Taking Rigor. On one side of the sticky note we wrote “Takes thorough notes” and on the other side we wrote “Takes poor notes.”
Another attribute was Team Role Differences. On one side we wrote “Very similar” thinking of our call center folks, with the opposing side labeled “All different” for the production team we visited.
We stuck our sheets of attributes on the wall, going from most important (based on our earlier votes), to least. (I usually don’t bother with any attributes that didn’t garner any votes at all.)

Crafting Our Personas

Given a list of attributes, based on real people we observed, we could now assemble the most interesting ones to form our personas. Those personas will become the basis of future design decisions, so getting them right was worth the effort. Our goal was to have three to five personas to work with.
Using a different color for each possible persona, we grabbed small sticky notes or flags. Someone on the team would suggest a set of attributes, putting the sticky note on the side of the scale that they thought made for an interesting persona.
One person we were interested in was a first-time manager in a large organization where HR wasn’t very supportive. This manager may have a large team of people with similar roles.
One of our team members put a purple sticky flag on the Org. Size attribute near the “Large” side of the scale, on the HR Support attribute near “Not very,” on the Manager Experience attribute near “Newbie,” and on the Team Role Differences attribute near “Very similar.” Everyone nodded in approval. “That’s just like Roger at Acme,” one team member suggested.
We came up for a name for each color, like First-time Freddy and Experienced Manager Evelyn. The colored stickies helped us see if we were biasing our personas on certain attributes. The goal was to have a nice distribution of stickies on each of the important attribute’s scales.
Documenting each of our personas became simple. A simple write up, using mildly disguised descriptions of what we saw in the research, delivered us four solid personas. For each persona, we could tie it to real organizations and managers we met.
We took the last half hour of our morning to share our personas with the other teams. One at a time, each team shared their personas, reviewing the top attributes for their particular project. It was fascinating to see the overlap, and the differences gave us interesting perspectives on our own personas.

Activity 2: Writing the Scenarios — 1.5 Hours

Writing the scenarios is the easiest part of the LiRPPS process. It’s rarely more effort than going through our research notes and documenting stories of what we actually saw.
For each persona, we wrote up two or three scenarios. These are stories that describe what that persona would try to do with our project. They set up the context, describe the persona’s flow, and outline what successful completion looks like.
For one of our personas, First-Time Freddy, we described the following scenario:
A few weeks after Freddy started as the manager of this group, he learned in his manager’s staff meeting that the company plans to open a second call center on the other side of the company. They’ll need trainers and Freddy wants to track who his smartest reps are, so he can be ready to suggest an elite training team.
He needs to identify the criteria that makes someone a good trainer and track the people on his team who are excelling in that criteria. He’d like to do this every couple of weeks, so he’s ready with the data when the time comes.
This scenario was easy to write up, because we’d seen a real world instance of it. It came directly from real life.
Again, we took time at the end of the activity to compare our scenarios with those of the other teams. As often happens, they had striking similarities to what we’d written up, but were bent slightly to fit their own projects.

Activity 3: Designing the Design Principles — 2.5 Hours

In the last activity of the day, we created our design principles. These are specific rules of thumb to help guide design decisions. The idea is, when the team faces a hard decision between two choices, they can choose the one that’s closest to the principle. This can also help push the team to try harder in a certain dimension, to move past a design that’s just OK to one that’s great.
Our goal was to come up with four design principles specific to our project of creating a tool for regularly collecting employee performance data. We started with a simple trick: how would we make the crappiest version of this tool?
For a few minutes, we brainstormed all the ways to create a version of our tool that would be awful to use. We started with the obvious things: It would be hard to understand the instructions. It would be really slow. It would only work on an out-of-date piece of hardware, like an Apple Newton.
After that first burst, the team fell into silence. Had we covered it? Apparently not, because suddenly, out came some real interesting ideas: It wouldn’t let you save, so you had to complete it all at once. It wouldn’t let you jump around from employee to employee, instead you had to go through the entire team. (For Freddy and his 18 direct reports, that would be hellish.)
Over time, we came up with about 20 different things that would make whatever tool we came up with really suck to use. And it was from the fires of Hell we’d created that our understanding of what was really important emerged.
We next revisited the list of crappy features and came up with attributes for each one. A slow design meant performance was an important attribute. And not letting the user save meant interruptible was also an important attribute. We ended up with about 25 attributes.
Again, using our dots, we voted on the attributes we thought were most important. From here, we started to explore the top voted candidates. Which ones would push us to excel?

Principles as Tradeoffs

For each of the top attributes, we asked two questions, “What would push us beyond what we deliver today?” and “What pushes us into today’s bad habits?” Our goal was to come up with principles that break us of what we normally do to something better than what we’ve been doing. Using the answers to these two questions, we formed principles that we stated as tradeoff statements.
To let a manager save their work without finishing, we’d need to stop requiring that all database updates be completed transactions. Allowing for partial transactions was something the back-end couldn’t handle today, but it could be changed. From this, the design principle We’ll prefer completion across sessions over insisting on complete transactions emerged.
We chose four principles from our list of attributes. When we were done, we had a solid understanding on how our new design would push beyond what we’d been delivering in the past.
When we compared our four principles with what the other teams came up with, we were again struck by the similarities. One principle appeared on every list, even though the teams had never discussed it with each other. A couple others appeared on more than a single list. It was clear that the research had influenced a new philosophy towards design.

LiRPPS Done. Now What?

After 7 hours, we’d created four personas, ten scenarios, and four design principles for our project. The two other teams also had created a similar number in the same period. That’s quite an accomplishment.
What was even more exciting was how the team was energized to start designing. They felt they had a solid idea of who their users were, what those users needed, and how they would produce better designs than ever before.
The next day, we launched a two-day design studio for our projects. Each team used the principles, personas, and scenarios they’d created to guide the studio. By the end of it, they’d created solid design ideas that propelled the team into the fastest design and development cycle they’d ever seen.
Creating Lightweight Research-Based Principles, Personas, and Scenarios (LiRPPS) is a solid technique for putting users at the center of the design process.

Jared M. SpoolAbout the Author

Jared M. Spool is the founder of User Interface Engineering. He spends his time working with the research teams at the company and helps clients understand how to solve their design problems.
via UIE Brain Sparks http://www.uie.com/brainsparks/2013/11/14/uietips-lirpps_part2/