Consulting | Disabled by Design

Consulting services

Technology strategy Reframe the technology decision

When an organization is deciding whether to adopt, build, automate, replace, or refuse a technology, I do not treat the requested tool as the starting point. I study what the work is for, how people are accomplishing it now, what the formal process leaves out, and who would bear the cost of a bad decision. The result is a clearer account of the problem and a grounded direction for what—if anything—to build.

I also audit existing systems and vendor relationships. I examine unequal control over infrastructure and unequal exposure to its failures: whose needs a platform serves, who controls it, and who bears the costs when it fails. Vendor dependence, opaque systems, and repair work pushed onto staff are part of the design problem. I help organizations understand those constraints and decide what to repair, what accountability to seek from a provider, and when to change the arrangement.

Responsible automation Build the right division of labor among people, AI, and code

I help organizations redesign work around what it was meant to accomplish, rather than simply scaling the way it was done under different technological constraints. Too often, tech companies try to automate the most bias-prone parts of our jobs by delegating judgments that probabilistic AI cannot reliably make. I shape the design around algorithmic bias, unequal consequences, and the limits of each technology from the beginning.

I redefine the task to move automation away from the parts of the work where ambiguity, bias, or unequal consequences require a different kind of judgment. I bring the task itself back into alignment with the mission it was meant to serve. Humans, probabilistic AI, and deterministic code are good at some things and bad at others. I design around these constraints so automations can help people accomplish meaningful work more effectively.

Local data stewardship and knowledge governance Keep sensitive data and organizational knowledge under accountable control

Map what information the organization holds, where it moves, which records people actually rely on, and where conflicts or gaps create risk. Then build practical rules for access, correction, retention, reuse, and source authority so staff can make decisions without treating a database—or last year's grant language—as automatically true. Where privacy, sovereignty, vendor dependence, or computing access matters, design local or open data routes and governance together rather than treating storage as a separate technical choice.

Knowledge infrastructure Make organizational knowledge usable without erasing its context.

Essential knowledge often lives in people's practices, scattered files, and records that disagree. I help organizations bring that material into a working system for research, planning, and writing. For grant writing, I build reusable knowledge bases that connect organizational records to supported claims and drafting material across applications. I connect claims to their sources, distinguish current information from older records, and make gaps and disagreements visible. Shared documentation and review interfaces let the people who know the work check information in context and contribute corrections. I build ways to carry those corrections back into the records and materials that depend on them, while keeping sensitive information out of shared views.

UX and interface design Express complex ideas through intuitive UX.

I use space, layout, and visual hierarchy to express complex concepts, relationships, and choices through websites and applications. I design around people's actual tasks, knowledge, and access needs, refining interfaces through use and feedback. Those differences shape the categories, navigation, visual hierarchy, language, and interactions. Clear choices, useful previews, and explanations of what happens next help people navigate consequential steps. Important distinctions and uncertainty should remain visible, with ways to question information, correct a record, revise a choice, or pause a process. I also review existing websites and workflows to find confusing choices, broken paths, and handoffs where information fails to carry through or actions do not complete. The aim is to help people understand and act while retaining control over what happens next.

Critical technology capacity building and collective inheritance Build for shared capacity and collective inheritance

Turn tacit practices, scattered documentation, and survival workarounds into knowledge the organization can hold together. Build the interfaces, source trails, operator choices, documentation, teaching, and repair paths people need to use and challenge the system. Be explicit about what staff can reasonably maintain and what still requires specialist support. The goal is for people to understand, question, maintain, change, or refuse the system—not depend indefinitely on a consultant.

My approach

Technology is never just hardware and software. Categories, data, permissions, staff practices, informal workarounds, institutional histories, and unequal consequences form social and technical systems. My training in anthropology and Ethnic Studies helps me see how these systems work in practice—especially where the official account leaves out the people and knowledge already carrying the work. That inquiry transforms the problem so we don't automate bad systems poorly. I carry this approach into workflow, governance, software, research, and teaching, then use what the build reveals to revise the analysis again.

Qualitative audit and new evidence can change any earlier step—including the principle or the decision to build.

Situated and community knowledge must be able to change the design

The people doing the work and living with its consequences hold knowledge that formal requirements, datasets, and organizational descriptions often do not contain. Systems are often designed around an implicit norm—including an imagined “standard human.” Situated and community knowledge destabilizes that norm by beginning from specific bodies, experiences, relations, and locations. It matters when it can reframe the task, change which source carries weight, define exceptions, alter an evaluation criterion, stop an action, or redirect what gets built. Consultation without consequence is not the same thing.

Social inequalities—including algorithmic bias—are design parameters to build around and against

Bias, unequal exposure to error, inaccessible defaults, forced legibility, uneven administrative burden, data extraction, and different capacities to absorb failure are not edge conditions to inspect after a system is built. They must shape the design problem from the beginning. The relevant asymmetry must be named rather than collapsed into generic equity language. Disability justice, queer and feminist thought, anti-racism, anti-colonial analysis, and Indigenous sovereignty do not supply one interchangeable checklist; each changes what the designer must notice and what a responsible intervention can mean.

Reframe the task before automating it

The first question is not how to automate a process. It is why the task matters, what it should accomplish, whether implementation lives up to those values, and where unexpected and unequal consequences sit. I return to first principles in order to automate the task well, without trading ethics for efficiency. This means redesigning social and technological infrastructure as an integrated whole so that automation does not become merely an exercise in algorithmic bias.

Critical strategy for integrated technological and social systems

Technology is not a separate layer placed on top of an organization. Categories, interfaces, permissions, workflows, data structures, models, staff practices, institutional histories, and informal workarounds form one sociotechnical system. Designing the technical part without the social system—or treating the social context as an implementation concern—misdescribes the object being designed. Put plainly: a technical system cannot be understood apart from the people, practices, and power relations through which it works. Ethical solutions require designing both together, not simply automating tasks that replicate existing social systems.

Infrastructure should expand collective capacity without displacing collective knowledge

The aim is not only a functioning tool. The infrastructure should help the people responsible for the work understand what it does, question its outputs, correct it, maintain the parts they can reasonably inherit, and decide when it should change or end. This is a design priority, not a guaranteed outcome: organizations may lack time, funding, technical staff, or code literacy. Good handoff cannot manufacture capacity that the surrounding conditions withhold.

Contact

You do not need to translate your situation into a consulting service before writing. Tell me about the people, knowledge, tensions, or system your organization is trying to navigate—and what feels difficult to name or change. I bring my background as a qualitative researcher and teacher to help you articulate what you need before deciding together whether it calls for research, strategy, facilitation, governance, a technical build, or something different.

june@ljunebloch.com