K.C. Jones-Evans, a User Experience Developer, Josh Lathery, a Full Stack Developer, and Sara Darrah, a User Experience Specialist, sat down recently to talk through our design and project development planning process that we implemented for part of a project. This exercise was to help improve our overall project development planning and create best practices moving forward. We coined the term the “Design Huddle” to describe the process of taking the feature from a high level (often one sentence request from our customer) to a working product in our software, improving project planning for software development.

We started the design huddle because the contract we were working on already had a software process that did not include User Experience (UX). We knew we needed to include UX, but weren’t sure how it would work given the fast paced (2-week sprint cycles) software process we were contractually obligated to follow. We needed to come up with a software design planning solution that allowed us to work efficiently and cohesively. The Design Huddle allowed us to do just that.

What does the design huddle mean to you?

Josh: Previously the technical lead would have all the design processes worked out prior to being assigned a ticket for development. The huddle meant that I had more ownership in the feature upfront. It was nice to understand via the design process what the product would be used for and why.

K.C.: The huddle was an opportunity to get our thoughts together on the full product before diving into development right away. In the past, we have developed too quickly and discovered major issues. Development early equated to too much ownership in the code, so changes were painful when something needed to be corrected.

Sara: The huddle for me meant the opportunity to meet with the developers early to get on the same page prior to development. That way when we had the final product, we could discuss details and make changes, but we were coming from the same starting point. I have been on other projects where I’m not brought in until after the development is finished- which

immediately strains the relationship between UX and Development due to big changes needed to finished code.

What does the design huddle look like?

  • The Team: UX Designer, at least one front-end or UX developer, a full-stack developer, the software tester, a graphic designer (as needed), and a Subject Matter Experts (as needed)
  • The Meeting: This took time to work out. As with any group, sometimes there were louder or more passionate individuals that seemed to overshadow the rest. At the end of the day the group worked better with order and consensus:
    • Agendas were key: The UX lead created the agendas for our meetings. Without an agenda it was too easy to go down a rabbit hole of code details. This also helped folks who were spread across multiple projects focus on the task at hand faster. We included time to report on action items, old business/review of any design items and set the stage of what you hope to cover as new design work.
    • Action Items: Create and assign actions to maintain in the task management system (JIRA). This was a good translation for developers and helped everyone understand their responsibility leaving the room. These also really helped with sprint planning and the ability to scope tasking.
    • The facilitator had to be assertive: Yes, we are all professionals and in the ideal world we could “King Arthur Round Table” these huddles. But the few times we tried this meeting were quickly off-track and down a rabbit hole. Many teammates would leave frustrated and feeling like we hadn’t made any progress. The facilitator was the UX specialist for our meetings, but we think the owner of the feature should facilitate. The facilitator needs to be willing to assert themselves during conversations, keep the meeting on track and force topics to be tabled for another time when needed.
    • Include everyone and know the crowd: The facilitator needs to quickly understand the team they are working with to figure out how to include everyone. One way we ensured this happen was to do an around the room at the end of each meeting.
    • Visual Aid that the whole team can see during the meeting: Choose the tool that works best for the topic at hand- a dry erase board, a wireframe, JIRA tickets, or a mock-up can help people stay on track and ensure common understanding.
    • Table tough items and know when to end the meeting: sometimes in the larger meetings we needed to call it quits on a debate to give more time for thinking, research, and discussions. Any member of the team could ask for something to be tabled. A tabled item was given a smaller group of individuals to work through the details in between the regular design huddle sessions.
    • Choose the team participants wisely: The first few meetings most likely will involve the entire team, but smaller huddles (team of 2 or 3) can often work through details of tabled items more efficiently.

