Chances are you've come in contact with a piece of flat-pack furniture from Ikea. You may even have put a shelf or desk together with the help of an allen wrench and a single-sheet instruction manual. Ikea has successfully innovated in pricing, logistics, packaging, and store layout to become a global phenomenon.
But the lesson we, the UX community, can learn from Ikea isn't directly related to their low prices, or making customers put products together themselves. Rather, the valuable lesson we can take from the self-assembly giant comes from an earlier point in a product's lifecycle: the design stage.
When it comes to design, Ikea is a price-first company. Sure, they pride themselves of their Scandinavian design and ingenuity, but above all else they want their products to be as affordable as possible. As a result, the target price for a product defines and constrains the product design, rather than the other way around. Instead of specifying a product and then determining how much it will cost, Ikea decides how much a product should cost and then designs it to fit within the cost constraint. In an interview with CNET, Ikea product developer June Deboehmler said, "When we decide about a product, we always start with the price... Then, what is the consumer need?"
To some this may seem like a counter-intuitive approach. But in actuality, creativity loves constraints. It may seem that a cost constraint would be burdensome to designers but in fact it helps focus and guide their work. Even if cost isn%u2019t the leading constraint (as it is with Ikea), it%u2019s always a critical constraint that should be factored into design.
But in the world of software and UX design, you seldom see projects where cost is treated as a primary, initial constraint. Instead, cost is treated as something that%u2019s derived from scope. Foundational problems with scope, budgets, and constraints are a setup for failed projects and poor UX. But how can we all learn from Ikea in a way that makes sense to industry? We have defined four lessons that will guarantee smoother projects before they even start.
1. Cost is a primary constraint
After they%u2019ve outlined a product%u2019s scope, most companies already have a strong sense of what they think the product should cost, or at the very least how much they can afford. But, in the majority of cases, rather than communicating both the scope and cost expectations to their vendor or internal development team, they withhold the cost information. This forces the development team to go through a complicated, error-prone process of trying to extrapolate a cost estimate from the scope. This is followed by a back-and-forth of discussion until the estimate comes into alignment with the original cost expectation. The cost expectation (or limit) was known all along but everyone has to participate in a ritual dance before it%u2019s disclosed.
In most other settings, this practice would be considered dysfunctional, and an example of how poor trust and communication wastes time and money. But, oddly, it%u2019s standard practice in software and Web development. If the cost expectation is fixed and present from the beginning%u2014in other words, it is a primary constraint%u2014why not simply let the development team know about it? Constraints give the team better understanding of what will be possible, reduces errors in their projections, and gets them working sooner.
Companies are generally wary of sharing their budget numbers upfront for fear of having the development team take advantage of their trust. Their concern is that the development team will charge the full amount in the budget even though the scope of the project should actually cost something less. But, in actual practice, this can't happen because the scope is never smaller than the budget. For innovative, UX-focused product and website development efforts, the project's requirements will always grow as large as the budget will allow%u2014again, cost is the project's primary constraint. The entire course of a project always entails an ongoing negotiation between the stakeholders and the development team about how much work can reasonably be accomplished, and how many requirements can reasonably be fulfilled, before the budget runs out. This is true whether or not the budget is initially disclosed, and whether the project is charged fixed-bid or hourly, because of the weaknesses of upfront planning and the ambiguity inherent to scoping documentation. If the development team is aware of the real cost constraint from the outset, their projections about what they can accomplish will be much more accurate%u2014and, often, much more ambitious%u2014than if they were left to make guarded guesses about what the cost constraint might be.
2. Goals are more important than specs
Initial scope and specifications documents are a form of guesswork product design often done by whoever owns the project, rather than by actual product designers. Such documentation is meant to serve as the definitive blueprint for the project, but have you ever (seriously, ever in your life) seen an early scoping document that turned out to be anywhere close to accurate when the project was done? This isn't because the people drafting these documents are incompetent; it's just that product design is something best left to, well, product designers.
And even for the most experienced product design professionals, the beginning planning stages of a project are the time when the least is known about what the project will actually entail. This is the worst time to have to lay out definitive specifications for the product. Complex, UX-focused software projects just don't lend themselves to extensive upfront planning and specifications efforts%u2014too much of the project's actual needs won't be discovered until design and development commence. So how, then, can project stakeholders ensure their vision and requirements for the product are met? By expressing their needs very clearly in terms of the business' goals for the product. Goals are another form of constraint.
When business stakeholders attempt to build detailed specifications up front, they are attempting to extrapolate specific requirements from their general goals. If Ikea took this approach in their product design, businesspeople would spend a week in a conference room trying to describe in words in long, numbered lists, exactly what a chair or table should look like and what features it should have. This would obviously be silly; product requirements (for both furniture and software) are best expressed through design materials and prototypes, not through lengthy specs built by business stakeholders. The stakeholders' role is to clearly express the constraining goals for the product and hand those off to product designers who can begin to design the specifics.
Business stakeholders need to ask themselves, what does it mean for a project to succeed? Is it successful if it fulfills on guesswork requirements built by the wrong people at the wrong time in the project, or is it successful if it meets the business' goals and stays within its budget constraints? Business stakeholders have the clearest understanding of what the company needs the product to accomplish, but the team that will build the product will advise them best on how to meet the goals. Setting clear, high-level goal and sharing the project's budgetary constraint gives a reliable development team the ability to plan accurately, reduce risk, and squeeze the most bang out of a buck.
3. Honesty and trust are mandatory
As we mentioned, many companies refuse to share their budget out of worry that they'll be taken advantage of. If you tell a car salesman that you're willing to spend $30K, he'll try to sell you a $20K car for $30K. If, on the other hand, you keep your budget constraint to yourself, you may drive out with a $20K car and $10K in savings in your pocket. But when shopping for cars, you're dealing with products that have already been built, and you're just picking the one that suits you. But when you're building software or a website, you're building something entirely new with great uncertainty about, and flexibility in, the details of the implementation. The scope of the product is a direct function of its available budget.
It's critical that you be able to work honestly and openly with your development team or vendor. You'll collaboratively manage a project to ensure it fulfills its goals, stays within its cost constraint, and delivers the best value possible. If you don't think you can trust your development team or vendor enough to share your budget with them, then you're working with the wrong team. That lack of trust will undermine the success of the project by crippling your ability to collaborate effectively. You and the development team need to be partners in building a great product, not adversaries who are managing each other as risks. In an adversarial or arms-length relationship, the development team will always be trying to do the least amount of work for the most money. The business stakeholders, for their part, will be trying to take advantage of the ambiguities in the initial scoping documents to get the development team or vendor to do more work for the same price. Both parties will be focused on protecting their interests, rather than working as true partners toward the joint goal of a good outcome for the project.
This partnership with the design team is what Ikea achieves by staying goal- and cost-focused. While it's uncertain what the product will look like, it's never ambiguous what the definition of success is for that product. This business stakeholders and design team are working toward the same goals without needing to keep information from each other.
4. Abandon guesswork for concrete understandings
This guessing game of "what's my budget" is very much a waste of time. Some business stakeholders think they couldn't possibly guess what a project should cost, but in thinking this they're approaching the problem backwards. When it comes to important, high-complexity, UX focused software and website development efforts, the question isn't "what should this cost," but instead "what can this cost?" One needs to have a number in mind%u2014a limit that will constrain the scope and ambitiousness of the project. Giving development teams a pile of guesswork specifications documentation will just get you a pile of guesswork price estimates. What you end up with are unreliable specifications and unreliable cost estimates. By providing development teams with a specific understanding of your cost constraints, you make it much easier for those teams to make accurate projections about what will be possible. This also lets development teams show you other projects from their portfolios that had similar budgets. This, in turn, allows everyone to work from a solid understanding of the cost constraint with a concrete example of achievable scope. Development teams can help stakeholders by providing detailed information about the budgets and challenges encountered in their portfolio projects.
We believe that these four lessons are important to succeed in the high-complexity domain UX-focused software and Web development. Making cost a primary constraint and sharing budgets with development teams may require a shift in thinking by all parties involved. Business stakeholders need to trust the teams they work with, and therefore choose to work with teams that are trustworthy. Development teams need to earn that trust by clearly communicating what they will do with the information and by being honest and transparent about their projections and about project progress once it's underway. And if there's any doubt on either side, you can always say, "Hey, it works for Ikea".
Wednesday, February 17, 2010
Lessons from Ikea | UX Magazine
Wednesday, January 06, 2010
Aaron Forth | UX Week 2009 | Adaptive Path
Great presentation about the value User Experience design on business.
Tuesday, December 01, 2009
No Silver Bullet
More than 20 years ago Fred Brooks published a seminal essay on the nature
of software, called "No Silver Bullet: Essence and Accidents of Software
Engineering" (see http://en.wikipedia.org/wiki/No_Silver_Bullet). If you've
never read it I'd highly encourage it, as even though it's ancient by the
standards of our industry, it's still amazingly relevant and gets to the
heart of why creating great software is so hard.
I thought of this article again recently, as one thing that truly frustrates
me is that there are always people out there in software arguing that their
favorite technique is essentially a silver bullet, and all you need for
great results is to follow their favorite practice. Reminds me of the old
saying that if the only tool you have is a hammer, then every problem looks
like a nail.
For some reason, the software process world has always seemed to attract
more than its share of these zealots. I hope I never become one of those
people.
I am a big fan of Scrum and aggressively advocate its use, but sadly there
are many core problems it simply doesn't address.
Similarly, I'm a huge fan of web analytics and split testing to optimize
products, yet there are critical insights about your users you'll never
learn if this is your only technique.
I also love to use the combination of high-fidelity prototypes and user
testing, yet I would never argue that this is all you need to do.
Same with personas, contextual inquiries, product principles, charter
customer programs, and dozens of other valuable techniques.
Instead I believe that a strong product leader needs to be armed with a
range of tools and techniques to be employed where appropriate.
I'm sorry if this sounds harder than just learning a single tool or
technique, but not only will you create better products, but you'll find
that you are better equipped to deal with whatever product challenges you're
faced with.
** Did you find this article useful? If so, please consider forwarding this
newsletter on to your colleagues.
Recent Popular Articles:
Lessons from the VC Industry:
http://www.svpg.com/lessons-from-the-vc-industry/
Lessons from Incubators: http://www.svpg.com/lessons-from-incubators/
Lessons from Amazon: http://www.svpg.com/lessons-from-amazon/
You can find all articles at www.svpg.com/blog.
Wednesday, October 21, 2009
Sell Yourself the Steve Jobs Way
At your level, people expect a good presentation — including the interview.
Effective presentation skills will not only help you sell your ideas and products, but it will elevate your personal brand. Management guru Peter Drucker once said, “As you move one step up from the bottom, your effectiveness depends on your ability to reach others through the spoken and written word.”
Apple CEO Steve Jobs is considered one of the best presenters in the corporate world today. In my previous article on his lecturing skills and my new book, The Presentation Secrets of Steve Jobs, I reveal the tactics behind his famed “reality distortion field,” outlining the exact techniques that Jobs uses to engage his audience.
Whether you’re a CEO, manager, consultant, entrepreneur, business owner, professional – or especially, a job seeker – Steve Jobs has something to teach you.
Here are five ways to sell yourself or your brand the Steve Jobs Way.
Sell dreams.
Steve Jobs doesn’t sell computers. He sells “tools to unleash your creativity.” You see, nobody cares about your job search (product ); they care about themselves, their problems and their dreams. Tell them how you can help them reach their dreams, and you’ll have won a customer (or fan) for life.
When Jobs introduced the iPod in 2001, he said that music transforms people’s lives and that in its own small way, Apple would be changing the world. Where most people saw an MP3 player, Jobs saw a better world.
How do you make the world a better place? How do you improve the lives of your customers? How will hiring you help a manager fulfill her dreams?
Don’t leave your listeners guessing.
Create Twitter-friendly headlines.
Steve Jobs has a one-sentence description — or vision — for every product he introduces.
- What’s the MacBook Air? “It’s the world’s thinnest notebook.”
- What’s an iPod? “It’s one thousand songs in your pocket.”
If you can’t explain yourself in 140 characters or fewer (a Twitter post), go back to the drawing board.
How would you describe the vision behind your personal brand? Long before I had Fortune 5 clients, I saw myself as “The communications coach for the world’s most admired brands.” In 61 characters, it gave my clients a reference point and gave me a vision to attain. Every product needs a vision — and so does every business professional.
Stick to the rule of three.
Most Steve Jobs presentations are divided into three parts. Neuroscientists are finding that humans think in “chunks” of three or four. Great presenters like Jobs don’t overload the brain with too many points. In media training, we coach executives to do the same: Stick to three main points they want to deliver in the course of an interview.
The same holds true for job interviews — stick to three main points that you want the recruiter to know about you and your experience.
- Introduce the three points early in the interview.
- Expand the points as the discussion unfolds.
- Summarize them at the end.
Strive for simplicity.
According to Steve Jobs, “Simplicity is the ultimate sophistication.” Not only are Apple’s products simple, so is the way the CEO articulates the vision behind those products. For example, Steve Jobs’ presentation slides are remarkably free from clutter.
Your resume should be as well.
Strive for simplicity in oral communications and in presentation design.
Practice like crazy.
Steve Jobs makes presentations look effortless because he works at it. He spends hours and hours over many, many weeks rehearsing every segment of his keynote presentations. Jobs takes nothing for granted, and neither should you. Practice presentations out loud. Practice for job interviews as well. Have a friend sit across from you and ask you tough questions. Rehearse your responses.
Better yet, record yourself and watch it back. It might a painful exercise but well worth it!
One more thing … Do what you love.
Career Advice from TheLadders
Steve Jobs revealed the secret to career success in a 2005 commencement address at Stanford University. He said, “Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. If you haven't found it yet, keep looking. Don't settle.” In this global economic crisis, many people are facing setbacks in their careers. Steve Jobs also faced setbacks but was convinced that the only thing which kept him going was the fact he had found his passion. Jobs once said his goal wasn’t to be the richest man in the cemetery ; it was going to bed at night thinking he had done something wonderful.
Do something wonderful, and you’ll know real career success and satisfaction. And that’s the kind of manager employers would die for.
Tuesday, October 06, 2009
Feed The Beast
Subscribe at: http://www.svpg.com Feed The Beast For those that haven't heard the term before, "feed the beast" refers to one
of the most common problems with product teams, and one of the top reasons
for failed projects. It's very easy to spot. If you find a product manager
that is scrambling to finish up his PRD because the developers are freeing
up from their current project on Monday and the very thought of the
developers not having a fresh spec ready to go sends the product manager
(and especially senior management) into a panic, that's what we call "feed
the beast." The beast is of course the development organization and the beast does have
a voracious appetite. Unfortunately, the beast generally can't distinguish
between something that's worth eating and something that's not. Beasts eat
PRD's and we all know what comes out the other end. This feed-the-beast mentality stems from the observation that the largest
cost in a product development organization is the engineers, so it's
important to keep them fully utilized. Ironically, this overly simplistic
view results in maximizing utilization (they are busy) but not maximizing
results (producing successful products). Further, this mindset tends to diminish the development organization's real
contribution. They are treated as a software factory optimized for coding
rather than a collaborative partner for discovering and delivering
successful products. I like to say that if you're using your developers for
only coding, you're only getting about half their value. Good product organizations understand that their responsibility is to
provide the development organization with something worth building;
something where they have evidence that the products that are created will
be successful. Part of this is simply management not understanding the difference between
building the right product, and building the product right. But often the
company's culture plays a role in creating this problem. I love what a great project manager can do to help you deliver quickly (see
www.svpg.com/ebays-secret-weapon/), but it's also true that in some
companies project management plays too central of a role, and the entire
focus becomes about schedule and resource utilization. This is why normally
I encourage project managers to take a back seat during product discovery,
and then move to the drivers seat only once you're sure you want to actually
build the product. I find this works well, except in situations where
there's nobody that knows how to drive in the drivers seat during discovery,
and I'm going to discuss this situation in the next article. So what do you do if you are stuck in this "just in time" situation? There
are several options: 1. the developers can work on critical infrastructure/headroom activities
(see www.svpg.com/engineering-wants-to-rewrite/) 2. the developers can work on fixing defects and improving performance 3. the developers can participate in product discovery activities In general, we try to build a backlog of useful product specs of about a
month or so. This way, if you run into trouble on a project (for example,
you test your idea on users and they think what you're proposing is a big
waste of time and they'd never use it), then you have work that is ready to
go while you move on to pursue other ideas. It is also possible that your project team is out of balance. If there are
too many developers relative to the number of product managers and
designers, then you will perpetually be behind and your organization is not
able to properly utilize the developers you have. I have seen some teams
where one product manager is trying to define products for 20 or more
developers and this is just a clear recipe for poor products. If you're not
sure about the proper ratios, see www.svpg.com/roles-and-ratios/. Just please remember that no matter what you do, your top priority is to
ensure that the team is building something worth building, and that the
development team is a very big investment for the company and should not be
wasted, either by having people waiting around or by rushing to build
something that will just have to be done over again later.
Thursday, September 10, 2009
7 Must Read Presentations for Job Seekers
|
