Why the Lean Start-Up Changes Everything

First, rather than engaging in months of planning and research, entrepreneurs accept that all they have on day one is a series of untested hypotheses—basically, good guesses. So instead of writing an intricate business plan, founders summarize their hypotheses in a framework called a business model canvas. Essentially, this is a diagram of how a company creates value for itself and its customers. (See the exhibit “Sketch Out Your Hypotheses.”)

Second, lean start-ups use a “get out of the building” approach called customer development to test their hypotheses. They go out and ask potential users, purchasers, and partners for feedback on all elements of the business model, including product features, pricing, distribution channels, and affordable customer acquisition strategies. The emphasis is on nimbleness and speed: New ventures rapidly assemble minimum viable products and immediately elicit customer feedback. Then, using customers’ input to revise their assumptions, they start the cycle over again, testing redesigned offerings and making further small adjustments (iterations) or more substantive ones (pivots) to ideas that aren’t working. (See the exhibit “Listen to Customers.”)

Third, lean start-ups practice something called agile development, which originated in the software industry. Agile development works hand-in-hand with customer development. Unlike typical yearlong product development cycles that presuppose knowledge of customers’ problems and product needs, agile development eliminates wasted time and resources by developing the product iteratively and incrementally. It’s the process by which start-ups create the minimum viable products they test. (See the exhibit “Quick, Responsive Development.”)

lean-startup-business-model-components


source

The Power of Minimalism: A Story of Redesigning Yelp

Excellent article – highly recommended.

Design by committee is death by a thousand cuts.

It kills slowly, as more and more people weigh in with their opinions, until the “revised” design looks like a stew of lesser parts. It certainly doesn’t need to be that way, especially for large companies like Yelp.

We chose to redesign their site to show how usability testing done properly can unleash the power of just one. Based on our experience as designers at different companies, we found usability testing to be the best defense for design decisions.

When in doubt, let the user stand between you and overbearing stakeholders and the evidence will speak for itself.

redesigning-yelp-jc-repainted


source

What it takes to be a lead designer at a top startup

Build a Design Culture

Top startups are now also looking for their designers to help build a company culture that values design. This means producing a well designed product, helping other employees understand and respect design, and can even extend to designing the physical office space. To build this culture designers must:

Be Collaborative and Inclusive

Though going off to a private space and designing a perfect solution is romantic and sometimes necessary it rarely raises the design IQ of an organization. To do this designers need to find opportunities to be collaborative and inclusive where possible.

One great example is a design team that printed up their design mocks and gave out chocolate in return for feedback. This approach ended up getting them insights from unexpected places like finance and legal, and got many people in the company behind what they were building.

Be a design evangelist

Great designers at top startups also do a great job of evangelizing design to help people understand how to work with design and the impact it design can have. At Coursera, the Director of Design uses “All Hands” meetings to talk about product design and what the design team is working on to the entire company. This has helped increase company understanding of how design helps the business and has increased the number of people that seek to collaborate with design as a strategic partner.

Be a design educator

Finally great designers educate others on design. At Facebook, Mark would often walk over to me and ask me to adjust spacing, margins, color, etc. while I was designing. Instead of turning inward and getting frustrated I would use these opportunities to educate him on design and why I made specific decisions. The result has been that Mark’s design IQ is now extremely high and it’s because many designers used interactions with him as design education opportunities.

Treat Prototyping as Design

As more design moves to mobile devices designers must think along a time dimension. This means photoshop or sketch alone won’t produce the deliverables you need to communicate the work. In this new reality, prototyping is designing.

source

UX for the Enterprise

Enterprise UX is often about solving ancillary problems by creating tools that facilitate an organization’s primary goals. These problems are rarely as compelling or visible as the goals they support, but they’re just as necessary to solve. A company might build the best-designed cars in the world, but it won’t matter if its quality-assurance process is hobbled by unusable software. Good design enables enterprises to do the work they were founded to do.

Enterprise employees are also consumers, and they’ve come to expect consumer-level design in all the tools they use. Why shouldn’t a company’s inventory software or HR portal be as polished as Evernote, Pinterest, or Instagram? When a consumer app is poorly designed, the user can delete it. When an enterprise app is poorly designed, its users are stuck with it.

The stakes can be enormously high. The sheer scale of enterprise clients magnifies the effects of good and bad design alike. Small inefficiencies in large organizations result in extra costs that are passed on to the end user in time spent, money lost, and frustration increased. Likewise, when an enterprise prioritizes user experience for its internal tools, it becomes a more effective organization; a recently released business index shows that design-driven companies outperformed the S&P average by 228% over the last ten years.

DESIGN FOR THE END USER, NOT THE CLIENT

As with many design jobs, the end users of your software probably aren’t the same people who commissioned it.

In large organizations, the divide between the user and the client can be vast. The director of operations might commission an inventory app for warehouse personnel, or someone from IT might commission a reporting tool for the sales team. In an enterprise-scale bureaucracy, the clients in charge of UX projects are often in higher-level management roles. And while they typically have an invaluable grasp of the big picture, they may not completely realize the everyday needs of the people who will use the software.

A successful enterprise UX project considers the users’ needs, the clients’ goals, and the organization’s priorities. The best user experience sits at the intersection of these concerns.

source

How to give useful design feedback – for clients

DO point out and go into as much detail as possible as to why you feel something is not working. More than anything, your reasoning is critical to solving the problem.

DO tell us why we’re wrong about certain design and development decisions we’ve made. Part of the process is finding those holes.

DON’T mock up designs or alterations to our designs or code in photoshop, word, or any other program. Doing so is counter productive because we then must reverse engineer the whole thing to find out what you were trying to solve. This results in lost time, and budget.

source

Using Wireframes or Prototypes to Elicit, Analyze, and Validate Software Requirements

Within the business analysis community, the debate still reigns about whether how the application will look and how the screens will be laid out is technically part of requirements or design. This debate centers around the wrong question.

The right question is “When is the most effective time to introduce visual prototypes into your requirements process?”. My answer: As soon as it makes sense to do so.

Another good question to consider is “What requirements do a prototype or wireframe represent?” My answer: It depends. It depends on where you are at from a requirements process perspective (eliciting, validating, analyzing, or a bit of each), what types of requirements management practices you have in place, and what level of user interface expertise is available across members of the team.

source