Prototyping with Adobe XD and Angular Material

Prototyping with Adobe XD and Angular Material

This is one of a series of posts detailing the process of building an application with Angular, Visual Studio, ASP.NET Core, and Azure. See the complete list of posts here.

This is a summary of decisions made and lessons learned while creating this prototype:

  • Adobe XD is free during the beta period and provides both wireframing and prototyping capabilities
  • Adobe XD comes with a set of Material Design Assets with which to build prototypes
  • Prototyping helps developers understand design considerations before potentially coding themselves into a corner
  • The Material Design assets provided by Adobe XD must be modified in some cases to match what Angular Material provides
  • Prototyping is a great way to start understanding Material Design for those who have never used it

Why Adobe XD?

When designing an application from scratch, it's tempting for developers to dive right into code. However, this often leads to dead ends and rework. Going through the process of wireframing and prototyping helps to understand design problems before investing in their development.

Wireframing is laying out the screens and UI elements. Prototyping is organizing the transitions or flows between these screens and states. Drawing on paper is a low-barrier method to wireframe and prototype. I have done this but I tend to miss the ability to copy and paste repeated UI. There are many software tools that do only wireframing OR prototyping but a much smaller selection accomplish both tasks. One of these applications is Adobe's relatively new Experience Design (XD) product.

There are several reasons I chose to use Adobe XD for this exercise. First, it's made by Adobe which is synonymous with 'professional design tools' and I can assume there is a large base of users from which to find examples, training, and support. Second, Adobe XD is currently free during the beta period. Adobe's Creative Cloud, while exceedingly capable, is arguably expensive at around $50 per month with an annual commitment. Not doing a lot of design work, it becomes difficult to justify this expense. When it's free, however, why not try it? Finally, Adobe XD comes out of the box with Material Design elements (and others) that I leveraged to make my prototype.

To get started, Adobe XD has a built-in tutorial. This was enough to orient me to the major features. However, you can read more about Adobe XD here.

Why Angular Material?

Why choose Angular Material? To start, I wanted to use an existing design language. My main skill is development and so I wanted to leverage existing design work to get my application off the ground as quickly as possible. Material design is a design language based off a set of patterns and principles. Frameworks have adapted these patterns to existing technologies. Angular Material, for instance, has adapted Material Design for Angular.

Angular Material is a set of Angular components built to fit the Material Design language. In addition, Angular Material represents some of the best thinking on how to implement UI component libraries for Angular-based applications. By using this library, I expect to better understand best practices for creating my own re-usable UI components.

Finally, I think Material Design looks good. I find applications built with Material Design to be useable and feel playful. However, I don't know much about it. I don't use many Google applications regularly. By creating a prototype, I can research how these UI components are combined to create an application.

Take the playful aesthetics and combine this with pre-built components, design principles, and prototyping support, and the choice to use Angular Material and Adobe XD makes sense.

Wireframing

Adobe XD offers sets of Material Design, iOS, and Windows assets called UI Kits. When selecting a UI Kit from the menu, Adobe XD opens a new window with a project containing all the assets. From there, you can copy and paste the assets you want to use in your own project.

To start, I copied a view of the Safari browser from the iOS UI Kit. This helps ground the fact that this application will be running in a browser. Next, I opened the Material UI Kit. These assets are designed to mimic native Android apps. To adapt the assets to Angular Material, I opened the Angular Material web site side-by-side with the Angular Material UI KIt. I adapted the existing assets to match what was available in Angular Material. For instance, I combined a text input and menu to recreate the Angular Material select component.

This is what the Material UI Kit gives you out of the box:

Adobe XD Material UI Kit Input

Adobe XD Material UI Kit Menu

This is my own composite to roughly match the Angular Material select:

Angular Material select component

The first screen, referred to as an artboard, takes the most time to create. From there, you can duplicate screens and modify them to wireframe the rest of the application more quickly.

