I was in a meeting yesterday with a couple of the guys on the intranet team, and asked them about the process they have for user experience (UE) changes: collecting requirements, creating designs, getting signoff, etc...
Their answer is that basically they've done a sufficiently good job on this that asside from a couple of sign-offs from the brass they're pretty much free to do things that seem to make sense. For the latest round, it took two people 7 months to come up with requirements for a new set of designs, and that this felt like a long time.
wow.
We just updated the UE of our external site. I'd estimate it took at least an order of magnitude more human months to figure out and document what it was that we were going to do do. Not implementing a single line of code, mind you. Just deciding what it was that we were going to do: what would the new home page look like? what should our other page templates look like?
A lot of this makes sense. The brand of the company is involved. There is a lot of mission critical business on the website, with potential customers, existing customers, investors, etc... The intranet by its nature is internal, so the marketing, support, and product teams don't really want to be part of the conversation every step of the way.
How much effort should we be putting into tracking the effort we put our UE requirements and design? Are there any industry benchmarks for this kind of thing that would be relevant?
Saturday, January 06, 2007
Subscribe to:
Post Comments (Atom)
1 comment:
I work at a startup that's about to launch a brand new look and feel. Kinda like what you guys did awhile back.
We estimated it would take a month of design work, and 2-3 months of engineering effort.
We were given, by executive managment, two weeks for design and two weeks to implement and launch.
It took about two months of design and two months of engineering, and a lot of guilt that we were "late", despite a bang-on accurate scope at the beginning.
Anyway, we're a *lot* smaller, which far fewer levels of beaurocracy to get sign-off on, and a culture of not bothering to document extensively, so I expect we'd be a lot quicker out of the gate than you guys are.
But the funny lesson that keeps popping up is right up there at the top of your blog: "cheap, fast, or good? choose two." Our designs after 2 weeks couldn't come close to meeting approval by the people who wanted us done already. We're limited in resources, so "cheap" is a constant. We chose "cheap and fast" and got crap, and ended up going with "good" and it took the full scope of the project.
My advice on redesigns is:
1. Invest in clean markup. Bad xhtml means lots more time in design implementation, and invariably, the design will change late into the project.
2. Invest in a styleguide. Create design patterns for your redesign efforts that will scale across the site and enable more people to do the same thing at the same time, if you have to add resources to the project.
3. Focus groups early and often.
4. Involve executives (or stakeholders) early and often.
5. Prototype early and often.
and finally
6. Isolate your release as a design update release only. Don't try to throw in tons of new features in the same time.
Post a Comment