Wireframes and Use Cases

20 Jan 2004 - 9:27am
10 years ago
4 replies
2752 reads
FelcanSmith, Mark
2004

I'm working with systems analysts who are familiar with use
cases and only recently have been introduced to wireframes. They
are used to receiving business requirements and then developing
use cases out of those.

There is some debate on when is the appropriate time to
introduce wireframes into the process. My reponse was, it
depends on the project. For example, let's say that the project
is going to require wireframe development, is there a best
practice out there regarding when to bring them into the mix?
The process they are used to working with is:
Bus Req > Use Cases > Design > Develop > Deploy

Thanks,
Mark

Comments

20 Jan 2004 - 10:16am
Peter Boersma
2003

Mark FelcanSith asked:
> The process they are used to working with is:
> Bus Req > Use Cases > Design > Develop > Deploy

I'd say there are several streams that lead up to "> Design":

Bus Req > Use Cases
Usability Req > Interaction Concept
Branding Req > Moodboards
Technical Req > Software Architecture
QA Reqs > QA plan
etc.

Oh, and I hope there's a feedback loop, something like:
(warning: ASCII-art approaching)

----> Design > Evaluate ---->
^ |
|-----------<------------v

Peter
--
Peter Boersma, Senior Information Architect, EzGov
"De Schinkel", Rijnsburgstraat 11, Amsterdam, 1059 AT, The Netherlands
Phone: +31(0)20 7133881 / Fax: +31(0)20 7133799 / Mobile: +31(0)6 15072747
mailto:peter.boersma at ezgov.com / http://www.europe.ezgov.com

20 Jan 2004 - 1:26pm
Coryndon Luxmoore
2004

Mark FelcanSith asked:
> The process they are used to working with is:
> Bus Req > Use Cases > Design > Develop > Deploy

Mark,
One can debate ad-nauseam about the appropriate time to do this before of
after use cases. What I have found is that the earlier you can do wireframes
the better at the very least you should do them in parallel with the use
cases.

The trouble with use cases is that business owners who understand the
business rules will rarely read or understand the use cases. However, if you
put a screen in front of them and a draft set of behaviors they will quickly
understand what the system is doing. Doing this as early as possible is one
way to prevent sudden and dramatic changes in business requirements later on
down the road.

I have also found that the tech folks find it useful to have a draft set of
screens as they write use cases to validate information and process sequence
against.

Finally, your screens can also drive requirements (and new use cases) out
that will impact the technical design especially if you are conducting any
sort of user testing (this is also very important to do before finalizing
any tech requirements.)

If you are getting resistance to doing this early it may be due to a
perception on the tech side of the finality of wireframes. Emphasize the
iterative nature of wireframes and set the completion of them at the same
point of after the tech design.

--Coryndon

20 Jan 2004 - 5:02pm
Wendy Fischer
2004

I am going through this right now.

The "use cases" were already done and put in the
Marketing Requirements Document but they weren't true
use cases. I have started designing the concept
wireframes for a client software product. Because we
designing for a complex data information system that
solves problems from a complex technical backend, and
not everybody completely understand the subject
matter, I am finding that the wireframes are serving
several purposes:

1) They are allowing team members to conceptually
understand the system, the task flow and the subject
matter. I would say that only 2 or 3 people on the
team completely understand the subject matter and
system that we are designing the tool for. I find that
I can explain the UI but because I am new to the
subject matter (which is very technical) it is
difficult for me to explain things or answer questions
out of the scope of the UI.

2) Spur discussion around requirements and use cases
While there were "use cases" in the Marketing
requirements document, they were high level use cases
and only dealt with features, and not implementation,
integration with other products, system and user
conceptual models and implemenation. Engineering
currently does not have use cases and certain key
conceptual ideas were not defined. The wireframes are
forcing engineering and marketing to look at the flow
and take a step backward and define use cases and
conceptual models that weren't already defined.
Several of these things should have been defined
several months ago but weren't.

3) Spur discussion around technological implementation
We are building this tool on an eclipse platform. We
have a team made of server engineers who are
transforming themselves into gui engineers. They are
learning the Eclipse tool and starting to prototype.
We get discussion around what is possible/impossible
and ideal to implement.

