jaywest / tags / team

Tagged with “team” (3)

  1. How To Run A SPOT Project Kickoff Meeting | Manager Tools

    This guidance describes how to run the first meeting you have with your team about a new project your team will be doing.

    A manager we know got assigned a project for he and his team a couple of years ago, and he asked us to critique his email that he was sending out to announce the project, both big picture and early assignments. We knew this manager, and knew his team were collocated with him. Why, we thought, would a manager send out a LOOOOOOONG email to his team with LOTS of details about a not unimportant project?

    He told us, well, that's just the way I've always done it.

    Well, there's a better way. It's MUCH more effective to have a brief meeting. It's called a SPOT meeting, and even though it's yet another meeting, it's totally worth it. Here's how to run one.

    https://www.manager-tools.com/2011/03/how-run-a-spot-project-kickoff-meeting#

    —Huffduffed by jaywest

  2. Project Status is Never “Fine” | Manager Tools

    Never ask how a project is going. You'll get information that isn't helpful…and it's your fault. Ask for status, and define what status is.

    The average reported status of all projects all the world over is always "fine". That's not to say the projects are actually fine - they're all mostly crap. But we managers have a bad habit of asking the wrong questions of project team members of directs. And directs are smart enough to obfuscate.

    Let's get better at asking.

    https://www.manager-tools.com/2014/02/project-status-never-fine

    —Huffduffed by jaywest

  3. SpoolCast: A Practitioner’s Guide to Prototyping with Todd Zaki Warfel » UIE Brain Sparks

    Duration: 31m | 16 MB

    Recorded: April, 2010

    [ Subscribe to our podcast via

    ←This link will launch the iTunes application.]

    [ Subscribe with other podcast applications.]

    [ Transcript Available ]

    Podcast: Play in new window

    | Download (Duration: 31:04 — 16.0MB)

    Prototyping is an iterative process. You generate design concepts. You test them. You discover what works, what needs improving, and opportunities for new ideas. Then repeat. Prototyping your design will get your team and your stakeholders to talk about it. They’ll use it, touch it, walk through it at a point in time when you can make changes inexpensively.

    Last year, Todd Zaki Warfel, a recognized leader in the design-research and usability fields, joined us for a UIE Virtual Seminar: A Practitioner’s Guide to Prototyping. In it, Todd explores his Eight Guiding Principles for prototyping. These principles are the foundation for more effective prototyping, regardless of the method and tool your team uses. Also, Todd’s principles are sure to test and improve your design whether you’re a seasoned prototyper or just getting your feet wet.

    Todd is a Pied Piper in the user experience design world. We’ve seen it! At conferences, everyone wants to catch up with him to see what he’s doing and what he’s thinking about. He’s loaded with charisma! Oh, and he’s a pretty good designer, too. He thinks about this technique a lot, so we’re thrilled to have Todd’s UIE Virtual Seminar as part of our UIE User Experience Training Library.

    Here’s an excerpt from the podcast.

    “…For us, we actually use the prototypes as our specification, for the most part. Now, there are some things that you’re not going to see or that maybe won’t be self-evident in the prototypes. Some of the business rules or back-end functionality may not really be clear in the prototype.

    What we found, and this is actually one of the reasons why we turned to prototyping and away from an older, traditional method of wire frames with written specification documents. What we found is that, since the prototype, basically, is show and tell and allows you to see the story as well as tell the story and actually play around with the systems, it’s much more tangible. When we do prototyping, we find that actually, any specifications that have to be written are dramatically reduced.

    So, for example, in my book there is a case study from a gentleman over in the UK and their old, traditional system was: do some wire frames, write a 200-page specification document and deliver it out to the development team. And they shifted over to using more of a prototyping model. And for similar systems that they used to have to write a 200-page spec document, they found themselves delivering the designs, with specifications, about three times as fast and that the specifications went down to 20 pages instead of 200.

    And so they’re essentially using the prototype as the bulk of the specification and then writing some supplemental documentation to describe things that aren’t self-evident, like back-end business rules and maybe some technology-type stuff. And we’ve done a very similar approach.

    So, a lot of times, what we’ll do is prototype out maybe a core flow, plus maybe some error sessions and maybe some success screens and that type of a thing. But, we won’t typically prototype out every single scenario. We’ll kind of do the 80-20 rule. So, here’s 80 percent of it prototyped out. You can pretty much see how it works. And then any additional, supplemental information that may not be self-evident in the prototype, we’ll either write some documentation, or in a lot of cases actually, our clients just take the prototype and then their internal team basically writes that spec…”

    If you thought that was interesting, you’ll also hear Todd address these questions:

    If you’re prototyping only some of the functionality, how do you talk about the rest of the functionality that isn’t in the prototype such that the team knows how to fill in the gaps?

    How are you able to do usability testing when the prototypes are not refined, or they’re missing pieces?

    We often talk about how prototyping lets you reduce risks, but does it give you an opportunity to actually take risks?

    Do the prototypes have to be made with the same technology that you’re going to use in your production system, or are there actually advantages to doing them in something completely different?

    If you have any questions or thoughts on prototyping, please feel free to share them in the comments section below.

    This entry was posted

    on

    Friday, January 7th, 2011

    at

    2:28 pm

    and is filed under

    Design Deliverables, Design Documentation, Design Process, Podcasts, prototyping, SpoolCast, UIE Virtual Seminar

    . You can follow any responses to this entry through the

    RSS 2.0

    feed.

    You can leave a response, or trackback from

    your own site.

    Tweet

    http://www.uie.com/brainsparks/2011/01/07/spoolcast-a-practitioners-guide-to-prototyping-with-todd-zaki-warfel/

    —Huffduffed by jaywest