Wiring for a Better Concept
While I think it is ideal that a project complete has proper user research, an a solid concept before I begin creating wireframes, I have had enough experience to know that it does not always happen that way.
The process of wireframing however, can help a client, project team, and developers realize form a solid concept.
The project I’m working on right now is a great example. Because of time constraints, I was given a very loose, high-level direction in the form of a statement of work (SOW) and told to create wires. As a result, I have to essentially pull the site layout, structure and interactions out of the least attractive portion of my person.
The process goes a little something like this
- I create wires and specifications,
- The team reviews and we all make recommendations for change.
- I then make the changes as the other project members revise and refine the vision and concept for the site we’re building.
- We then all sit down for another round of review/refinement.
While It’s not what I would prefer, I do see allot of good that can come out of doing things this way.
Personas - I’ve seen the light!
When I first started working in user-centered design in 2003, one method that I had a really hard time seeing the value of was the creation, maintenance and regular use of personas. After nearly 4 years, I believe I have finally seen the light.
My eyes began to be opened in November of 2006 when a client project I was working on required me to review some personas which were created prior ot my joining the project. The goal in reviewing the personas was to identify the primary target audience for a new online multimedia studio.
As I reviewed the personas I began to quickly see who would be most likely to engage in this type of tool. I also saw quite clearly which persona would not engage the tool at all. Based on this research I made my recommendations to the project team and we began designing the site that would advertise the tool. During the design phase the client was very uncomfortable limiting the focus of the site to one primary and 1 secondary persona as this approach seemed it might lead to certain personas feeling left out.
The team and I acquiesced and began efforts to design the site geared toward 4 total personas (out of cast of 6). However, while moving forward with our new target, our efforts produced (in my opinion) a very un-engaging user experience. As fate would have it, the client scrapped the project so our site never came to fruition.
This experience left me with the first of many positive persona experiences. I found that I really had a clearer vision of what would and would not work with the site because I felt like I understood who would be using it. It wasn’t until just this past week that I realized why our design efforts went so far south.
In reading chapter 5 of “About Face 2.0 – The Essentials of User Interface Design” the authors (Cooper & Reimann) helped me realize that in trying to design for more than a single primary persona and 1-2 secondary personas, we were effectively “…trying to accomplish too much” (pg 72).
This insight, along with several others contained in the book, have convinced me to become a stronger advocate for the creation, maintenance, and incorporation of personas in future projects.
Implicit Requirements
Over the last year, I've noticed an interesting benefit of interaction design. By overtly building interaction design into the project lifecycle, not only can a project team ensure a more useful and usable product, but also, interaction design can draw out what I've come call "implicit requirements".
What are implicit requirements?Implicit requirements are un-documented or otherwise un-thought-of specifications that can be distilled through employing various methods of user-centered design such as user & task flows, wireframing, prototyping, and user testing.
By drawing out implicit requirements, developers, designers and other project stakeholders clarify and refine requirements and build more robust and scalable applications/sites.
An exampleWhile working on a project to completely overhaul the virtual library for an online university, I was given sets of both functional and business requirements. In order to effectively translate these requirements into an interface, I began creating task flows and wireframes.
These activities screeched to a halt when I discovered that certain features and pieces of functionality could not be implemented unless the assumptions inherent in each was drawn out and documented. I brought these items to the attention of the project team to their delight (as a side note one of my favorite things to hear is “I never thought of that”).
As a result, changes were made to the site documentation and ultimately impacted the user experience one the new library went live.
I still don’t get it.To show you what I mean, I have provided a generic example. Say the business owners tell the developer and the interaction designer that they wanted feature “X”. The developer captures this requirement in her/his functional specification, the Interaction designer (me) begins the process of creating an interface through a variety of methods.
During this phase, the interaction designer realizes that the presence of feature “X” seems to assume the presence of otherwise undocumented feature “A”, business rules “Q” thorough “T” and could go one of 3 directions according to the flexibility of the technology platform.
These last items all fall into the definition of implicit requirements. The project team now has the opportunity of addressing these assumptions before any coding begins and is more likely to provide their a better experience.
Conclusion
Implicit requirements are like gold when it comes to what we do as user-centered professionals. It’s one major way we can justify (and even quantify) the need for user-centered design.
By drawing out and documenting these implicit requirements, developers, designers and other project stakeholders can then clarify and refine requirements and build more robust and scalable applications/sites.