-Wendy Fischer
--- Mark FelcanSmith <mfs at ureach.com> wrote:
> I'm working with systems analysts who are familiar
> with use
> cases and only recently have been introduced to
> wireframes. They
> are used to receiving business requirements and then
> developing
> use cases out of those.
>
> There is some debate on when is the appropriate time
> to
> introduce wireframes into the process. My reponse
> was, it
> depends on the project. For example, let's say that
> the project
> is going to require wireframe development, is there
> a best
> practice out there regarding when to bring them into
> the mix?
> The process they are used to working with is:
> Bus Req > Use Cases > Design > Develop > Deploy
>
>
> Thanks,
> Mark
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at interactiondesigners.com
> --
> to change your options (unsubscribe or set digest):
> http://discuss.interactiondesigners.com
> --
> Questions: lists at interactiondesigners.com
> --
> Announcement Online List (discussion list members
> get announcements already)
> http://interactiondesigners.com/announceList/
> --
> http://interactiondesigners.com/

=====
Test 123 test 123

21 Jan 2004 - 6:22pm
Danny Bluestone
2003

Wendy

Its been interesting reading your email and I am not 100% fammiliar with your specific project but would like to ask you one question regarding point number 3 in your email. Is it not better for an Interaction Designer with User Centric Interface Design (and Backend understanding) skills to prototype the GUI rather than Server engineers?

Cheers
Danny Bluestone
Interaction Designer
Cyber-Duck Ltd, UK

Wendy Fischer <erpdesigner at yahoo.com> wrote:
I am going through this right now.

The "use cases" were already done and put in the
Marketing Requirements Document but they weren't true
use cases. I have started designing the concept
wireframes for a client software product. Because we
designing for a complex data information system that
solves problems from a complex technical backend, and
not everybody completely understand the subject
matter, I am finding that the wireframes are serving
several purposes:

1) They are allowing team members to conceptually
understand the system, the task flow and the subject
matter. I would say that only 2 or 3 people on the
team completely understand the subject matter and
system that we are designing the tool for. I find that
I can explain the UI but because I am new to the
subject matter (which is very technical) it is
difficult for me to explain things or answer questions
out of the scope of the UI.

2) Spur discussion around requirements and use cases
While there were "use cases" in the Marketing
requirements document, they were high level use cases
and only dealt with features, and not implementation,
integration with other products, system and user
conceptual models and implemenation. Engineering
currently does not have use cases and certain key
conceptual ideas were not defined. The wireframes are
forcing engineering and marketing to look at the flow
and take a step backward and define use cases and
conceptual models that weren't already defined.
Several of these things should have been defined
several months ago but weren't.

3) Spur discussion around technological implementation
We are building this tool on an eclipse platform. We
have a team made of server engineers who are
transforming themselves into gui engineers. They are
learning the Eclipse tool and starting to prototype.
We get discussion around what is possible/impossible
and ideal to implement.

-Wendy Fischer
--- Mark FelcanSmith wrote:
> I'm working with systems analysts who are familiar
> with use
> cases and only recently have been introduced to
> wireframes. They
> are used to receiving business requirements and then
> developing
> use cases out of those.
>
> There is some debate on when is the appropriate time
> to
> introduce wireframes into the process. My reponse
> was, it
> depends on the project. For example, let's say that
> the project
> is going to require wireframe development, is there
> a best
> practice out there regarding when to bring them into
> the mix?
> The process they are used to working with is:
> Bus Req > Use Cases > Design > Develop > Deploy
>
>
> Thanks,
> Mark
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at interactiondesigners.com
> --
> to change your options (unsubscribe or set digest):
> http://discuss.interactiondesigners.com
> --
> Questions: lists at interactiondesigners.com
> --
> Announcement Online List (discussion list members
> get announcements already)
> http://interactiondesigners.com/announceList/
> --
> http://interactiondesigners.com/

=====
Test 123 test 123
_______________________________________________
Interaction Design Discussion List
discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest): http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

---------------------------------
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.interactiondesigners.com/private.cgi/discuss-interactiondesigners.com/attachments/20040121/9f6f7e56/attachment.html

Syndicate content Get the feed