At the request of our Product Manager, I recently took over ownership of the internal identity and access management application for SPH Analytics. My first action as PO was to understand the “state of the world” with the app, and then work towards a SWOT analysis that would ultimately form the product’s roadmap.
My research took me to all the standard places; interviewing developers, researching standards and security. I covered a-lot of ground learning how and why we got to where we are today.
Here’s where it gets a bit interesting, when I got to the external Threats part of the SWOT, my research continuously exposed the question of ROI when creating an identity and access management from scratch. Why do we need a team of people in-house reinventing the wheel, and scrambling to stay current on difficult things like:
- Server Configuration / Security
- Penetration testing
- Support for Single Sign On
- Platform agnostic support
When there are world class solutions out there with teams of people dedicated and up-to-date on the really difficult stuff. SPHA’s core specialty is doing analytics heavy lifting to enable healthcare professionals the means to Take Action with distilled pertinent information.
Conclusion: It’s going to be a bit of a wait, but our next version of identity and access management app will use AWS
or something that looks a-lot like it. Leaving us again to focus on our analytics game and empowering our users. I’m excited to see how different it will be to manage a product on an outside system.
I’m a fan of simple solutions, however getting that simplified solution out the door can be difficult. Often the hardest part is communicating the solution to the group creating the solution. Here’s an example.
When crafting the experience that enabled our 2016 PQRS Client-Administrator user to create and save report templates for their physicians, we sifted through a sea of Centers for Medicare & Medicaid Services (CMS) rules and standards. Distilling that info down into a simple experience took many hours and iterations.
Happy with the approach, we then verified the approach with partner customers with a demonstration and walkthrough. Our Customers validated our approach and latched on to its simplicity as a way to take uncertainty out of the process and reduce the man hours to set up reports. Great news, a solution that solves some big problems, and is verified by a few actual customers – time to start building it.
After writing up all our stories acceptance criteria and attaching all related docs, we hit a brick wall in sprint zero with our offshore development teams. They understood the approach and felt they could build it but were having a hard time getting their heads around the bizarre CMS rules, ambiguous nomenclature and standards for PQRS reporting. It seemed pretty clear we were going to have a QA nightmare testing and correcting the solution if we didn’t provide clarity.
Our mistake? We had distilled the process and information for our clinically based customers – but had not considered all of our audience members – most importantly our non-clinically minded offshore team.
It took us a couple of tries, but we finally found success with a couple of diagrams that worked together to explain the true nature of the beast. (One visually describing what the UI needed to do, and one grid version of the same information – without the flow logic.) I realize it won’t mean much, but since these were difficult to come by, I feel the need to post them (The blog equivalent of putting a “big-win” test on the Fridge perhaps? )
Ui flow of information & logic for 2016 PQRS Client Administrator report creation
Information & logic for 2016 PQRS Client Administrator report creation
I’m not talking about the BYOB of your college days – or even dragging your favorite Pinot Noir to that little place around the corner that has great eats but no license, I’m talking about Build Your Own Bootstrap – BYOB.
There are many many Bootstraps out there now, each with its own strengths. Using a bootstrap can be perfect for getting an idea out there fast, but less great when it comes to building brand or standing out from competitors.
That’s where the idea of BYOB comes into play. Making the leap from using a pre-made bootstrap to hunkering down and developing your own common component system – makes sense, but can appear time consuming. The payoff lies down the road, when you want to change design, direction or leverage your base bootstrap to another line of business – your time to market will be vastly reduced.
It can be a rocky road that requires extra time and planning from everyone:
- A strong product roadmap
- Extra planning/design to define controls and elements that can be repurposed
- Robust database / API designs that allow all instances of your product to be extendable yet remain sandboxed from other instances
- Good Product Management / Design feedback loop to iterate and refine BEFORE coding
- Refined coding practices to build solid elements that are extensible and portable
- Automated QA
- Quickly retool an existing app / site, with reduced coding and QA
- Offer user facing customization options
- For SaaS – implementation time to market for new clients can be nearly instantaneous
- Supporting all customers with a single codebase – bug fixes and upgrades benefit everyone
- You will need a single person or body to actively police all direction and code
- No shortcuts, meaning absolutely no changes can make it to production unless they are 100% on on point and approved (No matter how crazy the deadline, or angry the customer)
- All roadmaps must be as solidified as possible
- All channels between the Ux Team, Product Team, and Development Team must remain open and unrestricted
- All decisions need to be documented and available to everyone
Are you as sick of that #DIV/0! as I am?
Wrap it in this
or if you want text instead then use
I just registered as a mentor for a Stanford’s online course – for a coworker who is interested in learning new stuff. (This course was free) Needless to say, I’m impressed with the program – gone are the days of shady, slap-dash on-line university.
Maintaining navigational continuity is an easy way to make your app more usable – it might seem like a small thing – but done wrong it can work against you.
Basically the rule is this; any link or button text should align directly with the corresponding landing-place or action. (This includes any rollover or tool-tip text for an element itself.) When your link and destination don’t match, you are forcing your user to understand the difference – or worse you are eroding their trust with something that feels like “bait and switch”.
It’s a simple rule, but one that is ignored often, sometimes for good reasons*. Look for it when you are doing code review and add it to your test cases. Get everyone in the habit of looking for it – and talking about it.
*Often the problem stems from trying to shorten the link/button text because there is just not enough room. Need a way to get a decision quickly that everyone can agree with? Try this 15 min. workshop leveraging a group to make quick decisions, it’s a great fast workshop that reinforces your process and can be a team builder.
Then do some quick user testing using a simple poll to see if your users agree.
Here is a great 15 min. workshop to quickly leverage the power of any group (Collective intelligence) to make a solid, quick decision.
- 20-30 people.
- Notepaper or note-cards
You’ll need to get everyone into a room, and have their full attention.
Step 1 set the stage and get them thinking / working
Present the problem or question to the group as simply as possible, and then ask everyone to take a moment to write their answer on a sheet of paper. Give the group a 3-4 minute time-box to think it through and write their answers.
Step 2 randomly distribute the answers
Once the time is up, ask everyone to stand up move about and randomly pass the paper to another person, and keep passing for about 30-40 seconds. Everyone should now have a paper that is not their own. (As them to swap with another I they somehow still have their own)
Step 3 pair off and score the answers
Individuals should then pair off with another to evaluate the answers and score them. The pair should talk it over then assign each answer a single score on the back of the paper (1 to 10, 10 being the highest). Give them a min. to talk and make the decisions.
Once completed – have the room randomly exchange the pieces of paper again, and then evaluate with another partner. Repeat this step until you have four scores on the back of each piece of paper.
Step 4 – tally and find the winner(s)
Ask everyone to tally the amounts on the back of the paper they are holding.
Then using brackets of numbers ask the group to raise their hands if the tally on their card fits the bracket (Try working downward with brackets of five from the maximum number possible)
Ask the winner to read aloud the answer on his or her paper. You will find nearly all of the time the answer with the highest score is spot on. (Often there will be two with similar scores that are very similar – let the group vote by a show of hands the one they like best.)