Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Usability and U...   User interfaces & usability specs
Previous Previous
 
Next Next
New Post 4/18/2008 10:37 AM
User is offline Tiffany
3 posts
No Ranking


Re: User interfaces & usability specs 

I, too, defintely agree with Chris and Adrian.  If there is an experience UI or UX designer then let them go for it...that is their specialty.  However, if one is not available then I think a BA and BSA should do UI mockups.  Mockups are not set in stone and this needs to be related to developers so they know that is simply a guideline to give ideas.  I have ran into too many BAs who will not do UI mockups when there is not an UI (or UX) designer simply because they state it is not their job.  I think this is laziness and it actually hurts the business owner.  I truly believe that BAs should know some degree on how to create mockups for UIs.  I have also found that with some of the BAs I have worked with lately not collaborating with the development team.  I just cringe when this happens.  Our job as BAs and BSAs is to collaborate with various groups and people. 

To reiterate what Adrian stated, I think if a BA does not have UI experience then try to get training or work with people you know to help you with learning how to do UI mockups.  I would also recommend to understand and learn the analysis with eye movement, hand movement, wording, etc. since these are all critical aspects to understand when creating a mockup and useability.  It also can increase the time an end user takes to do a job function or it can decrease the time.  Once a mockup is completed, then I would meet with the business owners to discuss the layout, clarity, and color of the UI.

 
New Post 4/19/2010 6:57 AM
User is offline pietro
2 posts
No Ranking


Re: User interfaces & usability specs 

 Hi,

I've been purely  UI and UX designer before, but now i do mainly business analyst assignments with UX twist. Neither BA or programmer will know how to do usable UI without studying the field a bit, but it's not too difficult.

To answer you original question, I must answer as a true consultant... It depends :-)

