Well it's coming to that time of year again! The IA Summit is almost upon us and i am looking forward to it.
Especially since i have just seen the program which includes
Pre-conference workshop
UX Management: developing and growing yourself and a team of user experience professionals
Margaret Hanley
Also the Extra "Wall of Deliverables" sounds pretty interesting!
Wall of Deliverables – See how others are communicating design to their coworkers. This year there will be a special display of deliverables set up so you can peruse them at your leisure. Take back some tips and tricks that your peers are using or participate to get feedback on your deliverables. To add your deliverables simply bring them along and tack them up!
Anyway it should good, all i have to do know is make sure i can get there!
Jim
Thursday, January 31, 2008
Thursday, May 03, 2007
I designed the site, how did I do?
How do you know that the site you designed is fantastic when the user hasn’t even taken the time to email you personally to say how much fun they’ve had filling out their latest online form to pay their latest electricity bill?
It can be difficult sometimes to be sure when you ask your colleagues.
Management “you did good, they got AJAX so they must be happy”.
Development “you did good, the bill got submitted”.
Human Resources “we don’t know”.
Feedback can be ambiguous to the client when the response after a bout of user testing is that the site was “ok to use” and that “The user would use the site again because they have to pay a similar bill next month”. Clients can sometimes be hesitant to voice their opinions when they are not exactly sure what they are reviewing.
It seems to be that an IA (viewed by client or colleague) does something, the site gets built and then the IA moves on without any true review to mark their success or failure. Web statistics may prove that “something” once the site goes live but this is far too late in the process.
Educating clients and colleagues in information architecture is a must as our discipline still has that “unknown” factor. Presenting sitemaps, wireframes and prototypes must be complimented with:
· The reasons behind your IA decisions
· The value they have to the business and customer
· How a decision made now will affect the success of the end goal
· Brief descriptions of other solutions (and why the solution you chose is the correct one to use)
Better understanding of the IA process will build client confidence, which in turn will encourage them to take active roles in site reviews and user testing activities. The same goes for your project team as this may also help colleagues support your decisions and help fight your corner in times of need.
The idea is that the non-IA’s in a project environment can give fair and constructive feedback on your designs and user-test results.
What are your thoughts on this……?
Dr Pepper
It can be difficult sometimes to be sure when you ask your colleagues.
Management “you did good, they got AJAX so they must be happy”.
Development “you did good, the bill got submitted”.
Human Resources “we don’t know”.
Feedback can be ambiguous to the client when the response after a bout of user testing is that the site was “ok to use” and that “The user would use the site again because they have to pay a similar bill next month”. Clients can sometimes be hesitant to voice their opinions when they are not exactly sure what they are reviewing.
It seems to be that an IA (viewed by client or colleague) does something, the site gets built and then the IA moves on without any true review to mark their success or failure. Web statistics may prove that “something” once the site goes live but this is far too late in the process.
Educating clients and colleagues in information architecture is a must as our discipline still has that “unknown” factor. Presenting sitemaps, wireframes and prototypes must be complimented with:
· The reasons behind your IA decisions
· The value they have to the business and customer
· How a decision made now will affect the success of the end goal
· Brief descriptions of other solutions (and why the solution you chose is the correct one to use)
Better understanding of the IA process will build client confidence, which in turn will encourage them to take active roles in site reviews and user testing activities. The same goes for your project team as this may also help colleagues support your decisions and help fight your corner in times of need.
The idea is that the non-IA’s in a project environment can give fair and constructive feedback on your designs and user-test results.
What are your thoughts on this……?
Dr Pepper
Sunday, October 29, 2006
SWIPR - Don't leave home without it!
Well it's been a busy weekend, 20+ hours of creating a SWIPR flow for an application i'm working on. I will be doing a full write up on SWIPR at some point soon. But for now i just like say SWIPR rocks, if your an Information Architect you really should not be without this awesome piece of free software!
www.swipr.com
Jim
www.swipr.com
Jim
Tuesday, August 01, 2006
Can I have some usability please?
I was recently talking to a friend of mine who also works as an Information Architect and he was going crazy talking about a recent project proposal he had seen that had been drawn up by the company he works for. The proposal was for a rewrite of a web application that was already live. Now this project had been estimated and it was huge, with many thousands of man-hours. A large amount of these hours where for requirements gathering and in particular Information Architecture related tasks. So at first glance this seems normal, but then my friend pointed out that in this initial proposal clearly stated that any improvement to usability and been deemed out of scope, this meant that if the client wanted any improvement to user experience they would have to have to pay extra!
Now I understand this type of practice with regards to a base proposal that offers the bare minimum, maybe based on the Must, Should, COuld, Would approach that can be used in conjunction with some form of DSDM (Dynamic Systems Development Method).
However as I am sure you can guess that that type of approach was not what I have an issue with, my issue was around the fact that “usability” was seen as some form add-on some form of optional item. I do realise that you can different levels of effort with regards to usability, whether it be the use of an Information Architects knowledge, usability reviews, usability testing and so on. But the problem that this proposal really emphasised was a complete lack of understanding of the knowledge and experience an Information Architect brings to a project. The fact they had planned a large amount of time for Information Architecture work to be completed but at the same time they had said “improved usability” was out of scope? What did they expect the Information Architect to do….. sit and copy field and page layout from the current app to the new Visio based wireframes? Now I could be completely wrong in this opinion but for an Information Architect to do there job correctly I believe improved usability is implicit, it’s a given. I can’t imagine working as an Information Architect on a system and not always considering usability and the users motivations and their level of technological understanding and so on, all the things I see as fundamental parts of the Information Architecture process in this day and age.
Jim
(Must, Should, COuld, Would) A priority checklist
Dynamic Systems Development Method
Categories: usability, information-architecutre,user-experience,
UX, theuxsuspects
Now I understand this type of practice with regards to a base proposal that offers the bare minimum, maybe based on the Must, Should, COuld, Would approach that can be used in conjunction with some form of DSDM (Dynamic Systems Development Method).
However as I am sure you can guess that that type of approach was not what I have an issue with, my issue was around the fact that “usability” was seen as some form add-on some form of optional item. I do realise that you can different levels of effort with regards to usability, whether it be the use of an Information Architects knowledge, usability reviews, usability testing and so on. But the problem that this proposal really emphasised was a complete lack of understanding of the knowledge and experience an Information Architect brings to a project. The fact they had planned a large amount of time for Information Architecture work to be completed but at the same time they had said “improved usability” was out of scope? What did they expect the Information Architect to do….. sit and copy field and page layout from the current app to the new Visio based wireframes? Now I could be completely wrong in this opinion but for an Information Architect to do there job correctly I believe improved usability is implicit, it’s a given. I can’t imagine working as an Information Architect on a system and not always considering usability and the users motivations and their level of technological understanding and so on, all the things I see as fundamental parts of the Information Architecture process in this day and age.
Jim
(Must, Should, COuld, Would) A priority checklist
Dynamic Systems Development Method
Categories: usability, information-architecutre,user-experience,
UX, theuxsuspects
Monday, July 31, 2006
Interaction Layers and AJAX
So my current thinking on documenting AJAX is that I’m going to have use prototypes. Well my first reaction to this problem was that storyboards would handle this issue very nicely, then I actually put about two seconds of thought into the problem and realised that there could be two or more streams of information / interaction going on at any one time. So within this in mind you can still storyboard each interaction stream and then use a layered approach to show if and when interactions overlap (I think I’m going to call them “Interaction Layers”)
The more I think about this the more I can see that there will be different types of Interaction Layer. Well it’s more that I want to work in a way where I can classify different types of Interaction Layer.
(I feel I must mention at this point if you hadn’t already guessed, one of my main drivers/goals at the moment is to build an Information Architecture pattern library.)
So with this in mind and the fact that I want to classify these “Interaction Layers” I need to work in such away that whatever classification structure I use can then be reused at any level of my phantom pattern library.
Phantom Pattern Library Structure (BETA 2.0 ;-) )
Level 1
Field
Level 2
Component
Level 3
Page
Level 4
Section
Level 5
Application
Putting this in to practice will be interesting but for me the best aspect of this approach will be watching the library grow. As usual I digress so I will leave that idea there for now.
As I mentioned in an early post one of the elements of AJAX that must be documented with the greatest amount of care is Timing, Timing as I see it is the one place were storyboarding can’t help you. This is where prototyping is going to have to play a part!
Right I feel I wondered of so many issues in this post that I best stop now!
Jim
Categories: information-architecture, user-experience, web2.0, UX, theuxsuspects, wireframes, IA, RIA, AJAX
The more I think about this the more I can see that there will be different types of Interaction Layer. Well it’s more that I want to work in a way where I can classify different types of Interaction Layer.
(I feel I must mention at this point if you hadn’t already guessed, one of my main drivers/goals at the moment is to build an Information Architecture pattern library.)
So with this in mind and the fact that I want to classify these “Interaction Layers” I need to work in such away that whatever classification structure I use can then be reused at any level of my phantom pattern library.
Phantom Pattern Library Structure (BETA 2.0 ;-) )
Level 1
Field
Level 2
Component
Level 3
Page
Level 4
Section
Level 5
Application
Putting this in to practice will be interesting but for me the best aspect of this approach will be watching the library grow. As usual I digress so I will leave that idea there for now.
As I mentioned in an early post one of the elements of AJAX that must be documented with the greatest amount of care is Timing, Timing as I see it is the one place were storyboarding can’t help you. This is where prototyping is going to have to play a part!
Right I feel I wondered of so many issues in this post that I best stop now!
Jim
Categories: information-architecture, user-experience, web2.0, UX, theuxsuspects, wireframes, IA, RIA, AJAX
Friday, July 21, 2006
Information Architecture deliverables for the RIA, Web 2.0, AJAX, etc
From what I can figure out just showing the states of an AJAX page is not enough and it will leave too much room for error. For example if I only document each physical state of an AJAX page/component on a static Visio page that would then be covered in notes and dotted outlines in different colours to try show what would be going on at any one given moment I really don't think a client and a dev team can look at them and understand how I intend/require a page/component to function. How will they get the feel of the "interactivity" and as far as I’m concerned more importantly get a feel for the most important issue of understanding the "timing".
I believe working in this way will create a very nasty grey area for the client and the
dev team. The clients will have formed their own expectations of how a page will behave and if they sign off on that expectation and then we deliver something "Different" or as they might see it "wrong" it could be a nightmare. The same issue can be said for the dev team. If they don't understand how we want it to work and they spend time developing an incorrect solution that could be even further from the already unknown client expectations! So as I see it we really will have a problem!
Now I could have over dramatised the issue but as far as I’m concerned I’m not prepared to work with that level of risk.
To be continued…
Jim
Categories: information-architecture, user-experience, web2.0, UX, theuxsuspects, wireframes, IA, RIA, AJAX
I believe working in this way will create a very nasty grey area for the client and the
dev team. The clients will have formed their own expectations of how a page will behave and if they sign off on that expectation and then we deliver something "Different" or as they might see it "wrong" it could be a nightmare. The same issue can be said for the dev team. If they don't understand how we want it to work and they spend time developing an incorrect solution that could be even further from the already unknown client expectations! So as I see it we really will have a problem!
Now I could have over dramatised the issue but as far as I’m concerned I’m not prepared to work with that level of risk.
To be continued…
Jim
Categories: information-architecture, user-experience, web2.0, UX, theuxsuspects, wireframes, IA, RIA, AJAX
Thursday, July 13, 2006
I like it you might.....
Web 3.0 by Jeffrey Zeldman
For me the best bit has to be:"To you who are toiling over an AJAX- and Ruby-powered social
software product, good luck, God bless, and have fun. Remember
that 20 other people are working on the same idea."
Enjoy,
Jim
Categories: information-architecture, user-experience, web2.0, UX, theuxsuspects, wireframes, IA, RIA, AJAX
Ok, so wireframing AJAX.....
Right i know we are all having "fun" with this and there are many different proposed solutions. In fact i think i have my own way of doing this (all theory). So i gona try and read up about this little issue and see what i can think of afterwards.
Jim
Categories: information-architecture, user-experience, web2.0, UX, theuxsuspects, wireframes, IA, RIA, AJAX
Jim
Categories: information-architecture, user-experience, web2.0, UX, theuxsuspects, wireframes, IA, RIA, AJAX
Subscribe to:
Posts (Atom)
