Dmitry, I agree with everything you said :-).
I think that I have also not really communicated my point (problem?) very well. There have only been a couple of times that I have used interactive prototypes (+ minimal documentation) to communicate designs to the developers here. Both times they were relatively simple web application interfaces but with complex back-ends, and both times the developers completed the projects to the t regarding the back end business rules, but only implemented certain aspects of the interaction design. Instead of the specifications tool being the problem, I think perhaps the real problem lies in the context I am working in. There is no resistance from developers to the specifications - they simply run out of time to follow through on a design. Anything UX related that we don't specify very clearly as part of the core of the application tends to fall through the cracks, and another third of the time it's cut out of the project purposefully because the customer does not want to pay for it (and neither do we). Since my company makes money based on customer transactions, even 2 weeks spent on something other than implementing customization requests and getting a customer on our productive system is costing the company revenue, therefore they go to a lot of effort to shave time off every single project. In a way I feel like I have had to change my way of thinking to from 'holistic, clean, and helpful user experience' to 'super-practical minimalist functional design. cheap.' in order to fit into the context of my current job. This is not necessarily a bad thing, but it means that I really had to change the way I work and think. I think I was also a little overenthusiastic in my first few projects e.g. expecting to be able to create some beautiful 37signals-like interface, when what we really need for this customer is an excel-like interface. Nowadays I find myself working much harder to prioritize and distinguish the improvements in interaction design that are _absolutely_ necessary from the ones that are just good ideas, and really think about how I can present them to others so that they seem worthwhile investments in the software from a business perspective. It's still tough because often the most worthwhile improvements in interaction design (e.g. changing the interaction style of one of our base modules to be more intuitive), would take a lot of development effort. Anyway, I'm sure I'm of-topic by now. Thanks for your feedback, - Liz On 10/2/07, Dmitry Nekrasovski < [EMAIL PROTECTED]> wrote: > > Elizabeth, > > I completely agree that, in the enterprise space, business rules are > often what makes or breaks an application. That doesn't mean that > interaction design for these applications is "icing on the cake". On > the contrary, good interaction design will communicate business rules > clearly to the users, and bad interaction design will mangle the rules > or obscure them entirely. > > In my experience, detailed specifications documents simply do not work > well as a means of communicating design, even in an environment of > complex business rules. They are usually too static to effectively > document the design, too heavyweight to be really understood by anyone > but the person who writes them, and too difficult to update to remain > relevant as requirements and scope change. > > As you note, B2B/enterprise applications are often lacking in good > interaction design. If you want to change this in your particular > project, you will need a way to communicate your design ideas and > decisions to your development team. Personally, I have found that > interactive prototypes, combined with lightweight documentation of > business rules and usage scenarios, are an effective way of doing > this. Try it, and you just might find that your developers' resistance > is mostly due to failing to realize that there are alternatives to the > status quo. > > Dmitry > > On 10/2/07, Elizabeth Whitworth < [EMAIL PROTECTED] > wrote: > > Perhaps the best type of specifications document depends on the industry > you > > work in. In my current job in the logistics industry, the only times > that I > > am required to make an interactive prototype is for presentation of a > design > > concept an end-customer. For the rest, the developers hands-down prefer > > simple wireframes/screenshots + a detailed specifications document > including > > use cases and business rules. I think that it is because in b2b > logistics, > > the make or break points of any application rests in the business rules. > Any > > fancy visual/interaction design is just icing on the cake. The > developers > > know this and therefore do not focus very much on the type of > interaction > > design that is typically displayed in an interactive prototype (don't > get me > > started on the need for better interaction design in b2b > applications...:P). > > I imagine this is quite different in a different industry such as > > e-commerce, where interaction design can greatly effect usage or > customer > > satisfaction and therefore becomes more important. > > > > Any comments on the industry/ies you have been working in or the types > of > > applications you have been working on James? > > > > - elizabeth > > > > On 10/1/07, Todd Zaki Warfel < [EMAIL PROTECTED]> wrote: > > > > > > Have you spent any time trying to figure out why? I'm curious what > > > causes this type of reaction from the engineers you're dealing with. > > > > > > On Oct 1, 2007, at 3:43 AM, James Leftwich, IDSA wrote: > > > > > > > Nowadays, I and my partners will often have portions mocked up and > > > > made interactive, mostly for show to our clients or execs while > > > > implementation is underway. No engineers I work with would prefer > to > > > > have interactive models _in lieu of_ the kinds of implementational > > > > documentation I've traditionally provided. > > > > > > > > > Cheers! > > > > > > Todd Zaki Warfel > > > President, Design Researcher > > > Messagefirst | Designing Information. Beautifully. > > > ---------------------------------- > > > Contact Info > > > Voice: (215) 825-7423 > > > Email: [EMAIL PROTECTED] > > > AIM: [EMAIL PROTECTED] > > > Blog: http://toddwarfel.com > > > ---------------------------------- > > > In theory, theory and practice are the same. > > > In practice, they are not. > > > > > > > > > > > > ________________________________________________________________ > > > Welcome to the Interaction Design Association (IxDA)! > > > To post to this list ....... [EMAIL PROTECTED] > > > List Guidelines ............ http://beta.ixda.org/guidelines > > > List Help .................. http://beta.ixda.org/help > > > Unsubscribe ................ http://beta.ixda.org/unsubscribe > > > Questions .................. [EMAIL PROTECTED] > > > Home ....................... http://beta.ixda.org > > > > > ________________________________________________________________ > > Welcome to the Interaction Design Association (IxDA)! > > To post to this list ....... [EMAIL PROTECTED] > > List Guidelines ............ http://beta.ixda.org/guidelines > > List Help .................. http://beta.ixda.org/help > > Unsubscribe ................ http://beta.ixda.org/unsubscribe > > Questions .................. [EMAIL PROTECTED] > > Home ....................... http://beta.ixda.org > > > ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [EMAIL PROTECTED] Unsubscribe ................ http://gamma.ixda.org/unsubscribe List Guidelines ............ http://gamma.ixda.org/guidelines List Help .................. http://gamma.ixda.org/help
