design

Escaping the Manager-Hero Trap: How to Help Your Team Design Their Own Solutions

When Alice stomped into my office, I knew something was wrong.

“I can’t take it any more,” she fumed as she told me about the latest offense from Charles, the coworker who always “forgot” to include her in critical meetings. I could feel my blood pressure rising. He did what? He said what? No way, not to MY teammate! 

60 seconds later, I was on the phone with his manager, demanding that he give some harsh feedback to Charles.

“I could do that,” said the manager. “But wouldn’t that make Alice look like a tattletale?”

I flushed with embarrassment. In my haste to play the hero, I had almost made the situation worse.

The problem with trying to solve other people’s problems

Be honest with yourself. How many times have you tried to take ownership of someone else’s problem? Maybe it was that time you yelled at your friend’s ex for cheating on her, or the time you called your child’s math teacher to get that B+ changed to an A-.

In a leadership position, it can be even more tempting to take on your teammate’s problems. You may believe that you will be able to solve it more quickly and effectively because you have greater power, status, or experience. However, when you try to solve your teammate’s problem for her, this is what happens:

  1. You aren’t fixing the problem; you’re deferring it. Most problems have underlying causes that run so deep that they can’t be solved in one go, especially by a third party.
  2. You’re making yourself a bottleneck for problem-solving. Your teammate will start to feel like any time she has a problem, she needs to rely on you to solve it.
  3. You’re implicitly telling your teammate you don’t trust her. Now she’s not only worried about solving her first problem; she’s also worried about how to earn back your trust and respect.
  4. You’re probably making things worse. You risk making it seem like your teammate is incapable of solving her own problems. 

Help people design their own solutions

If I really wanted to help my teammate, I had to ditch the superhero cape and become an advisor and collaborator. I apologized to my teammate and suggested that we work together to address the problem.

The next time she walked into my office, it was with a big smile on her face. She’d had a productive conversation with her teammate and was already seeing improvements! 

I learned a valuable lesson that day: Being a leader isn’t about solving people’s problems for them; it’s about helping them design their own solutions.

Design process for problem solving

Many of the tools and techniques we traditionally use for solving design problems can be repurposed for “people” problems. Here’s the process I use to help teammates design their own solutions:

  1. Acknowledge the problem. Many people struggle with asking for help because it requires them to acknowledge their weaknesses and failures. When your teammate raises a problem, thank her for trusting you enough to share and let her know you’re there to help.
  2. Clarify the situation. Put on your Researcher hat and ask open ended questions about the situation. Use the “5 whys” to identify the root cause. It may be useful to capture your insights on a whiteboard; for example, drawing a quick stakeholder map can help you quickly identify breakdowns and opportunities.
  3. Brainstorm approaches to problem solving. Pull out your post-it notes and work together to brainstorm different possible solutions to the problems you’ve identified. Push for quantity of ideas over quality; ideas that seem silly at first glance may in fact have some merit.
  4. Narrow to the top ideas. Encourage your teammate to decide which ideas to try first. If she’s struggling to prioritize, suggest that she order them by risk, effort, or potential for success. If she seems to be picking ideas that you don’t agree with, ask her to explain her rationale before providing your own input.
  5. Execute the plan. Check in with your teammate and hold her accountable to the plan. If she seems to be putting it off, ask why and help her adjust accordingly. Also hold yourself accountable and report back about any actions you took on her behalf.
  6. Reflect on the outcomes. Ask your teammate what happened when she put the plan into action and how she feels about the outcomes. Celebrate her successes, help her unpack problems, and encourage her to reflect on her learning and growth.
  7. Iterate. A designer’s work is rarely done. If the problem hasn’t been resolved or new problems have emerged, return to Step 1 and repeat.

A few exceptions

Here are a few exceptions that may require a different approach:

HR Violations
Problems related to harassment, bullying, criminal activity, or other HR violations need to be dealt with immediately and professionally. Your organization likely has clear policies related to this. If in doubt, speak to your HR representative.

They aren’t ready to problem-solve
If your teammate comes to you in such an emotional state that he is not yet ready to move into “problem-solving” mode, that’s ok. Create a safe, non-judgmental space for him by using active listening. If you aren’t sure whether he’s ready to problem solve, ask, “How can I help?” Let him take the lead on whether to tackle the problem immediately or whether he’d prefer to go for a walk and cool down a bit first.

