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!

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…

Mobile solutions are already transforming the way we do business and interact with customers, partners and colleagues, but many organizations are still struggling to fully embrace the changes and opportunities. Today’s workforce wants mobile technologies that allow them to work when they want, how they want, and from where they want. (And not to mention using whatever device they want.) Here are 10 reasons to rethink your current mobile strategy and fully embrace the concept of enabling a true mobile workforce.

1. Your workers want lightweight, handheld devices.

Slim and lightweight tablets are making it possible for mobile workers to carry them virtually anywhere without burden. Who wants to carry ruggedized bulky laptops anymore?

2. Tap into tablet innovation.

Innovations are happening at a breakneck pace in the tablet world. Even warehouses are now manufacturing tablets. Fold-up, roll-up or paper tablet, anyone?

3. Simplified app acquisition.

The app economy is expected to grow to $150 billion by 2017. Users simply love the ease of acquiring (and disposing) apps. Most of them already rely on a collection of apps to get their jobs done everyday.

Read More…

70% of all devices sold in 2012 were tablets or smartphones. Tablet purchases by businesses will grow three times by 2016. These numbers, provided by Gartner, confirm what we already know from walking in the mall or sitting at a cafe…and the news for PC sales doesn’t appear to be improving any time soon.

Navigating this post-PC world can a frightening experience when your corporate lifeblood relies on the dominance of PCs. Compounding this is the fragmentation of the emerging market across native mobile platforms, three primary desktop browsers (exponentially more when including mobile), and varying device form factors and operating system flavors. Read More…

In order to meet ever-increasing customer demands and compete on a global scale, many organizations need to be able to fold new systems and/or new features into existing systems quickly and cheaply. These organizations — and perhaps yours — have portfolios of existing systems and infrastructures that were implemented literally decades ago.

These “legacy” systems, while well-architected for the demands and market conditions of the past, have often become increasingly complex through the years and more costly to maintain. What’s more, these systems are based on technologies that simply don’t provide the flexibility and disciplined agility that modern programming languages and frameworks can. Read More…

In my job, I have an opportunity not afforded to most: I get to listen to all of the risks, challenges, and issues (a.k.a. problems) that other organizations face. (I know, you’re jealous, right?)  From issues with large-scale hardware deployments to the risks of implementing new federal bureaucratic form processing, I get to hear it all.  Without fail, nearly all of those discussions start with someone in the room declaring, “We do it different here.”

If I had a dollar for every time I heard, “we do it different here” during a federal project kick-off meeting, well…I would have about twenty or thirty bucks, but that’s not my point. The point is you don’t do it differently!  Human nature is human nature and given similar constraints, regulations, policies and procedures, the outcomes will be similar.  Beyond the obvious irony in nearly all organizations declaring their uniqueness, I am struck by the actual similarities of the problems.

Read More…

With the SharePoint Conference 2012 behind us, I have been reflecting on our SharePoint journey so far…and on the road ahead. And what an incredible journey it has been! SharePoint has allowed AIS to build mission-critical applications for various large federal government agencies and commercial organizations. And not just ECM or document management systems (which are great workloads enabled by SharePoint) but enterprise-class applications for tens of thousands users (such as the FBI’s Delta Project), built using SharePoint platform elements such as workflows, lists, libraries, search, etc.

This blog entry is comprised of two parts. The first part will focus on the SharePoint journey so far. Through a series of short video clips, I will present some of the key insights we have derived over the many years of building custom applications on SharePoint. We will end this the first part with a short demonstration of SharePoint-based Case Management application that brings together many of the key concepts. The second part will focus on the road ahead and the most important enhancements made in SharePoint 2013. Read More…