What is the benefit?

  • Everyone felt ownership in the product by the end of the design. Sara’s favorite thing about this learning experience was when one of the developers I hadn’t worked with before said he loved the process. He had the opportunity to provide input early and often, and then by the time development started there weren’t really any questions left on how to implement. Josh- the process helped me feel like an engineer and not just a code monkey. K.C.-: In other projects, we have been handed mock-ups without context. This process helped the “gray area” be taken away.
  • Developers were able to tame the ideals of the UX designer by understanding the system, not just the User Interface. Developers could assist UX by asking questions, helping understand the existing system limitations, and raising concerns that the design solution was too complicated given the time we had.
  • The software tester was able to understand the flow of the new designs, ask questions and assist in writing acceptance criteria that was specific, measurable, attainable, realistic and testable (SMART).
  • She provided guidance when we needed to go from concept to reality and ensured we understood the design requirements.
  • It was critical to designing 1-2 sprints in front of expected development as part of Agile software development. It allowed for the best design to be used rather than forcing ourselves into something that could be completed in two weeks. Together we would know what our end goal was, then break down the concept into tiers. Each tier would have a viable product that was one sprint long, and always kept the end product design in mind.

The Design Huddle is a way for teams to collaborate early on a new feature or application. We feel it is a great way to work User Experience into the Agile software process and simplify project development planning. We have taken our lessons learned and applied to a new project the three of us are getting to tackle together and expanded the concept of the huddle to different members on the team. If you are struggling to incorporate proper design or feel frustration from teammates on an application task, this may be the software design planning solution for you!

Image of book coverI recently read Patrick Lencioni’s latest book, Getting Naked: A Business Fable About Shedding The Three Fears That Sabotage Client Loyalty. I found the book useful, well written, and insightful.

Here is a quick summary of the key ideas:

Always Consult instead of Sell

Rather than harping on past accolades and what you can do if the organization hires you, transform every sales situation into an opportunity to demonstrate value. Start adding value from the very first meeting… without waiting to be hired. Don’t worry about a potential client taking advantage of your generosity. (One potential client in 10 may – but you don’t want that one potential client as a customer anyway!)

Tell kind truth

Be ready to confront a client with a problematic message, even if the client might not like hearing it. Don’t sugar coat or be obsequious. Rather, replay the message in a manner that recognizes the dignity and humanity of the client. Be prepared to deal with “the elephant in the room” that everyone else (including your competitors) is afraid to address.

Don’t be afraid to ask questions or suggest ideas, even if they seem obvious

There is a good chance that a seemingly obvious question/suggestion is actually of benefit to many in the audience.

Of course, there is also that chance of posing a “dumb” question. But no one is expecting perfection from their consultants, but they do expect transparency and honesty. There is no better way to demonstrate both than by acknowledging mistakes.

Make everything about the client

Be prepared to humble yourself by sacrificially taking the burden off of a client in a difficult situation. Be ready to take on whatever the client needs you to do within the context of the services you offer.

The focus of all of your attention needs to be on understanding, supporting, and honoring the business of the client. Do not try to shift attention to yourself, your skills, or your knowledge. Honor the client’s work by taking an active interest in their business and appreciating the importance of their work.

Admit your weaknesses and limitations

Be true to your strengths and be open to admitting your weaknesses. Not doing so will wear you out and prevent you from doing your best in your areas of strength.

Like many of you, we at AIS attempt to subsume many of the above ideas from Lencioni’s book. For example, rather than “sell” a project, we often co-invest (along with the customer) in a micro-POC* or a one-day architecture and design session that helps lay out the vision for the solution, identify main risks, and crystallize the requirements for a project. With the insights derived from a micro-POC, clients can make an informed decision on whether to move forward or not. Here are a couple of examples of micro-POCs:  Jupyter Notebooks as a Custom Calculation Engine, and Just-in-Time Permission Control with Azure RBAC

* Micro-POC (micro Proof of concept) – a time-boxed (typically ~40 hours) “working” realization of an idea/concept with the aim to better understand the potential, risks, and effort involved. This is *not* an early version of a production application.  Also, see this Wikipedia definition of Proof of concept

Driving value, lowering costs, and building your organization’s future with Microsoft’s next great business technology