The problem just won’t go away
If your teammate keeps bringing up the same problem and doesn’t seem to be making any progress, it may be time to ramp up your involvement. Are there big cultural problems that need to be resolved? Is there something that could be solved through smarter staffing? Listen for trends in feedback from other employees and departments. You may discover deeper problems that should be addressed by yourself or others.

Conclusion

As a manager, it’s tempting to think of yourself as a hero. But if you really want to save the day, help your teammates design their own solutions and become their own heroes.

“

Design for Delight is grounded in deep customer empathy, going broad with ideas then narrowing with possible solutions and finally, rapid experimentation with customers.



These principles were integral in a product we recently launched called Snap Payroll, a free, mobile application that allows small businesses on the go to calculate paychecks in minutes and determine how much to set aside for taxes.

”
— Intuit CEO Brad Smith in Forbes talking about Snap Payroll

Five Lessons for Creating Great Tablet Experiences (part 1)

Part 1 of my notes from a BayCHI talk given by Brennan Browne, a UX researcher at AnswerLab.

Trend 1 - Trading computer time for tablet time

  • Why? It’s more fun, easy, convenient.
  • Computer: in the home office vs. Tablet: comes everywhere
  • Tablets are portable, not necessarily mobile - possibly because need wifi (not all are 3G enabled)
  • Over past 6 months, see trend of more people using tablet at work - more employers are handing them out, there are more biz-related apps available
  • People are afraid of taking iPad outside of home, Starbucks, work, or other places where they feel safe (i.e. not public transit) because they fear theft
  • Choice of device to use isn’t based on where user is– it’s about what user wants to do. 
  • Phone: quickly checking something
  • Tablet: immersive - plan to sit down with for a longer period of time
  • Computer: for tasks that require more management/multitasking/typing
  • People prefer typing on everything (i.e. phone, computer) except a tablet
  • Did see people using bluetooth keyboards primarily if they’re trying to replace their computer with an iPad (although would still often have to turn back to a computer for other reasons)
  • Whichever device is most convenient at the time will often be the one they choose to use. For example, they might pull their phone out of their pocket while on the couch, rather than getting up to grab a computer from another room.

Trend 2: The tablet and shared experiences

  • Tablet is commonly shared amongst family members
  • In the past 3 months more common to have multiple iPads within a house– “I got tired to sharing it so I got everyone in my house one”– much like what happened when computers were growing in popularity
  • Shared nature can lead to some problems because no built in multiuser support in iPad & very limited in Android. Puts the responsibility for multi-account support on the app developer
  • Facebook tries to support this (to view this, sign out of the FB iPad app and see ability to create other accounts)

Trend 3: Apps vs Web

  • Many users are content to use the web on iPad - they expect to be able to access the full version of the website and to have the same level of functionality that they would have from the computer
  • Example of a bad app: Target (users felt they were being forced to leave the app to view product details on the website which broke their experience - “what’s the point of even using the app?”)
  • Example of a good app: Zappos (users get full functionality of the website, plus ability to interact with pictures, better shopping cart experience, etc.)
  • Best Practice: give lightweight help to users during their first use experience, then make help content available (but not in their face) going forward
  • Best Practice: use universal app instead of having a separate iPhone/iPad app if possible or users might not realize that you have a different version of the app in the App Store
  • Best Practice: website interrupts that alert you that an app is available is fine unless it impedes the web experience (ex: people were frustrated by Yelp which asks them to download the app each time they visit the website). Using a banner or sending an email may be even more preferable.
  • People generally update their apps within a month
  • See lots of people syncing their iPads to computer, but it’s not as common as syncing their smartphone
  • Did observe some users saving websites to their home screens, but these were generally more tech-savvy users or those who didn’t care for apps
  • Saw a mix of people who did/didn’t want push notifications. Best Practice: don’t ask users whether they want to accept push notifications until they’ve spent some time within the app and have an idea of how/why notifications might be useful to them

Overall Design Recommendations

1. Design for a “small laptop”, not a “big phone”

  • Create fast, intuitive, full featured experiences that are fun to use and better than the web

2. Full web

  • People expect a full website when browsing on the iPad browser, so ensure your site is optimized to deliver a great experience. 
  • Ex: use HTML5 to customize the keyboard when typing in a datafield