Duplicate artboards worfklow

I didn't spend a lot of time on the initial design, enough to get acquainted with the tool and create the first set of interactions. You can see the current state of the prototype here. Also, visit the Adobe XD documentation to learn more about the program's features.

This is the full set of initial artboards.

Initial application artboards

Prototyping

After the artboards are created, Adobe XD makes it easy to prototype interactions by linking artboards together with transitions.

Adobe XD transitions

Simply select the element that triggers the transition and link it to the target artboard representing the new state.

Adobe XD link transitions

Once all the artboards are linked, you can 'play' the prototype. When in this mode, the artboards are not editable. The user clicks the onscreen elements and Adobe XD displays the linked artboard with the selected transition. This allows the user to get a feel for how the application behaves.

Adobe XD Transition Animation

I almost skipped creating a prototype because I already had an idea of how the screens would flow together. However, the process to create the prototype took very little time and it was somewhat gratifying to see the prototype 'working' even if in a rudimentary state.

Especially if designing this application for other users than myself, the prototype would allow me to perform usability testing. The testing would provide valuable design feedback to incorporate before investing in development effort.

Takeaways

Not being very familiar with Material Design, I had a chance to research how the Angular Material components fit together in an application. Furthermore, I became better acquainted with the various components that Angular Material offers.

I found Adobe XD to be a very capable tool and will consider using it for other application ideas going forward. It was easy to get started and I could become more efficient using the tool with more experience.

I look forward to seeing how Adobe XD evolves overtime and using it more in the future. Have you given it a try? Leave a comment below sharing your experience.

Sprint Planning in Visual Studio Team Services

Sprint Planning in VSTS

Derived from photo by Dafne Cholet / flickr.com, CC BY

Getting started in Visual Studio Team Services (VSTS) eventually leads to planning a sprint. This post discusses how to configure a sprint in VSTS and schedule work for this iteration.

This is one of a series of posts detailing the process of building an application with Angular, Visual Studio, ASP.NET Core, and Azure. See the complete list of posts here.

This is a summary of decisions made and lessons learned while creating this project in Visual Studio Team Services (VSTS):

  • Chose two weeks for the initial sprint duration and because I am a team of one, I may have varying sprint durations in the future to fit my schedule. While VSTS supports varying sprint durations, teams generally operate better with a consistent schedule.
  • Set the sprint capacity to later compare to scheduled work. Although VSTS capacity is set per day in hours, this number can be calculated from week-based or sprint-based capacity estimations.
  • Estimated backlog items using a modified Fibonacci sequence, roughly based on hours to start but will be used to comparatively size future product backlog items.
  • Estimated tasks in hours and added the Original estimate and Completed work fields to the task work item template for tracking this information as well.
  • Verified the scheduled work against the configured capacity and adjusted the scheduled work to fit the sprint capacity.

Configure the Sprint

The first thing to determine is the duration of sprints. If working on a large team, predictable sprint durations are helpful to keep everyone on the same page. However, for a project with one developer, I am going to determine sprints more on my own availability. I have been working recently in two-week increments, but alternating these iterations between code-related projects and other personal projects. So, while I may have a sprint that lasts two weeks, I may not schedule the next sprint until two weeks after the end of the previous. Also, I try to squeeze in a "week off" to my schedule occasionally where I try not to focus on achievement but rather rest and spend time with friends and family. The point is that while large teams may benefit from predictable sprint durations, Visual Studio Team Services allows for flexible durations if that works better for you and your team.

To set the dates, go to the Work section of the team project. VSTS provides a default list of iterations named Sprint 1, Sprint 2, etc. Choose Sprint 1 to view the page for that iteration. Look towards the top right of the screen and you will see a link to Set dates. Click that link and this dialog appears:

Edit iteration dialog

Set the start and end date for the sprint. Optionally, change the sprint name. I decided to go with sprint names that correspond to famous jazz musicians of the bebop era. Press Save and close to save the sprint.

