I do recommend taking a look at a previous thread on the lis "Raising awareness for Interaction Design in a corporate IT company" ( http://www.ixda.org/discuss.php?post=28266 ) .

{ Itamar Medeiros } information designer
http://designative.info/
http://www.autodesk.com/

Posted from the new ixda.org
http://www.ixda.org/discuss?post=29332

Hi Itamar,

I do recommend taking a look at a previous thread...

Thanks for the link. But that thread seems to deal more with how to sell the idea of design. Here, they are already sold (thankfully). I need to decide what to do first to have the maximum impact (low hanging fruit, etc.).

They have worked with people from a central Human Factors Engineers group in the past, so they have certain expectations that I will have to contend with. For example, they are used to getting mockups of flows in PowerPoint. So the idea of having some kind of prototype to show to stakeholders is already there.

I guess I need to steer them toward using more appropriate tools (maybe Visio instead of PPT at this stage; not ideal but better). And also try to convince them of the value of putting mockups/prototypes in front of actual users as well as stakeholders.

Any other ideas?

Thanks,

Martin

On Thu, May 22, 2008 at 12:16 AM, Martin martin.polley at gmail.com wrote:

What would you do?

Hi Martin,

Offer to facilitate design/whiteboard sessions and volunteer to write the design specs. You've got writing gifts so this seems a natural extension. The dev team will be thankful because they typically love having specs but hate writing them. As part of the design and specification process, you can offer suggestions on interfaces. This works out especially well if you prepare two or three different versions of wireframes ahead of time as discussion aids. You'll never build the wireframes you bring the first time, or maybe even the third or fourth, but be thankful - those are the wrong solutions. You want to contribute your time to the design effort and help the team be successful. Listen to your developers and make sure that you're documenting information they'll use and not just something that fills in blanks on a form and gets ignored afterwards.

Some designs you'll be able to get close by iterative refinement and an awareness of design patterns. You'll be able to detect many usability problems before build time if you schedule a day or two for testing a paper prototype using random people you grabbed walking down a hallway.

If you can get a little budget for field studies to observe your existing users work with your software this will give you valuable perspective on their tasks and goals. It may be difficult to get permission and funding for this initially; keep asking.

The main idea is to be a facilitator of design on the team. As you succeed with simple concrete tasks, like preparing specification documents, you can gradually expand your role. This will give you time to study and learn how to do new tasks ahead of time.

Finally, if you're good with graphics, symbols, colors, visual design - offer to contribute to this part. Otherwise some Java programmer will do it all in the Gimp, underwhelm, and deliver code late.

Hope this helps,

Michael Micheletti

Caveat - I am in the same position as yourself and do not in any way consider myself an expert.

That said, I feel your strategy here is entirely dependent on how early on in the process you are working, what your timeframe is, and how much flexibility you have.

In my case, I am being brought in during concept stage, with the plan to start developing the software in July, and the opportunity to develop a new branding identity and marketing materials as well as user assistance documentation once the software is well into development. So I have time for all kinds of data collection from the marketing department, and to develop user scenarios, usability testing procedures, and eventually personas and use cases. Following that I plan to do wireframes and paper prototypes with iterative testing and design refinement, based on various concept models for testing usability. In other words, I've been given the time and leeway to go all out on not just usability testing but user experience design including re-architecting documentation and designing marketing materials as well as help systems.

On the other hand, you may have very little time or leeway for usability testing. There is definitely information out there for executing "guerilla usability testing". Certainly any testing is worthwhile, and if you Google you will find lots of resources.

It is up to you which way you take it.

Cheers,
Erica

Posted from the new ixda.org
http://www.ixda.org/discuss?post=29332

Hi Michael,

Thank you for the wise words.

Offer to facilitate design/whiteboard sessions and volunteer to write the design specs.

... you can offer suggestions on interfaces ... prepare two or three different versions of wireframes ahead of time as discussion aids.

I get the definite impression that they are after something more visual that they can take and translate into the built product. Which raises another question: how interactive/hi-fidelity to make wireframes/prototypes? Whiteboard/paper? Visio with layers to simulate different page states? HTML/CSS/JS for something that wags and barks like the real thing? (The latter will require a crash course to fill in some big blanks...)

They are used to receiving PPTs to illustrate interaction flows, so I guess anything's better than that : 

If you can get a little budget for field studies...

I will definitely try to get them to let me do some sort of usability testing. Something small to begin with, to prove its worth.

The main idea is to be a facilitator of design on the team.

I'll try to keep that in mind at all times.

Finally, if you're good with graphics, symbols, colors, visual design - offer to contribute to this part. Otherwise some Java programmer will do it all in the Gimp, underwhelm, and deliver code late.

Or more likely it will be the standard GWT look with a logo slapped on it : 

Thanks very much,

Martin

Hi Erica,

... your strategy here is entirely dependent on how early on in the process you are working, what your timeframe is, and how much flexibility you have.

I think my timeline is going to be a bit more compressed than yours. I'm coming into a project in the middle, where the functionality of an existing product is being extended. So I probably will have to take a somewhat guerrilla approach. But I certainly get the importance of usability testing, and I'll try to incorporate it somehow.

And I still have to make sure the documentation is ready on time as well.

Thanks,

Martin

On Thu, May 22, 2008 at 8:14 PM, erica ericamhc at gmail.com wrote:

Caveat - I am in the same position as yourself and do not in any way consider myself an expert. That said, I feel your strategy here is entirely dependent on how early on in the process you are working, what your timeframe is, and how much flexibility you have. In my case, I am being brought in during concept stage, with the plan to start developing the software in July, and the opportunity to develop a new branding identity and marketing materials as well as user assistance documentation once the software is well into development. So [trim]

-- Martin Polley
Technical writer, etc.
+972 52 3864280
Calendar— http://capcloud.com/calendar
Site— http://capcloud.com/

On Thu, May 22, 2008 at 12:28 PM, Martin martin.polley at gmail.com wrote:

I get the definite impression that they are after something more visual that they can take and translate into the built product. Which raises another question: how interactive/hi-fidelity to make wireframes/prototypes? Whiteboard/paper? Visio with layers to simulate different page states? HTML/CSS/JS for something that wags and barks like the real thing? (The latter will require a crash course to fill in some big blanks...) They are used to receiving PPTs to illustrate interaction flows, so I guess anything's better than that : 

Ugh Visio layers, what a sadly broken feature. You've listed some good choices. The usual criteria to select might include:

For usability testing, it's great to have a working prototype. It's perfectly acceptable during an early design stage to use a paper prototype. A paper prototype gets done quick, finds lots of problems, is easy to work with, low tech, cheap. No style points but big results, and early in the project where it can really count.

Powerpoint can work for you too if needed. Flash is a great prototyping tool, as is HTML/CSS/Javascript. There's a tendency for Flash or HTML prototypes to end up as front end code in the app sometimes so heads up there. Since you're introducing design into the process for the first time, and it's a bit new to you, I'd recommend that you focus more on facilitating design processes and communications than on higher fidelity prototypes, at least during the early phases of the project. Good luck!

Michael Micheletti

Thanks, Michael. Those are all important factors. I didn't have it as clear in my head as how you articulated it.

As for "what the customer prefers", I think they are open to being educated and respect and defer to the expertise of people in fields other than their own. (Not that I'm in any way an expert at this stage.)

There's a tendency for Flash or HTML prototypes to end up as front end code in the app sometimes so heads up there.

Not likely in this case, luckily. I'll be working on enhancements to an existing project, so it will be implemented in GWT, for better or for worse.

... I'd recommend that you focus more on facilitating design processes and communications than on higher fidelity prototypes, at least during the early phases of the project. Good luck!

Sounds sensible. I get the impression that I am just expected to come up with one design that will work, which the developers can then go build. So I'll have to impress upon them that this will require some sort of user input. The thing is, I'm not clear about which would better serve the design: some sort of ethnographic research, or some kind of usability testing. (Sure, doing both would be best, but in this situation, what would give me more bang per buck? I think usability testing would be the easier sell, in any case...)

Thanks,

Martin

Hi Martin, I'd talk to your CEO or whoever is in charge, show them before and after scenarios and make a case as to why you think usability = increased revenue. I would also do a bit of internal marketing, ensure your team are referred to as interaction designer (never graphic designers) and do some educational sessions on why preplanning and information architecture add to the product and is something everyone can support. You have to solve the internal attitude to it before you (and your coworkers) can educate the client. I would research industrial design history and how they got into the mix (they were seen as glorified prettifiers before) .
hope that helps.
james

On Thu, May 22, 2008 at 4:38 PM, Martin martin.polley at gmail.com wrote:

Thanks, Michael. Those are all important factors. I didn't have it as clear in my head as how you articulated it. As for "what the customer prefers", I think they are open to being educated and respect and defer to the expertise of people in fields other than their own. (Not that I'm in any way an expert at this stage.) There's a tendency for Flash or HTML prototypes to end up as front end code in the app sometimes so heads up there. Not likely in this case, luckily. I'll be working on enhancements to [trim]

I'm surprised by the advice on this thread, especially yours here James. Talk to the CEO? Why? As Martin explained he's been asked to be more active, not to stage a coup, which is exactly how most of the people in line between Martin and his CEO would see this sort of thing.

Worse, most of the other advice has advocated about 20 lbs. of process and evangalism without asking if all that's needed is an ounce of results.

First and formost: Martin, if you are a self admitted wanna-be, the best thing you can do is to advocate hiring a professional. If you are not confident in your ability, rookie mistakes run the risk of ruining your orgs perception of what a qualified pro can do.

Second: the goal is to make better GUIs, right? That becomes straightforward if you are granted the power to write the first spec, make the first screenshots, and have your boss rallying the development team to make the first prototypes based on your designs. Tons of usability studies, daily whiteboard sessions, or most of the processes mentioned become unnecessary if you have authority from the begining and the expertise to set the right course from day one. Most bad GUIs suffer from the same two dozen or so mistakes - you don't need to be a design maestro to correct or prevent them.

Third: If you have trouble getting support from programmers, go to your boss and ask for more ammo. If the team has never seen a usability study, it can be a great way to get their attention and support, but if your UI problems are basic, you won't be learning much from them - they're more for the team than for you.

Many programmers don't care much about UI design one way or the other - really they dont - what they care about is having a clear spec to work from that makes sense. If you write better specs (in their opinion) than the other guy, and your specs happen to have been UI designs in them, they be building better UIs without even noticing.

Lastly, as far as where to start. Get involved early. Ask for authority over any screens and specifications. Pick one or two of the best programmers out of the bunch and ask them what you can do to get their support (they often have more power than the managers do) . Buy a dozen copies of GUI bloopers by Jeff Johnson and put them on the chairs of anyone that writes UI code, with a post-it note saying "Please please please read this". Most of the rest will take care of itself. Pick small easy clear wins and repeat. Once you've proven you can deliver and have earned a positive reputation, only then look to expand. Only then do internal marketing, using your proven wins as the argument for why even more people should follow your lead.

-Scott

Scott Berkun
www.scottberkun.com

Original Message From: "james horgan" horganjames at gmail.com Cc: "IXDA list" discuss at ixda.org Sent: Thursday, May 22, 2008 1:19 PM Subject: Re: [IxDA Discuss] Introducing design to a dev team for the firsttime Hi Martin, I'd talk to your CEO or whoever is in charge, show them before and after scenarios and make a case as to why you think usability = increased revenue. I would also do a bit of internal marketing, ensure your team are referred to as interaction designer (never graphic designers) and do some educational sessions on why preplanning and [trim]

Martin's question - "Where to start? What are the things I can do right now that will have the greatest positive impact for the effort I will be putting in?"

Speak to the team about key pages or flows that are in need of help and have the greatest impact on the product. Find out where they are hurting and where you can help.

Perhaps a quick usability review and to cross check the thinking with the team.

When you have created some design ideas, walkthrough with the team - http://www.uxmatters.com/MT/archives/000199.php

rgds, Dan

Posted from the new ixda.org
http://www.ixda.org/discuss?post=29332

Hi James,

Thanks for the input. In my case, the CEO is a bit distant. (It's a company with ~100,000 employees worldwide.) My area of influence is just the 11-person development team that I belong to (and to a lesser extent, a couple of sibling teams).

In this company, the whole UX/IxD thing is referred to as Human Factors Engineering. An outdated term, perhaps, but as in any large organization, things don't change overnight.

I think it's just going to be a matter of making the team leader aware of the value of usability testing as part of the design process (i.e., testing before actually building the thing). And we are not talking about a huge project here. At this stage, it is just enhancements to an existing webapp, being developed by two people.

Thanks,

Martin

Hi Scott,

First and formost: Martin, if you are a self admitted wanna-be, the best thing you can do is to advocate hiring a professional.

Well, I am here already so it's not going to cost them much to use me for this. Certainly much less than brining someone else in from outside, justifying budget, etc. And at this stage it's just a few new screens for an existing webapp. If it comes out any better than what they would have come up with on their own, it's a win. (And I really, really WANT to do this! And I'm not a complete amateur—I have done a ton of reading, podcast listening, etc., and I have already given them feedback on existing products, which was appreciated and acted upon.)

Second: the goal is to make better GUIs, right? That becomes straightforward if you are granted the power to write the first spec, make the first screenshots, and have your boss rallying the development team to make the first prototypes based on your designs...

That's exactly what they want me to do. Actually, they want me to design it, then straight to production, no prototypes. Which is why I want to be sure I actually do it right. And if doing it right includes getting some user input on what I design before it gets built (which I think it should) rather than just going full speed ahead and assuming I know best, then that's what I'll do.

Most bad GUIs suffer from the same two dozen or so mistakes - you don't need to be a design maestro to correct or prevent them.

True, but I would think that getting user input (thru some sort of usability testing on wireframes/mockups/paper prototypes/whatever) would (a) catch anything I might have missed (me being fairly new to this thing) and (b) show whether what I think would work actually matches user goals and activities. (I am working in the dark to some extent—no previous user research or even day-to-day interaction with users.)

Third: If you have trouble getting support from programmers, go to your boss and ask for more ammo.

Fortunately, I don't think that will be too much a problem. In fact, they seem to welcome the fact that I will be working with them on this.

Lastly, as far as where to start... Pick small easy clear wins and repeat. Once you've proven you can deliver and have earned a positive reputation, only then look to expand.

Right on. That's solid advice that I can definitely follow.

Thanks very much,

Martin

Hi Daniel,

I guess with "where to start", that is pretty clear (or rather, has become so since my original post). They have said, basically "Here's what we're adding to the product—go design it".

So whatever I do will have to be within the constraints of this particular task, rather than me being able to pick and choose where I would like to make improvements. I guess my refined question is "Apart from the obvious things that I can figure out myself, should I, and how should I, be integrating user research and/or usability testing into my design process? Given very limited time, etc."

What specific things can I do to make sure that what I design will support user goals and activities?

And thanks for the link. Great article. The blanks I am trying to fill are in the process that leads up to having a design to walk though with them.

Thanks,

Martin

Apart from the obvious things that I can figure out myself, should I, and how should I, be integrating user research and/or usability testing into my design process? Given very limited time, etc."

This may have been asked - How much time available do you have to include user research before you need to show them new designs?

rgds, Dan

Posted from the new ixda.org
http://www.ixda.org/discuss?post=29332

This may have been asked - How much time available do you have to include user research before you need to show them new designs?

That's one of the first questions that I will be asking when I get back to work on Sunday : 

Martin

No problems Martin, hope it goes well for you. I do think you have a bit of internal marketing to do especially to shift such a large organizations viewpoint on delivery. Identify the people who can help you make that change and get in touch with them, there are ways to do it without ticking off your team lead.

Scott any new idea that has support from the top people in a company tends to get pushed forward as a result. I'm currently working on a project and if didn't have the vocal support from Bill Gates I think it would be just seen as another 'quack' idea rather than something that can be designed for practical business purposes. Sometimes you've got to go direct to the source, this is how progress is made.
All the best
James