3. Content over context

  • Location-specific experiences that are king on smartphones may not be as important on tablets because they aren’t necessarily being brought everywhere
  • Instead, focus on rich content and superb UI (especially taking advantage of video & photo)

4. Shared device

  • Consider social nature of the device when design log in components, how data is stored, and anything involving transactions/ecommerce
  • Ex: Amazon app allows users to view recommendations/watch list without signing in, but user is prompted for password when making a purchase

5. Security fears

  • People have no clue about security on a tablet. In all of their testing, they’ve never seen someone who’s set up a passcode on the iPad. The people who are the most tech savvy are the least afraid of security risks… but non-savvy users are more afraid about persistent log in and entering credit card info and will sometimes go back to a computer when they’re required to input credit card credentials
  • Tip: reassure users that the privacy/security of your app/website on the iPad are the same as what they’ll find on the computer

In part 2 of this post, I’ll summarize Brennan’s recommendations regarding smartphone/tablet usability testing.

Eric Ries: Lean Startup + Big Biz

Notes from Eric Ries’ talk about applying Lean Startup to a large software company at the Intuit Delight Forum.

“There are 3 acts to every story, and entrepreneurship is mostly in phase 2, the boring part” – Eric Ries

Entrepreneurs are everywhere

  • They aren’t just “the guy eating ramen in the garage”
  • Definition of a startup: “A human institution designed to create something new under conditions of extreme uncertainty”
  • Nothing to do with size of company, sector of economy, or industry; it’s about running experiments

Uncertainty 

  • If you’re building something new you are naturally in extreme uncertainty because you don’t know the users or behavior
  • Since nowadays we can build everything, the question isn’t “can it be built” but “should it be built”
  • Today lots of companies waste people’s time– no one takes ownership for it
  • Who’s to blame? Fred Taylor, the father of “Scientific management” - study work, find the best way, manage by exception, standardize work into tasks, compensate based on performance, “the system will be first”
  • What we need is “Entrepreneurial management”, where we can pivot (change direction but stay grounded in what we’ve learned)

Speed wins

  • If we can reduce the time between pivots, we can increase odds if success before we run out of money
  • Minimize total time through the loop - ideas, build, code, measure, data, learn - by avoiding “achieving failure” (successfully executing on a bad plan)

Innovation Accounting - 3 Learning Milestones

  • Establish the baseline -  build a MVP and measure how customers behave right now
  • Tune the engine - experiment to see if we can improve metrics from the baseline towards the ideal
  • Pivot or persevere - when experiments reach diminishing returns, it’s time to pivot

Coaching

Eric held a “live coaching” session in which he provided feedback and advice for teams regarding real projects that they were working on. Top takeaways:

  • Don’t worry about the competition and what they know about you. It’s all about you moving faster than the competition.
  • Regarding competitors stealing ideas that you’re just testing: “Try to get someone else at another company to steal one of your ideas and notice that it’s really hard to do that” - observed that many competing companies have similar backlogs of features but it can be equally hard for both to actually get them into a product. In the end, it’s all about how gets there first.
  • Worried about potentially damaging your company’s brand? Try releasing under a different brand name.
  • You can test different types of application positioning by using different words or images on your marketing pages.
  • Regarding sustainable growth: New customers come from the actions of past customers. Engines of growth: Paid, Viral, and Stickiness/Engagement. Growth needs to be engineered, so choose one to focus on and do everything you can to help drive that up. Can use “lifetime value” as a framework for thinking through this
  • Consider the distribution channel you will use to get to your customers
  • Get into a rhythm/cycle where every 6 weeks, you meet to decide whether you’re on track or need to pivot. Have a clear understanding of the evidence you’ll need at that meeting to make that decision.
  • Remember: pivot is changing the strategy without changing the vision

Wrap up

Myth: Lean means “cheap and saving money”
Truth: It’s not about cost, it’s about speed

Myth: Companies are “lean” if they are small bootstrapped startups
Truth: Companies are “lean” if they are ambitious and are able to deploy resources in a good way

Myth: Lean startups replace vision with data or customer feedback
Truth: They are driven by a compelling vision, and are rigorous about testing each element of this vision.“ You don’t turn on your GPS and ask it where you should go. Data helps you get there, it doesn’t tell you where you should go.”

Q&A

A few final thoughts from Eric that emerged during the Q&A section.