Lately, I’ve been helping folks understand the Microsoft Power Platform (MPP) by sharing two simple diagrams.

The first one is below and is my stab (others have made theirs) at contextualizing the platform’s various components in relation to one another.

The Common Data Service (CDS) is the real magic, I tell people. No matter which app you are using, the data lives there in that one CDS across your entire environment. (And no, folks outside your organization don’t get to use it.) This means that data available to one of your apps can be re-used and re-purposed by your other apps, no wizardry or custom integration required. I promise, it just works. Think expansively about the power of this in your organization, and you’ll come up with some cockamamie/brilliant ideas about what you can do.

These are the types of data-driving-business-function that geeks like me always dreamed of.

A diagram of Microsoft Power Platform components

Then there’s PowerApps, in purple. Most folks think of this as a low-code/no-code app development tool. It is, but it’s more. Imagine that there are three flavors of PowerApps:

  1. Dynamics 365, which in the end is a set of really big PowerApps developed by Microsoft
  2. COTS apps developed by Microsoft partners (including AIS), available for organizations to license and use
  3. Custom apps you build yourself

Point Microsoft PowerBI at all of this, then mash it up with data from outside of your CDS that you get to via hundreds of out-of-the-box connectors, automate it all together with workflows in Flow…and you’ve got Power Platform in a nutshell.

When I’m presenting this to a group, I turn to my next slide pretty quickly at this point.

A rearranged look at Microsoft Power Platform

Here I’ve essentially re-arranged the pieces to make my broader point: When we think about the Power Platform, the emphasis needs to be on the Platform bit. When your organization invests in this technology, say via working with an implementation partner such as AIS or purchasing PowerApps P1/P2 licenses, you’re not just getting a product or a one-off app solution.

What you’re getting is a platform on which to build your modern business. You’re not just extending Office 365. Instead, you’re creating a future where your organization’s data and business processes are deeply integrated with, driving, and learning intelligently from one another.

The more you leverage the platform, the higher the ROI and the lower the marginal costs of those licenses become. A central goal of any implementing partner ought to be guiding organizations on the journey of migrating legacy systems onto the platform (i.e., retiring legacy licensing + O&M costs) and empowering workers to make the platform even more valuable.

We don’t invest in one-off apps anymore, i.e. a CRM in one corner of your network where you run your sales, something in another where you manage your delivery, clunky Human Resources Management off over there where you take care of your people, etc.. No, what we care about here is the platform where you integrate all of the above — not through monolithic one-size-fits-all ERP — but rather through elegant app experiences across all your users’ devices that tie back to that magical Common Data Service.

This is what I mean when I tell folks sky’s the limit, and thinking about your entire business is what’s called for here. It’s because Power Platform gives us the ability to learn and grow with our customers, constituents, vendors, employees, and other stakeholders like never before.

That’s what has everyone at Microsoft so excited. I am as well.

I want to learn from you. How do you make Power Platform understandable to those who haven’t thought about it too deeply? How does your organization make it valuable as a platform rather than just a product? I love to build beautiful things, so inspire me!

15498218 - search icon

Make no mistake, most organizations and government agencies are—at least in part—software companies. The backbone of the services and products they sell, the internal business processes they use, and the customer feedback mechanisms they rely on are all built on software. Even in the age of software as a service (SaaS) – a modern organization’s portfolio of applications and the specifics of how these apps are used influence its most important decisions.

So while it’s easy to understand that software is a foundational component to modern business, often the decision to invest in building or offering software to users must also be accompanied by a more specific, anticipated return on that investment. That process can go like this:
Read More…

FBI UCR

The FBI’s Uniform Crime Reporting (UCR) Program is a nationwide, cooperative statistical effort of more than 18,000 city, university and college, county, state, tribal, and federal law enforcement agencies voluntarily reporting data on crimes brought to their attention. The program’s primary objective is to generate reliable information for use in law enforcement administration, operation, and management. Over the years, however, this data has become one of the country’s leading social indicators. The FBI is required by law to store national UCR data in a platform that will allow the public to search/view results and download for off-line analysis.

