Today I want to share with you my approach for using UI mock ups in an Agile project.

As a Business Analyst, I started using powerful mockup tools, such as AXURE and Balsamiq, when I was still asked to produce complete upfront documentation. I used to create detailed wireframes of User Interface and accompany each of them with a specification table with description of every item.

When I started to be involved in Agile projects, I wondered which was the best approach to use mock ups in supporting the development cycle.

Let’s take as an example a design of an hypothetical intranet page that offer the staff:

–     A list of all staff members in the organisation (with a photo, their names, department and role and contact details)

–     The possibility to email them directly

–     The possibility to see their LinkedIn profile

–     A search feature that allow filtering results for Name, Last Name and Department.

Blog1 simple Image

Creating this simple mock up in Axure is useful for confirming the design with the users before starting the developing phase, but also for splitting the design elements in user stories (or epics) and prioritise them in the iteration cycle.

When the design is agreed, I then break it up in smaller chunks that can be delivered individually, in several iterations, for example:

1-     The boxes with employees name, last name, role & department and contact information

2-     A photo of each employee

3-     An <email now> icon that allow the user to send an instant email to the contact.

4-     A “search” functionality, that allow user to reduce the display of records in the page filtering for last name, name or department.

Now you can link a user story to each chunk of the mockup, estimate the effort for implementation of each of them (story point) and prioritise them according to their business value.

Mockup can be linked to User Stories as attachments or embedded images (for example in Team Foundation Server or JIRA). My choice is to attach the entire wireframe to each of the related user stories, but highlighting the component that apply to the specific Story. In addition, I indicate on the mockup itself the User Story number of each component.


User Story 111: As a user of the organisation’s intranet, I can visualise a page with all the other staff members of my organisation, their name, last name, role in the organisation, department and contact details.

User Story 112: As a user of the organisation’s intranet I can see a photo next to each staff member’s name so that I can associate the name with a face.

User Story 113: As a user of the organisation’s intranet, I can click on the email icon underneath each staff member to email them directly.

User Story 114: As a user of the organisation’s intranet I can filter the result of the team page for first name, last name or department, so that only the records I am interested in will be displayed.

User Story 115: As a user of the organisation’s intranet, I can click on the LinkedIn icon underneath each staff member to be redirected on their LinkedIn profile.

If you estimate every user story in development effort (story points or story size), the wireframe can help the product owner visualise the impact of each component and make better cost-benefits decisions.

Leave a Comment

Your email address will not be published. Required fields are marked *