A message to big companies: “There are startups gunning for you right now. It’s not like size is everything.” At big companies, people know what needs to be done but are afraid to do it. Hopefully this is an invitation for people to actually do this.

Regarding whether Lean methods of testing represent loss of integrity: Integrity means being clear and honest with the customer and apologizing when you do something wrong. “We are already doing the wrong thing. Our customers dont know how to use our products, so our customers are constantly experiencing us as a bait and switch.”

Early adopters would rather have things in an unfinished state and being the first to try it. If you are spending too long perfecting it, customers will get mad because they can’t use it yet.

Regarding legacy code: Being first means that people will be gunning at you, but whoever moves faster will win. Legacy code means that everything we’ve learned is embedded in the code. If you have a choice, invest in new features, in cleanup, or in things that help you move faster in general. Refactoring tools can help you to move more quickly so they’re a good investment. But if you pivot because your use cases change, refactoring is better than starting over.

Teams need good measuring tools. "Metrics are people too.“ Best method is usually a homegrown way to see important data for a product, such as 5 key metrics pulled straight from the master database.

"Most visions can’t be recognized. As a startup, think that you’re the exception and systematically try every idea about getting there.”

Regarding selling through channels: Ask “am I creating value for the end user? What is lifetime value of the customer?" It might make sense to use the channel, but for testing you might first want to try selling direct and learn, then start applying that learning when you get building with the channels.

“And how do you resonate with your customers at an emotional level without excessive human interaction? You design it in. If you create a positive relationship between the product and the end user, you don’t have the expense of someone needing to explain, “Here’s why this is important, this is how you use it, and this is why it matters to you.””
— Bruner & Emery, “Do you matter?”

The problem with mobile app "Pretenders"

So true:

The iPhone browser already has a back button

This is a great explanation of why mobile web apps shouldn’t simply try to emulate a native app:

Users of pretender apps get an experience that falls squarely in the uncanny valley — it looks like a native app, but something isn’t quite right. Perhaps it doesn’t respond as expected or it doesn’t quite follow the conventions of a native app. Often pretender apps have both of these problems and then some. They simply don’t feel “at home”.

Another problem which we’ve heard in usability: non-iPhone users are put-off when they encounter mobile websites that “look too much like an iPhone”. There are interaction problems: should the Android user tap the glossy button or the hard back button to move to the previous page? There are also visual design problems: when a page screams “designed for iPhone,” non-iPhone users feel like they’re being treated as second-class citizens. Not good, considering that many users consider their choice of phone to be a mode of self-expression.

Recommendation: Focus less on “I’ve fooled them all into thinking this is native!” and more on “This is a great user experience.” A few tips:

  • Keep it clean & quick to load (consider your use of images, animations, etc.)
  • Streamline key workflows: keep in mind that each time the user navigates to another page, they run the risk of encountering slow load times
  • Optimize layout & visual elements to be appropriate for a small screen size (look to native apps for best practices about font size, line height, tap area, etc.)
  • By default redirect users to the mobile-optimized version of your site, but include a link to the full version of the website

EightShapes Unify Documentation System

Templates and snippets for design documentation, wireframes, and more within Adobe InDesign. The website is well documented and has several video tutorials. If you prefer to jump in, download the pack and open “documentation/IASummit2008.InstantDeliverableMix.NathanCurtis.pdf” for an overview of available templates.

Once I’d familiarized myself with the system, I was able to set up a decent looking design review document in just a few clicks. Since this is using InDesign, this enables a separation between the presentation layer and actual files. The EightShapes Unify blog has a few articles about sourcing library artwork.

Hint: If you’re new to InDesign, note the differences between templates (.indt) and snippets (.inds). You can open a template directly in InDesign, but in order to add a snippet, you must add it to an existing document.

Bottle Label Inspiration

Q: What’s great about brewing your own beer?
A: You get to design a label for it. 

Q: What’s great about designing a beer label?
A: It’s an excuse to visit The Dieline for some inspiration! (Somehow a quick trip here always turns into hours of happy browsing…)

A sampling:

Enjoy! I’ll post pictures if I ever stop reading The Dieline long enough to design my own label.

A Study of Trends in Mobile Design

An excerpt from a Smashing Magazine book about mobile design. Topics are a mix of technical (TLD usage, code validation, load time), visual design (typography, contrast), and interaction design (navigation, link click region, scrolling). Worth reading to get a quick snapshot of mobile design patterns as they exist today.