Tip: The Iteration settings are also available from the Settings menu in the top navigation. Select Work, then Iterations to modify the full iteration list.

Full iteration list

Set Capacity

Capacity is another tool for scheduling work. By setting the capacity for people working on the project (even if only yourself), it helps determine if the team is committing to too much or too little work for the sprint. The VSTS sprint burndown chart also uses this number to visualize progress.

The first step is to determine how many hours per day or week everyone can commit to the project. I have roughly 14 hours per week to devote during this sprint. On the page for the current sprint, select the Capacity tab:

Capacity tab

Enter the capacity per day. Since I can do 14 hours per week, I entered in 2 hours per day. This field allows for decimals to accommodate the daily number for any week-based or sprint-based capacity estimations. For instance, if a teammate could only work 20 hours for the entire sprint, divide 20 hours by the number of days in the sprint (14) to arrive at a daily capacity of 1.43.

By default, VSTS does not count weekends as working days. Being a personal project, the weekends are prime time for getting things done so I wanted them to count towards the capacity. To enable them, click on the gear/settings icon in the top right of the team's work page and then find the settings for Working days. Enable the checkboxes for those days to include them in the capacity.

Working days settings

Estimate Product Backlog Items and Tasks

To improve my estimation skills, I'm estimating my work in VSTS. This isn't entirely necessary but I find tracking this over time leads to a better understanding of what can be accomplished in each sprint. I use two different estimation systems for product backlog items and tasks.

For product backlog items, I like using a modified Fibonacci sequence like what's found on a planning poker deck. The modified sequence progresses as 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, etc. The product backlog item estimates do not reflect hours, but are sized relative to each other. I happen to use hours as a baseline when starting out. For instance, because this is my first sprint and first estimates, the three backlog items estimated equal 24 (8 each). This is roughly equivalent to my sprint capacity which is 28. This can be confusing for some because the units of measure are close (sizing versus hours) but not the same. I like having that loose association but I must remember that when estimating backlog items, I'm thinking about how they compare to other backlog items, not how many hours they will take. For instance, if I start thinking that a backlog item is 10 hours, I would force myself to estimate it as either an 8 meaning that it is roughly equivalent to the amount of work done for a complete product backlog item or I would decide that it is indeed larger and estimate at 13 which is the next largest number in the modified Fibonacci sequence.

Once the backlog items have been estimated, choose one or more for the sprint backlog by setting the sprint property in the product backlog item itself. I decided to take one product backlog item off my product backlog and added two new ones to the sprint and estimated them. The two new backlog items represent blog posts discussing the project work.

Once I have the backlog items that I think I can accomplish during the sprint, I start to break them down into tasks. These tasks are estimated in hours which will be matched to the sprint capacity. By default, the scrum process template in VSTS gives one field for task estimation, Remaining Work. This field is used to calculate the burndown chart as the sprint progresses. I decided to also add the Original estimate and Completed work fields to my task work items to get a better understanding of how well (or not) I estimate a task. These fields already exist in VSTS and simply need to be added to the work item template. This documentation provides details on customizing work items. Be sure to assign each task to yourself or the person scheduled to implement the work during the sprint. Look at the board view for the sprint and this is how each backlog item appears:

Product Backlog Item on Kanban board

One final thing to do before finalizing the sprint plan is to check the capacity screen one more time. On the right-hand side, there are bullet graphs representing each team member's capacity and the amount of work scheduled for them. If the bars are green, you are good to go. If they are red, it means an individual has more estimated work than capacity and you should consider adjusting the workload.

Capacity Screen

Get to Work

Now it's time to get started working through the sprint backlog. Use the Kanban board to easily visualize the sprint work. As work is accomplished, update each task with the time remaining and time completed.

Finally, refer to the sprint burndown chart to see if you are on track to reach your goals. Happy coding!