The current UCR data reporting tool was built in Cold Fusion and has not received an update since 2010. The FBI released an RFI solicitation with the intent to gather information about possible ways to replace the current UCR tool. Criteria for the new tool is that it should be web based with the ability to filter on any UCR attribute and then export the results in a .csv format.

Using 2 gigabytes of sample data provided by the FBI, AIS set out to determine if, in just a few weeks, a minimally viable product (MVP) solution could be built leveraging public cloud services that were currently (or soon to be) available in the Azure Government Cloud. The resulting MVP was designed to fully support the capability for citizens to be able query, filter, correlate and display public FBI National Uniform Crime Reporting (UCR) information. Take a look at the solution we built!

Technologies:

  • ASP.NET MVC 4.5 (with jQuery, bootstrap, ADO.NET)
  • Power BI embedded
  • SQL Azure Data Warehouse
  • Blob storage with SaaS for file download
Office Graph In my previous post, I proposed an example application that leverages the resources available to us in Office 365 development platform and Azure Active Directory, as well as the in-application integration of Office 365 Add-ins.

Now we’ll take a deeper look at the Graph API and some of the implementation points.

Build Your Enterprise Graph

The Graph API empowers developers and enterprises to build new relationships and interactions between resources in Azure Active Directory, Office 365, and other applications and data assets.

As Microsoft’s enterprise cloud offerings continue to expand, so will the opportunities to weave these resources together in new and innovative ways. Microsoft’s acquisition of LinkedIn will help it expand its social network graph, so it will be interesting to see how it plays into its Graph API in the future. Read More…

Office_365_AppsEnterprises have a trove of business resources and data that are often under-utilized – users, calendars, contacts, emails, tasks, documents and other files. Often there are redundancies between what users do with Office applications and other enterprise applications, and a painful lack of integration.

In prior posts, I discussed the compelling new Office 365 development platform and introduced Matter Center to demonstrate how integrating web-based add-ins directly into Office applications like Outlook can lead to productivity gains and happy users.

In this post we’ll introduce a sample application to show a practical example of how we can use these technologies to bring enterprise applications together with these valuable resources.

Read More…

Office 365As a full-stack software developer with a penchant for UI/UX, I must admit I was a little skeptical when I was recently tasked to investigate Office 365 as a development platform.

What I found surprised and impressed me.

The Office 365 Development Platform

We’ve gotten really good at spinning up web applications that help users solve problems and increase productivity. That’s great, but it can also leave users with all sorts of disparate applications and stand-alone tools to interact with throughout the day. This contributes to a common productivity disrupter: context switching – that is, the need to frequently switch between different applications and user experiences.

Office 365 offers new compelling ways to integrate external services and custom functionality directly into the Office applications people already use.

Users can do more without having to alt-tab their way through the day, and developers can leverage a rich set of features and functionality without re-inventing the wheel.

Imagine being able to perform many of your day-to-day tasks without ever leaving Outlook. Or accessing external content directly in Word, Excel or PowerPoint. Users can do more without having to alt-tab their way through the day, and developers can leverage a rich set of features and functionality without re-inventing the wheel.

What’s more, the functionality you add is available from anywhere, on any device. Office 365 provides rich browser-based web apps as well as native apps for Windows, iOS, and Android.

Nice.

Read More…

Like every business that’s dependent on consumer sales to fuel growth, you and your team members are probably constantly thinking about how you can make your organization’s sales processes fast and efficient enough to support the growth and customer retention that your executive team desires.

Well, we’ve figured out a way to do just that – our client organization is in the highly competitive insurance industry, and needed a way to increase sales volumes. Enter AIS; we were able to provide our client with an automated method of providing customers with a quote for insurance rates via a self-service web portal solution…resulting in the higher sales volumes they were seeking, while also reducing costs. Read More…