There has been a few good suggestions and comments. Firstly, it's true that you should separate overall functionality from UI, but only to certain extent. I'll try to demonstrate it by example. Ok, if you are selecting a COTS package it's essential to have business, user and functional requirements separated from UI. This is because you are selecting package based on capability, not because of it's UI. You do have to make evaluation of UI and include only feasible options to your shortlist (i.e. those which don't look overly complicated wiht gazillion modal windows etc). You can and should have requirements about UI and it's usability. "1. Customer information entry must be presented in one screen. 2. It must support using without mouse. 3. Entering new customer should not take more than xx seconds."

When making requirements about UI, you must think about how each UI requirements supports high-level requirements. Good UI can be very effective way to increase work efficiency!

When building custom applications or products or services that will be sold to customers, it's not so clear that you should develop functional requirements, use cases and UIs separately. Example: Functional requirements for iphone and non-touch UI phone would be pretty much similar to certain point. Only the exceptional UI of iPhone was the business requirements that delivered a) best user experience b) differentiation in markets. But there's a catch here. Be aware what is you projects' goal. If you are creating a some generic business application, there probably is no justification to build a totally customized UI. Those would require that it affects strategical, business and mission critical functions of organization in question. 

One special thing about UI is that it brings together and validates

  • Information model (what data, values must be available at any given time? How they will relate to each other in UI and ER model?)
  • Functional requirement (does UI allow user to complete task that fills a business goal?)
  • Some non-functional requirements (how effective UI is? is it usable by color blind? etc)
  • One more related thing to understand is, that some requirements /UI features will bring any value only if set of other requirements will be also done in same release. E.g. no point in implementing map-UI, if none of location features are present in same release. So, UI can help in scoping, not only scope creep...

 

One good piece of advice was to think about these things in generic tems/ flow to identify what information needs to be present at the same time. Depending on organization, you can be facing a situation where none of the customers understands data model and can't validate the structure for you. But when you show them UI sketches, they will know what they want!

What this means in practice? When application is bespoke i can create fast mockup screens based on initial requirements. When client is happy with screens and flow based on above criteria, i can break down the mockups into generic requirements. 

You can attach the UI skteches in your requirements documents with comment, "Illustration of one possible way to satisfy requirement BR123". This gives potential vendors much better understanding of client expectations about functionality. For example, compare following requirements.

1. User can enter text and format it before publishing (no UI image)

2. User can enter text and format it before publishing with following functionality: Bold; Italic; Font type; font size; ... (etc for total of about 60 formatting options, no UI image)

3. User can enter text and format it before publishing with UI offering capability similar to UI123 (attached image UI123 of web-based wysiwyg editing component)

Which of the above requirements is least unambiguous? For which of them it would be easiest to give an accurate work estimate? Which of them would be most meaningful as a backlog item for scrum team and would need least amount of non-reusable documentation? 

Then again, for COTS package selection, you should have it as a written requirements - "Solution has a wysiwyg editor for formatting forum posts."

I am not sure if this helped or confused more.

Petteri

 

 
New Post 4/19/2010 5:31 PM
User is offline Kimbo
454 posts
5th Level Poster


Re: User interfaces & usability specs 

Hmm Petteri,

It seems you are advocating skipping functional analysis (use cases) and going straight to a UI design? If that is the case I have to disagree with you. 1 use case does not equal 1 screen. It is a many to many relationship. I think if a BA goes down this road they will miss functionality. Trap for young players here. Don't do it!!

One other comment about UI prototyping in previous posts. Someone, not necessarily the BA but us by default, should create a UI standards type document that specifies the look and feel and usability of each screen. e.g. Title is 14 point, bold, centred, blue, logo on left of title, submit button always means finish transaction and return to menu, no horizontal scrolling permitted, error messages highlight fields and appear next to field in error, etc, etc. It means that each screen has a chance of looking the same and a button with a certain name always behaves the same on every screen. Then when you give the prototype to a group of developers, they should create screens that look the same and behave the same.

Kimbo

 
New Post 4/20/2010 8:05 AM
User is offline pietro
2 posts
No Ranking


Re: User interfaces & usability specs 

Hi, Kimbo

No, that is not the case, i didn't mean to do that. Good you raised the point. You still need to do functional analysis to identify necessary use cases and to identify goals etc. In era of AJAX interfaces and business using complex applications, some functionality is easier to discuss through prototypes. On the other hand, some functionality is nearly impossible to specify through prototypes.

So, to enforce what Kimbo wrote and to clarify my original message

-Analyse needed functionality to ensure you have covered it all (for example, important security related functionality will not be visible in UI so using only prototype can cause you to miss these)
-Prototypes and Use Cases must go hand in hand.
-Some "use cases" are easier to work through UI prototypes once you have agreed on user goal (one picture does say more than 1000 words). You still need to support prototype with written specification which refers to prototype or screens
-Relationship between use case and screen is not 1-to-1, it's often 1-to-many and sometimes even many-to-many. I.e. one screen or screen component (=compartment)  can be used by many use cases. Say...hmmm... map interface, selection patterns etc. Only their content varies, not how it's presented. (that relates to style guides and UI standards)

In most cases UI prototype gives better idea of targeted approach and quality of functionality and helps in getting more accurate quotes or estimates. Same use case with quick and dirty form-entry interface without client side error handling and interaction is much easier to implement than UI with AJAX, browser-side value checking etc. Difference can be 5 fold. 

Some of our internal tests have shown that prototyping can decrease change requests during implementation by 70 - 80%. We have been using use cases for very long time and this has been a huge improvement. Approach requires a good team with BA/ Analyst, UI design and usability skills. I do recommend that you take an open-minded look at using ui prototypes to replace fully-dressed, detailed use cases in later design phase. It probably will save you time, ensure better quality and facilitates understanding between different parties.

As all models, it is just an aid, not the only way.

Petteri

 

 
New Post 12/29/2014 2:16 AM
User is offline SAQIB AZIZ
6 posts
10th Level Poster


Re: User interfaces & usability specs 
At first created a draft version of a product, i.e. a prototype, which enables to measure the product’s efficiency prior to proceeding with functionality issues and finalization of the project. 

The prototype development calls for much smaller investments, than a website development. The prototype testing helps to identify the optimal options in terms of the future website’s functionality. Besides, such testing helps to reduce expenses and the period of the website engineering, thus preventing the company from wasting time and money for inefficient website without relevant functionality. 

Engineering and design of user interface comprises the following stages (the list might be either reduced or extended, depending on the project goals): 

  • preparation of the document “User Interface Specification” outlining standards of the structural, compositional and visual design of the product taking into account recommendations based on the usability testing results
  • revision of the prototype relying on recommendations based on usability testing

 

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Usability and U...   User interfaces & usability specs

Community Blog - Latest Posts

Fabricio Laguna talks Business Analysis and AI
I recently connected with Fabricio Laguna, aka The Brazilian BA. Fabricio is a passionate and pioneering business analyst from Brazil. During our conversation, we had a thought-provoking discussion on how artificial intelligence stands to shape the field of business analysis in the years ahead. While AI promises to transform many aspects of busines...
Business Architecture, Ontology and More with Terry Roach
It's been a privilege meeting Terry Roach, a visionary in the field of enterprise architecture and business architecture. Terry's insights into the evolution of business models, the importance of ontology in architecture, and the potential of AI to shape our future were not only thought-provoking but also a reflection of his extensive exper...
Today I had the pleasure of chatting to Jignesh Jamnadas, Chief Operations Officer at Mosaic, about his Blueprints for Success. As a Senior Finance and Operations Executive, Jigs (as he is known to many) has a holistic understanding of all facets of business and a flair for managing both people and processes. Having worked with Jigs, I was struc...

 



Upcoming Live Webinars




 

Copyright 2006-2024 by Modern Analyst Media LLC